Dispatch management system, dispatch management device, dispatch management method, and program

Abstract

We aim to promote the use of account linking. [Solution] A dispatch management device that can communicate via a network with a user terminal logged in with a first user account includes one or more processors, which assign a vehicle to a dispatch request received from the user terminal, associate the number of rides (the number of times the user has ridden in the assigned vehicle) with the first user account, and may grant benefits to the first user account based on the number of rides. While the first user account and a second user account different from the first user account are linked, the rate at which the number of rides corresponding to dispatch requests received from the user terminal is increased.

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 allocating a taxi in response to a user's vehicle allocation request is known. For example, Patent Document 1 discloses a technology that estimates the arrival times of the user and the taxi respectively for the boarding place desired by the user, matches the estimation results, and allocates a taxi such that the difference between the estimation results is reduced. [Prior Art Documents] [Patent Documents]

[0003] [Patent Document 1] Japanese Unexamined Patent Application Publication No. 2023-027694 [Summary of the Invention] [Problems to be Solved by the Invention]

[0004] In the vehicle allocation service that allocates taxis in response to vehicle allocation requests as described above, there are cases where a user rank is used and the user rank is updated based on the usage frequency of the service. A user with a higher user rank can obtain greater benefits related to the vehicle allocation service than a user with a lower user rank. In order to obtain such benefits, a user must increase the usage frequency of the vehicle allocation service while the benefits are still small. Here, it is conceivable to adopt a specification that allows users to link their accounts with each other, enabling users to share the high user rank of another user. However, while this provides advantages for users with low user ranks, it provides no advantages for users with high user ranks, making it difficult to promote the use of account linkage.

[0005] In view of these issues, the present invention aims to provide a dispatch management system, a dispatch management device, a dispatch management method, and a program that can promote the use of account linking. [Means for solving the problem]

[0006] In this embodiment, the dispatch management system comprises a user terminal logged in with a first user account and a dispatch management device capable of communicating with the user terminal via a network. The user terminal comprises one or more first processors, and the dispatch management device comprises one or more second processors. The first processor transmits a dispatch request to the dispatch management device, and the second processor assigns a vehicle to the received dispatch request, associates the number of rides (the number of times the user has ridden in the assigned vehicle) with the first user account, and may grant benefits to the first user account based on the number of rides. While the first user account and a second user account different from the first user account are linked, the system increases the rate at which the number of rides corresponding to dispatch requests received from the user terminal is added. In this embodiment, the dispatch management system comprises a user terminal logged in with a first user account and a dispatch management device capable of communicating with the user terminal via a network. The user terminal comprises one or more first processors, and the dispatch management device comprises one or more second processors. The first processor transmits a dispatch request to the dispatch management device, and the second processor assigns a vehicle to the received dispatch request. The second processor associates the number of payments, which is the number of times the fare based on riding in the assigned vehicle has been paid using a payment method associated with the first user account, with the first user account. The second processor may grant benefits to the first user account based on the number of payments. While the first user account and a second user account different from the first user account are linked, the system increases the rate at which the number of payments corresponding to riding in a vehicle assigned to a dispatch request received from the user terminal is accumulated. A dispatch management device that can communicate via a network with a user terminal logged in with a first user account comprises one or more processors, the processors assign a vehicle to the dispatch request received from the user terminal, associate the number of rides (the number of times the user has ridden in the assigned vehicle) with the first user account, and may grant benefits to the first user account based on the number of rides, and while the first user account and a second user account different from the first user account are linked, the rate at which the number of rides corresponding to the dispatch request received from the user terminal is increased. The processor may update the user rank based on the number of rides, grant different benefits to the first user account according to the user rank, and share the user rank of the first user account with the second user account. A dispatch management device that can communicate via a network with a user terminal logged in with a first user account comprises one or more processors, which assign a vehicle to the dispatch request received from the user terminal, associate the number of payments made using the payment method associated with the first user account with the first user account, and may grant benefits to the first user account based on the number of payments, and while the first user account and a second user account different from the first user account are linked, the degree to which the number of payments corresponding to rides in vehicles assigned to dispatch requests received from the user terminal is increased. The processor may update the user rank based on the number of transactions, grant different benefits to the first user account according to the user rank, and share the user rank of the first user account with the second user account. The processor may increase the degree of addition as the number of linked user accounts, which is the number of user accounts different from the first user account that are linked to the first user account, increases. The processor may settle the charges based on rides taken in vehicles dispatched based on the second user account using a payment method that bills the second user account. The processor may settle the charges based on rides taken in vehicles dispatched under the second user account using a payment method that bills a user account different from the second user account. The processor may settle the fare for a ride in a vehicle dispatched based on the second user account using a payment method that bills the first user account. The processor may also share the vehicle dispatch information of the second user account with the first user account. In the dispatch management method of this embodiment, the computer assigns a vehicle to a dispatch request received from a user terminal logged in with a first user account, associates the number of rides (the number of times the user has ridden in the assigned vehicle) with the first user account, and may grant benefits to the first user account based on the number of rides. While the first user account and a second user account different from the first user account are linked, the computer increases the rate at which the number of rides corresponding to dispatch requests received from the user terminal is accumulated. In the dispatch management method of this embodiment, the computer assigns a vehicle to a dispatch request received from a user terminal logged in with a first user account, associates the number of payments made using the payment method associated with the first user account for fares based on rides in the assigned vehicle with the first user account, and may grant benefits to the first user account based on the number of payments, and increases the rate at which the number of payments corresponding to rides in vehicles assigned to dispatch requests received from the user terminal is accumulated while the first user account and a second user account different from the first user account are linked. In this embodiment, the program may instruct the computer to assign a vehicle to a ride request received from a user terminal logged in with a first user account, associate the number of rides (the number of times the user has ridden in the assigned vehicle) with the first user account, grant benefits to the first user account based on the number of rides, and increase the rate at which the number of rides corresponding to ride requests received from the user terminal is added while the first user account and a second user account different from the first user account are linked. In this embodiment, the program causes the computer to assign a vehicle to a ride request received from a user terminal logged in with a first user account, associate the number of payments made using the payment method associated with the first user account for rides in the assigned vehicle with the first user account, grant benefits to the first user account based on the number of payments, and increase the rate at which the number of payments corresponding to rides in the assigned vehicle for ride requests received from the user terminal is accumulated while the first user account and a second user account different from the first user account are linked. [Effects of the Invention]

[0007] According to the present invention, it becomes possible to promote the use of account linking. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a block diagram illustrating the general structure of the dispatch management system. [Figure 2] Figure 2 is a block diagram illustrating the configuration of the user terminal. [Figure 3] Figure 3 is a block diagram illustrating the configuration of the crew terminal. [Figure 4] Figure 4 is a block diagram illustrating the configuration of the service provider's server. [Figure 5]Figure 5 is a block diagram illustrating the configuration of the dispatch management server. [Figure 6] Figure 6 is a sequence diagram showing the processing flow of the dispatch management method using the dispatch management system. [Figure 7] Figure 7 is an explanatory diagram illustrating the processing in the vehicle dispatch department. [Figure 8] Figure 8A is the first explanatory diagram for illustrating the pair generation process. Figure 8B is the second explanatory diagram for illustrating the pair generation process. [Figure 9] Figure 9A is the first explanatory diagram for explaining the matching process. Figure 9B is the second explanatory diagram for explaining the matching process. Figure 9C is the third explanatory diagram for explaining the matching process. Figure 9D is the fourth explanatory diagram for explaining the matching process. [Figure 10] Figure 10A is the first explanatory diagram for illustrating the processing of the vehicle dispatching department. Figure 10B is the second explanatory diagram for illustrating the processing of the vehicle dispatching department. [Figure 11] Figure 11A is the first explanatory diagram for illustrating the matching process. Figure 11B is the second explanatory diagram for illustrating the matching process. [Figure 12] Figure 12A is the first explanatory diagram for illustrating the processing of the vehicle dispatching department. Figure 12B is the second explanatory diagram for illustrating the processing of the vehicle dispatching department. [Figure 13] Figure 13A is the first explanatory diagram for explaining the processing of the dispatching department. Figure 13B is the second explanatory diagram for explaining the processing of the dispatching department. Figure 13C is the third explanatory diagram for explaining the processing of the dispatching department. [Figure 14] Figure 14 is a flowchart illustrating the operation of the dispatch management server in the ride-hailing reservation service. [Figure 15] Figure 15 is a flowchart illustrating the operation of the dispatch management server in the early dispatch service. [Figure 16]FIG. 16A is a first explanatory diagram for explaining an example of the operation of the user terminal control unit. FIG. 16B is a second explanatory diagram for explaining an example of the operation of the user terminal control unit. FIG. 16C is a third explanatory diagram for explaining an example of the operation of the user terminal control unit. FIG. 16D is a fourth explanatory diagram for explaining an example of the operation of the user terminal control unit. [Figure 17] FIG. 17A is a first explanatory diagram for explaining processing of the vehicle allocation unit. FIG. 17B is a second explanatory diagram for explaining processing of the vehicle allocation unit. FIG. 17C is a third explanatory diagram for explaining processing of the vehicle allocation unit. FIG. 17D is a fourth explanatory diagram for explaining processing of the vehicle allocation unit. [Figure 18] FIG. 18 is an explanatory diagram for explaining benefit contents of a loyalty program. [Figure 19] FIG. 19 is an explanatory diagram for explaining benefit contents of a subscription. [Figure 20] FIG. 20 is an explanatory diagram for explaining a difference between family linkage and general linkage. [Figure 21] FIG. 21A is a first explanatory diagram for explaining an increase in the addition rate of the number of rides. FIG. 21B is a second explanatory diagram for explaining an increase in the addition rate of the number of rides. [Figure 22] FIG. 22 is an explanatory diagram for explaining an example of the operation of the user terminal control unit. MODE FOR CARRYING OUT THE INVENTION

[0009] Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Dimensions, materials, other specific numerical values and the like shown in these embodiments are merely examples for facilitating understanding of the invention, and do not limit the present invention unless otherwise stated. In the present specification and the drawings, elements having substantially the same function and configuration are denoted by the same reference numerals to omit redundant description, and elements not directly related to the present invention are omitted from illustration.

[0010] (Vehicle allocation management system 1) Figure 1 is a block diagram illustrating the general structure of the dispatch management system 1. The dispatch management system 1 includes multiple user terminals 20, multiple driver terminals 30, multiple vehicles 32, one or more operator servers 40, and one or more dispatch management servers 50. In the dispatch management system 1, the commercial vehicles 32 that serve as the means of transportation for user 2 include not only taxi vehicles but also NRS vehicles. NRS is an abbreviation for Japanese-style rideshare or Japanese version of rideshare, and refers to a service in which ordinary drivers transport user 2 for a fee using their private cars, etc.

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

[0012] Figure 2 is a block diagram illustrating the configuration of the user terminal 20. The user terminal 20 includes a communication device 120, a processing device 122, a display device 124, an input device 126, and a storage device 128. The communication device 120 is connected to an external source, such as a dispatch management server 50, via a base station 5 and a network 6. The processing device 122 has a semiconductor integrated circuit including a processor such as a CPU (Central Processing Unit), a ROM (Read Only Memory) where programs are stored, and a RAM (Random Access Memory) used as a work area. A user application for the dispatch management system 1 can be installed on the user terminal 20. The processing device 122 controls the user application by running a program and functions as a dispatch request unit 160 that assists in inputting dispatch requests, which are dispatch requests by user 2. Here, dispatch indicates assigning a vehicle 32 to a dispatch request and sending it to the pick-up location. The display device 124 includes a liquid crystal display, an organic EL (Electro Luminescence) display, etc., and displays various information, such as images of the user application for making dispatch requests. The input device 126 includes a touch panel, switches, buttons, keys, and a microphone for voice input superimposed on the display device 124, and accepts input from user 2, such as information for requesting a vehicle dispatch. The storage device 128 is composed of storage means such as an HDD (Hard Disk Drive), SD memory, and SSD (Solid State Drive).

[0013] The crew terminal 30 is an electronic device lent to the driver 3 of the vehicle 32, or an electronic device owned by the driver 3, and is used when operating the vehicle 32. Therefore, the crew terminal 30 is associated with the vehicle 32 together with the driver 3. In short, the crew terminal 30 only needs to be located (exist) within the vehicle 32 so that the driver 3 can operate and refer to it. Therefore, the crew terminal 30 is not limited to being brought into the vehicle at the start of driving, but may also be installed (fixed) in the vehicle 32 beforehand. Examples of the crew terminal 30 include smartphones, personal computers, tablet PCs, etc.

[0014] Figure 3 is a block diagram illustrating the configuration of the crew terminal 30. The crew terminal 30 includes a communication device 130, a processing device 132, a display device 134, an input device 136, and a storage device 138. The communication device 130 is connected to an external source, such as the operator server 40 or the dispatch management server 50, via a base station 5 and a network 6. The processing device 132 has a semiconductor integrated circuit including a processor (CPU), ROM for storing programs, RAM used as a work area, etc. A vehicle application for the dispatch management system 1 is installed on the crew terminal 30. The processing device 132 controls the vehicle application by running a program and functions as a dispatch response unit 162 that supports driver 3's response input to dispatch requests. The display device 134 includes a liquid crystal display and an organic EL display and displays various information to the driver 3, such as that their vehicle 32 has become the target of a dispatch request (dispatch target notification) and information related to the dispatch request (boarding location, alighting location, user information about user 2). Hereinafter, the subject of a dispatch request may be referred to as the "dispatch target," and the vehicle 32 that becomes the dispatch target may be referred to as the "dispatch target vehicle." The driver terminal 30 can also function as a fare meter (taxi meter) that automatically calculates the fare according to the distance traveled and the time taken from the pick-up location to the drop-off location. In this case, the display device 134 displays information to the user 2, for example, indicating the automatically calculated fare. Such a fare meter realized by the driver terminal 30 may be called a "soft meter" to distinguish it from a dedicated meter fixed to the taxi. The input device 136 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc., superimposed on the display device 134, and accepts input from the driver 3, for example, acceptance of a dispatch request. The storage device 138 consists of storage means such as an HDD, SD memory, or SSD. The driver terminal 30 can obtain its own location on a map through location identification means such as GPS (Global Positioning System).

[0015] Driver 3 is the crew member of vehicle 32. Driver 3 includes both taxi drivers and NRS drivers. A taxi driver is a crew member who holds a Class 2 ordinary driver's license and belongs to the taxi business (general passenger transport business). An NRS driver is a driver who holds a Class 1 ordinary driver's license and belongs to the ride-sharing business (private vehicle paid passenger transport business). In this embodiment, we will explain using an example in which a taxi operator also manages a ride-sharing business based on Article 78, Paragraph 3 of the Road Transport Act. Therefore, it can be said that an NRS driver is a driver who belongs to a taxi operator. NRS drivers differ from taxi drivers in that they may not have a Class 2 ordinary driver's license, or their qualifications as a driver, driving skills, and knowledge may be low. Also, NRS drivers cannot engage in so-called cruising, where they look for users 2 who wish to ride while driving vehicle 32, as taxi drivers do. Furthermore, in the case of paid passenger transport using private vehicles based on Article 78, Paragraph 3 of the Road Transport Act, the NRS driver may charge User 2 a fee (fare) equivalent to that of a general passenger transport business as consideration for transporting User 2.

[0016] Vehicle 32 is, for example, a vehicle belonging to a taxi operator (taxi, NRS vehicle) and can transport user 2 for a fee as part of a taxi service. In the dispatch management system 1, there are multiple combinations of driver 3, vehicle 32, and crew terminal 30. In this embodiment, a four-wheeled taxi (hire car) is given as an example of a vehicle 32 to be dispatched, but it is not limited to this example, and vehicle 32 may include, for example, a motorcycle (motorcycle taxi) as long as it is a vehicle capable of transporting people. Also, if driver 3 is an NRS driver, a private car or an idle taxi vehicle can be used as the vehicle 32 to be dispatched. Furthermore, in the dispatch management system 1, driver 3 is not necessarily required to drive vehicle 32, and a so-called autonomously driven vehicle 32 that does not require driver 3 can also be applied.

[0017] Furthermore, each vehicle 32 has a designated operating area. If driver 3 is a taxi driver, vehicle 32 can operate within the operating area of ​​the taxi company to which it belongs. For example, if the operating area is within the special wards of Tokyo, vehicle 32 can operate in the 23 wards of Tokyo, Musashino City, and Mitaka City. This operating area of ​​vehicle 32 is sometimes referred to as the transportation area. Also, if driver 3 is an NRS driver, the operating area of ​​vehicle 32 is included in the operating area of ​​the taxi driver's vehicle 32, and is often smaller than the operating area of ​​the taxi driver's vehicle 32.

[0018] Figure 4 is a block diagram illustrating the configuration of the operator server 40. The operator server 40 is an information processing device (computer) owned by an operator operating a taxi business. The operator server 40 manages vehicles 32 driven by drivers 3 belonging to the taxi business. The operator server 40 includes a communication device 140, a processing device 142, a display device 144, an input device 146, and a storage device 148. The communication device 140 is connected to an external source, such as a driver terminal 30 or a dispatch management server 50, via a network 6. The processing device 142 has a semiconductor integrated circuit including a processor (CPU), ROM where programs are stored, and RAM used as a work area. By running a program, the processing device 142 functions as a vehicle management unit 164 that manages vehicles 32 belonging to the taxi business. The display device 144 includes a liquid crystal display and an organic EL display, and displays various information such as information about the driver 3 or the vehicle 32, obtained directly from the vehicle 32 or via the dispatch management server 50. The input device 146 includes a keyboard, a touch panel superimposed on the display device 144, a microphone for voice input, etc., and receives input from operators at the service provider. For example, the operator can communicate with the driver 3 via the service provider server 40, or view images of the vehicle's interior and exterior, including images of the driver 3. The storage device 148 consists of storage means such as an HDD, SD memory, or SSD.

[0019] Figure 5 is a block diagram illustrating the configuration of the dispatch management server 50. The dispatch management server (dispatch management device) 50 is an information processing device (computer) that manages vehicles 32 belonging to a taxi company based on a contract between the dispatch management company and the taxi company. The dispatch management server 50 is an example of a dispatch management device with server functionality and is operated by the dispatch management company. The dispatch management server 50 can dispatch a vehicle 32 to user 2 in response to a dispatch request from user terminal 20. The dispatch management server 50 includes a communication device 150, a processing device 152, and a storage device 154. The communication device 150 is connected to the outside world via the network 6, for example, to communicate with user terminal 20, driver terminal 30, and operator server 40. The processing device 152 has a semiconductor integrated circuit including a processor (CPU), ROM in which programs are stored, RAM used as a work area, etc. By running programs, the processing device 152 functions as a user terminal control unit 170, a dispatch unit 172, and a driver terminal control unit 174. The user terminal control unit 170 controls the user application installed on the user terminal 20. The dispatch unit 172 assigns a vehicle 32 to a dispatch request. The crew terminal control unit 174 controls the vehicle application installed on the crew terminal 30. The storage device 154 consists of storage means such as an HDD, SD memory, or SSD, and stores information about the user 2 and the vehicle 32.

[0020] Furthermore, the dispatch management server 50 manages the dispatch status of each vehicle 32 by dispatch status. The dispatch management server 50 sets the dispatch status of a vehicle 32 that is not carrying user 2 but is ready to transport user 2 (ready to transport user 2) to "vacant". The dispatch management server 50 identifies the vehicle to be dispatched to correspond to the dispatch request, and when the driver 3 accepts the dispatch (when the dispatch is confirmed), it changes the dispatch status of that vehicle 32 to "on call". The dispatch management server 50 changes the dispatch status to "on call" when the vehicle 32 reaches the pick-up location or its vicinity (for example, within 80m) and the arrival switch is operated via the crew terminal 30. The dispatch management server 50 changes the dispatch status to "on call" when the vehicle 32 arrives at the pick-up location, passenger 2 is boarded, and the vehicle is in use switch is operated via the crew terminal 30. The dispatch management server 50 changes the dispatch status to "paid" when the vehicle 32 arrives at the drop-off location and the payment switch is operated via a meter device (not shown). The dispatch management server 50 changes the dispatch status to "payment completed" when the payment processing is completed and the payment completion switch is operated via the driver terminal 30. The dispatch management server 50 changes the dispatch status to "vacant" when the vacant switch is operated via the meter device after payment is completed. The vehicle 32 can notify the outside of the vehicle of such dispatch statuses.

[0021] In the dispatch management system 1, when assigning a vehicle 32 to a dispatch request (i.e., dispatching a vehicle), a matching process is performed between multiple dispatch requests and multiple vehicles 32, so that, for example, one vehicle 32 is assigned to one dispatch request from one user 2. Here, the matching process refers to the process of exclusively associating any dispatch request with any vehicle 32 when multiple dispatch requests and multiple vehicles 32 exist. The following explanation will use an example of assigning one vehicle 32 to one dispatch request, but if carpooling is permitted, where multiple users 2 ride together in one vehicle 32, then multiple dispatch requests from multiple users 2 may be combined, and one vehicle 32 may be assigned to that combined dispatch request.

[0022] (Ride-hailing service) First, we will describe a standard ride-hailing service that matches multiple ride requests with multiple vehicles 32. Then, we will describe priority ride-hailing services, ride-hailing reservation services, and early ride-hailing services, which can be selectively added based on the ride-hailing service and at the user's request.

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

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

[0025] In addition to the initial ride-hailing preference, the settings include options such as pickup location, drop-off location, payment information, ride-hailing category, taxi operator, vehicle attributes, toll road information, and ride-sharing permission information.

[0026] The pick-up location indicates the map location where User 2 will board the vehicle 32. User 2 can set their current location as the pick-up location, or they can set a desired location different from their current location as the pick-up location. The drop-off location indicates the map location where User 2 will alight from the vehicle 32. When User 2 sets the pick-up and drop-off locations, the fare calculated based on the set time, pick-up location, and drop-off location is calculated and displayed on the display device 124. In this way, User 2 can know in advance the fare they will pay for riding in the vehicle 32. If User 2 limits the dispatch target to only taxi vehicles, the drop-off location is not required input information and can be entered optionally. On the other hand, if User 2 includes NRS vehicles in the dispatch target, the drop-off location becomes required input information.

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

[0028] The taxi operator indicates the operator to which driver 3 belongs as a taxi operator. User 2 can specify the desired taxi operator by entering information in the settings field for the taxi operator. The vehicle attributes indicate the type and equipment of vehicle 32. Examples of vehicle attributes include whether or not it is a high-class vehicle (so-called hire car), whether or not it is wheelchair accessible, and whether or not it has sliding doors. In this way, user 2 can specify the attributes of the vehicle they wish to be dispatched by entering information in the settings field for the vehicle attributes. The toll road information indicates whether or not toll roads, such as expressways, will be used. If the use of toll roads is indicated in the toll road information, toll roads will be actively included in the route from the pick-up location to the drop-off location. The ride-sharing permission information indicates whether or not ride-sharing is permitted in vehicle 32, where another user 2 rides along.

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

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

[0031] However, in reality, the matching process initiated at the previous execution timing may not have determined the vehicle to be dispatched for a dispatch request. Such dispatch requests for which the vehicle to be dispatched has not been determined are carried over to the current execution timing, and the matching process continues. Therefore, the dispatch unit 172 extracts dispatch requests accumulated up to the current execution timing, including dispatch requests accumulated from the previous execution timing to the current execution timing, as well as dispatch requests for which the vehicle to be dispatched has not been determined by the previous matching process.

[0032] (Vehicle extraction process S4) The dispatch unit 172 selects one or more vehicles 32 from among multiple vehicles 32 capable of carrying user 2 that satisfy predetermined selection conditions related to the dispatch request extracted in the dispatch request extraction process S3. Here, one example of a selection condition is that the estimated arrival time to the pick-up location is short. Specifically, a selection condition may be that the distance between the pick-up location and the current position of vehicle 32 is within a predetermined distance (e.g., 10 km), or that the estimated arrival time to the pick-up location is within a predetermined time (e.g., 10 minutes). In this case, the distance is the Euclidean distance between the pick-up location and the current position of vehicle 32, and the estimated arrival time is the time obtained by dividing the Euclidean distance by a predetermined speed (e.g., the average speed when vehicle 32 is operating). The operational state of vehicle 32 primarily refers to the state where the dispatch status is "on call" (driving towards user 2's pick-up location) and the state where the dispatch status is "on call" (driving with user 2 on board), and does not include the stationary state where the vehicle is waiting for a dispatch request. Furthermore, the dispatch unit 172 may also limit the number of vehicles 32 to be extracted to a predetermined number (for example, 10 vehicles) based on the distance between the pick-up location and the vehicle's current location, or the shortest estimated arrival time at the pick-up location.

[0033] Figure 7 is an explanatory diagram illustrating the processing of the dispatch unit 172. Figure 7 shows six users 2a to 2f who have made dispatch requests within service area A, and eleven vehicles 32a, 32b, 32c, 32d, 32e, 32f, 32g, 32h, 32i, 32j, and 32k located within service area A.

[0034] The dispatch unit 172 sets extraction conditions for each of the dispatch requests extracted in the dispatch request extraction process S3, that is, for each of the dispatch requests 22a to 22f from users 2a to 2f. Here, the extraction condition adopted is that the distance between the boarding location and the current location of the vehicle 32 is less than or equal to a predetermined distance. Therefore, for each of the dispatch requests 22a to 22f from users 2a to 2f, the extraction conditions 24a to 24f, shown by the dashed arcs in Figure 7, are set.

[0035] The dispatch unit 172 extracts vehicles 32 that satisfy the extraction conditions 24a to 24f for each of the dispatch requests 22a to 22f from users 2a to 2f. For example, for user 2a's dispatch request 22a, the vehicles 32 that satisfy the extraction condition 24a are vehicles 32a, 32b, 32c, 32d, and 32e. For user 2b's dispatch request 22b, the vehicles 32 that satisfy the extraction condition 24b are vehicles 32e, 32f, 32g, 32h, and 32i. For user 2c's dispatch request 22c, the vehicles 32 that satisfy the extraction condition 24c are vehicles 32d, 32e, 32f, 32h, and 32i. For user 2d's dispatch request 22d, the vehicles 32 that satisfy the extraction condition 24d are vehicles 32d, 32e, 32f, and 32i. Furthermore, the vehicles 32 that satisfy the extraction condition 24e for user 2e's dispatch request 22e are vehicles 32d, 32h, and 32i. Also, the vehicles 32 that satisfy the extraction condition 24f for user 2f's dispatch request 22f are vehicles 32d, 32i, and 32j. The dispatch unit 172 extracts all vehicles 32a, 32b, 32c, 32d, 32e, 32f, 32g, 32h, 32i, and 32j that are included in the extraction range 26 enclosed by a solid line in Figure 7 and satisfy any of the extraction conditions 24a to 24f for each of the dispatch requests 22a to 22f, and excludes vehicle 32k, which does not satisfy any of the extraction conditions 24a to 24f, as a vehicle 32 that cannot be dispatched.

[0036] (Pair generation process S5) The dispatch unit 172 extracts at least one candidate vehicle pair that satisfies predetermined pairing conditions from the vehicles 32a, 32b, 32c, 32d, 32e, 32f, 32g, 32h, 32i, and 32j extracted in the vehicle extraction process S4, for each dispatch request 22 extracted in the dispatch request extraction process S3, and associates the extracted candidate vehicle pair with the dispatch request 22. Here, the pairing condition is that all of the acceptable items of the vehicle 32 match all of the setting items of the dispatch request 22. For example, if the vehicle attribute included in the setting items of the dispatch request 22 is "compatible with sliding doors," the dispatch unit 172 determines that the vehicle 32 "matches" if the attribute included in the acceptable items of the vehicle 32 has sliding doors. If even one of the acceptable items of the vehicle 32 does not match the setting items of the dispatch request 22, the dispatch unit 172 determines that the vehicle 32 does not satisfy the pairing condition. On the other hand, if the vehicle 32's acceptable items match all the setting items of the dispatch request 22, the dispatch unit 172 associates the vehicle 32 with the dispatch request 22 as a candidate vehicle that satisfies the pairing conditions of the dispatch request 22.

[0037] Figures 8A and 8B are explanatory diagrams illustrating the pair generation process. Here, we assume that all of the vehicles 32a, 32b, 32c, 32d, 32e, 32f, 32g, 32h, 32i, and 32j extracted by the dispatch unit 172 match the settings items of the dispatch requests 22a to 22f from users 2a to 2f.

[0038] The dispatch unit 172, in response to user 2a's dispatch request 22a, extracts vehicles 32a, 32b, 32c, 32d, 32e, 32f, 32g, 32h, 32i, and 32j included in the extraction range 26 of Figure 7 that satisfy the pairing conditions of dispatch request 22a, and designates them as candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j. The dispatch unit 172 then associates these candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j with user 2a's dispatch request 22a. Similarly, the dispatch unit 172 associates the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j with the dispatch requests 22b to 22f from users 2b to 2f. In this way, as shown in Figure 8A, one or more candidate pair vehicles 232 are associated with each of the dispatch requests 22a to 22f.

[0039] In this case, the dispatch unit 172 determines whether the vehicle 32 is compatible with all the settings of the dispatch request 22. However, not limited to this case, if the dispatch unit 172 has already determined the compatibility of some of the settings, such as the dispatch preference or the sales office, the dispatch unit 172 may omit determining the compatibility of those settings. In this way, the processing load on the dispatch management server 50 can be reduced.

[0040] Next, the dispatch unit 172 estimates the estimated arrival time of each associated candidate vehicle 232 at the boarding location for each dispatch request 22a to 22f, and associates it with each candidate vehicle 232. Since the positional relationship between the user 2 who made the dispatch request 22 and the vehicle 32 is different for each dispatch request 22, the estimated arrival time will differ for each dispatch request 22, even for the same candidate vehicle 232.

[0041] Next, the dispatch unit 172 sets a vehicle priority for each pair of candidate vehicles 232 associated with each dispatch request 22. Here, the vehicle priority indicates the order in which the vehicle should be dispatched. When setting the vehicle priority, the dispatch unit 172 recalculates the estimated arrival time to the pick-up location. At this time, the shorter the recalculated estimated arrival time, the higher the vehicle priority. The estimated arrival time recalculated here may be the time obtained by dividing the Euclidean distance by a predetermined speed, as in the case of the extraction conditions, but it may also be the travel time that takes into account the route the vehicle 32 takes to arrive at the pick-up location. Furthermore, the dispatch unit 172 may derive the travel time by taking into account the direction of travel of the vehicle 32 at the time of extraction of the vehicle 32, the stopping time at traffic lights along the route, etc., in addition to the route.Therefore, the dispatch unit 172 can set the vehicle priority using an estimated arrival time that is equivalent to, or more accurate than, the estimated arrival time based on the Euclidean distance used as the extraction condition.

[0042] For example, as shown in Figure 8A, the dispatch unit 172 rearranges the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j, which are associated with the dispatch request 22a, in order of shortest recalculated estimated arrival time, as shown in Figure 8B, to candidate pair vehicles 232b, 232d, 232c, 232e, 232a, 232f, 232i, 232h, 232g, and 232j. Similarly, the dispatch unit 172 rearranges the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j associated with the dispatch request 22b, in order of shortest recalculated estimated arrival time, to candidate pair vehicles 232i, 232h, 232f, 232e, 232g, 232d, 232a, 232b, 232j, and 232c. Furthermore, the dispatch unit 172 rearranges the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j, which are associated with the dispatch request 22c, in order of shortest recalculated estimated arrival time, to candidate pair vehicles 232i, 232e, 232d, 232f, 232h, 232g, 232c, 232b, 232j, and 232a. Furthermore, the dispatch unit 172 rearranges the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j, which are associated with the dispatch request 22d, in order of shortest recalculated estimated arrival time, to candidate pair vehicles 232d, 232i, 232e, 232f, 232h, 232c, 232b, 232a, 232g, and 232j. Furthermore, the dispatch unit 172 rearranges the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j, which are associated with the dispatch request 22e, in order of shortest recalculated estimated arrival time, to candidate pair vehicles 232i, 232h, 232d, 232j, 232f, 232e, 232g, 232c, 232b, and 232a. Furthermore, the dispatch unit 172 rearranges the candidate pair vehicles 232a, 232b, 232c, 232d, 232e, 232f, 232g, 232h, 232i, and 232j, which are associated with the dispatch request 22f, in order of shortest recalculated estimated arrival time, to candidate pair vehicles 232d, 232i, 232j, 232h, 232e, 232c, 232f, 232b, 232g, and 232a.

[0043] Thus, as shown in Figure 8B, for each dispatch request 22a to 22f, one or more candidate vehicle pairs 232 are assigned a vehicle priority, and one or more combinations of dispatch requests 22 and candidate vehicle pairs 232 are generated. Here, it can be seen that the vehicle priority of the candidate vehicle pairs 232 corresponding to each dispatch request 22a to 22f differs depending on the positional relationship between the users 2a to 2f and the candidate vehicle pairs 232.

[0044] As shown in Figure 8B, for each of the dispatch requests 22a to 22f, one or more pairs of candidate vehicles 232 are associated with a vehicle priority, that is, in order of shortest estimated arrival time at the pick-up location. Therefore, the dispatch management server 50 can assign a vehicle 32 with the shortest estimated arrival time at the pick-up location by extracting the candidate vehicles 232 in order of highest vehicle priority for each of the dispatch requests 22a to 22f.

[0045] Furthermore, for each of the dispatch requests 22a to 22f, all available vehicles 32 are associated, and vehicle priorities are set. This is because there may be cases where a vehicle 32 designated for dispatch cannot accept a dispatch request. For example, suppose vehicle 32 is cruising, accepting ride requests from users 2 found near its route, and simultaneously receives dispatch requests 22 from users 2a to 2f and a ride request from user 2 near its route. In this case, vehicle 32 will be in order to pick up user 2 near its route and will not be able to accept dispatch request 22. Therefore, even if a vehicle 32 designated for dispatch cannot accept a dispatch request for any reason, the dispatch management server 50 can efficiently assign a vehicle 32 with a short estimated arrival time to the pick-up location to each of the dispatch requests 22a to 22f by extracting the second-highest (next) candidate vehicle 232.

[0046] However, depending on the relative positions of user 2 and vehicle 32, the pair candidate vehicle 232i with the highest vehicle priority may overlap in dispatch requests 22b, 22c, and 22e, as shown by the dashed lines in Figure 8B, or the pair candidate vehicle 232d with the highest vehicle priority may overlap in dispatch requests 22d and 22f, as shown by the dashed lines in Figure 8B. In such cases, the dispatch management server 50 will be unable to appropriately assign the pair candidate vehicle 232 as the vehicle to be dispatched for dispatch requests 22b to 22f. Therefore, the dispatch unit 172 performs a matching process between dispatch request 22 and the pair candidate vehicle 232.

[0047] (Matching process S6) The dispatch unit 172 performs a matching process between the dispatch request 22 and the candidate vehicle 232 for multiple combinations obtained by multiplying the dispatch request 22 and the candidate vehicle 232 associated in the pair generation process S5. In this matching process, the dispatch request 22 and the candidate vehicle 232 are matched such that the candidate vehicle with the highest vehicle priority among the at least one candidate vehicle 232 associated with each dispatch request 22 does not overlap with the at least one candidate vehicle 232 associated with other dispatch requests 22. For example, for each of the dispatch requests 22a to 22f, the dispatch unit 172 exclusively matches the candidate vehicle 232 that has the shortest average (or sum) estimated arrival time to the pick-up location.

[0048] As shown in Figure 8B, each of the dispatch requests 22a to 22f is associated with one or more candidate pairs of vehicles 232, each assigned a vehicle priority. Here, the dispatch unit 172 attempts to extract the candidate pair of vehicles 232 with the highest vehicle priority for each of the dispatch requests 22a to 22f as the vehicle to be dispatched. In other words, the dispatch unit 172 extracts candidate pair of vehicles 232b for dispatch request 22a, candidate pair of vehicles 232i for dispatch request 22b, candidate pair of vehicles 232i for dispatch request 22c, candidate pair of vehicles 232d for dispatch request 22d, candidate pair of vehicles 232i for dispatch request 22e, and candidate pair of vehicles 232d for dispatch request 22f, thereby enabling the assignment of a vehicle 32 with a short estimated arrival time to the pick-up location to each of the dispatch requests 22a to 22f.

[0049] Here, the candidate vehicle pair 232b for dispatch request 22a does not overlap with the candidate vehicle pair 232 with the highest vehicle priority in the other dispatch requests 22b to 22f. Therefore, the dispatch unit 172 confirms candidate vehicle pair 232b for dispatch request 22a as the vehicle to be dispatched.

[0050] However, in dispatch requests 22b, 22c, and 22e, the candidate vehicle 232i with the highest vehicle priority is duplicated for each request. Also, in dispatch requests 22d and 22f, the candidate vehicle 232d with the highest vehicle priority is duplicated for each request. Even if the same candidate vehicle 232i were simultaneously assigned as the vehicle to be dispatched to multiple dispatch requests 22b, 22c, and 22e, the candidate vehicle 232i cannot accept all of the dispatch requests 22b, 22c, and 22e at the same time.

[0051] Therefore, the dispatch unit 172 performs an exclusive processing to change the combination of dispatch requests 22b, 22c, and 22e and the candidate pair vehicle 232 so that the candidate pair vehicle 232 with the highest vehicle priority for each of the dispatch requests 22b, 22c, and 22e is different. Specifically, the dispatch unit 172 assigns the candidate pair vehicle 232i to one of the dispatch requests 22b, 22c, and 22e in which the candidate pair vehicle 232i overlaps. Then, for the other dispatch requests 22, the dispatch unit 172 assigns candidate pair vehicles 232 with lower vehicle priority until there is no overlap between the candidate pair vehicle 232 and the other dispatch requests 22.

[0052] Figures 9A to 9D are explanatory diagrams illustrating the matching process. For example, as shown in Figure 9A, the dispatch unit 172 assigns candidate vehicle 232i to dispatch request 22b, candidate vehicle 232e, which has the next highest vehicle priority after candidate vehicle 232i, to dispatch request 22c, and candidate vehicle 232h, which has the next highest vehicle priority after candidate vehicle 232i, to dispatch request 22e. The combination of assigning candidate vehicles 232i, 232e, and 232h to dispatch requests 22b, 22c, and 22e is called pair group A. Similarly, as shown in Figure 9B, the dispatch unit 172 assigns 232i to dispatch request 22c, candidate vehicle 232h, which has the next highest vehicle priority after candidate vehicle 232i, to dispatch request 22b, and candidate vehicle 232d, which has the next highest vehicle priority after candidate vehicle 232h, to dispatch request 22e. Thus, the combinations in which candidate vehicles 232h, 232i, and 232d are assigned to dispatch requests 22b, 22c, and 22e are designated as Pair Group B. Similarly, as shown in Figure 9C, the dispatch unit 172 assigns 232i to dispatch request 22c, assigns candidate vehicle 232h, which has the next highest vehicle priority after candidate vehicle 232i, to dispatch request 22e, and assigns candidate vehicle 232f, which has the next highest vehicle priority after candidate vehicle 232h, to dispatch request 22b. Thus, the combinations in which candidate vehicles 232f, 232i, and 232h are assigned to dispatch requests 22b, 22c, and 22e are designated as Pair Group C. Similarly, as shown in Figure 9D, the dispatch unit 172 assigns 232i to dispatch request 22e, assigns candidate vehicle 232h, which has the next highest vehicle priority after candidate vehicle 232i, to dispatch request 22b, and assigns candidate vehicle 232e, which has the next highest vehicle priority after candidate vehicle 232i, to dispatch request 22c. The combination of assigning candidate vehicles 232h, 232e, and 232i to dispatch requests 22b, 22c, and 22e in this way is called pair group D. In this way, in each pair group A to D, it is possible to avoid the duplicate assignment of candidate vehicle 232, which has the highest vehicle priority, to dispatch requests 22b, 22c, and 22e.

[0053] The dispatch unit 172 calculates, for example, the estimated arrival times of the vehicles at the pick-up location for all combinations of the dispatch request 22 and the candidate vehicle 232 for each pair group A to D. The dispatch unit 172 then identifies the pair group with the shorter total estimated arrival time as the matching result for the dispatch request 22 and the vehicle to be dispatched. For example, suppose that in pair groups A to D, the total estimated arrival times are in the relationship: pair group D < pair group C < pair group B < pair group A. In this case, the dispatch unit 172 identifies pair group D, which has the shorter total estimated arrival time, as the matching result. Once the dispatch unit 172's matching process identifies a pair group (for example, pair group D) as the matching result, the combinations of pair group D are reflected, and candidate vehicle 232h becomes the vehicle to be dispatched for dispatch request 22b, candidate vehicle 232e becomes the vehicle to be dispatched for dispatch request 22c, and candidate vehicle 232i becomes the vehicle to be dispatched for dispatch request 22e.

[0054] Furthermore, even after pair group D has been identified as a matching result, the dispatch unit 172 maintains the second and subsequent vehicle priorities of the candidate pair vehicles 232 associated with dispatch requests 22b, 22c, and 22e. This is because, as mentioned above, if vehicle 32, which has become the vehicle to be dispatched, is unable to accept the dispatch request for any reason, the dispatch unit extracts the candidate pair vehicle 232 with the second highest vehicle priority as the vehicle to be dispatched.

[0055] Figures 10A and 10B are explanatory diagrams illustrating the processing of the dispatch unit 172. As described above, once a pair group is identified and the pair candidate vehicle 232 with the highest vehicle priority is exclusively determined for dispatch requests 22a, 22b, 22c, and 22e, that pair candidate vehicle 232 is removed from the list of pair candidate vehicles 232 associated with other dispatch requests 22. This is because, in a single matching process, a pair candidate vehicle 232 only has one opportunity to become a dispatched vehicle. In other words, once the crew terminal control unit 174 notifies the pair candidate vehicle 232 that it has become a dispatched vehicle, it does not subsequently notify that pair candidate vehicle 232 of information indicating that it has become a dispatched vehicle for other dispatch requests 22, regardless of whether it has accepted the dispatch request 22 or not. Therefore, a pair candidate vehicle 232 that is already a dispatched vehicle for dispatch request 22 cannot become a dispatched vehicle for other dispatch requests 22. Thus, for example, candidate vehicle pairs 232b, 232h, 232e, and 232i that have been matched with dispatch requests 22a, 22b, 22c, and 22e are removed from the list of candidate vehicle pairs associated with other dispatch requests 22, as shown in Figure 10A. In this way, as shown in Figure 10B, new combinations are generated in which candidate vehicle pairs 232 are associated with each of the dispatch requests 22a to 22f in order of vehicle priority. Subsequently, the dispatch unit 172 performs matching processing on dispatch requests 22d and 22f, to which candidate vehicle pairs 232 have not yet been associated, as shown by the dashed lines in Figure 10B.

[0056] Figures 11A and 11B are explanatory diagrams illustrating the matching process. In dispatch requests 22a, 22b, 22c, and 22e, the pair candidate vehicles 232b, 232h, 232e, and 232i that were matched are removed from the pair candidate vehicle 232. In dispatch requests 22d and 22f, the pair candidate vehicle 232d, which has the highest vehicle priority, is duplicated in each case.

[0057] The dispatch unit 172 assigns the candidate vehicle 232d to one of the dispatch requests 22d and 22f in which the candidate vehicle 232d overlaps, similar to dispatch requests 22b, 22c, and 22e. Then, for the other dispatch requests 22, the dispatch unit 172 assigns candidate vehicle 232 with a lower vehicle priority until there is no overlap between the candidate vehicle 232 and the other dispatch requests 22.

[0058] For example, as shown in Figure 11A, the dispatch unit 172 assigns candidate vehicle 232d to dispatch request 22d and assigns candidate vehicle 232j, which has the next highest vehicle priority after candidate vehicle 232d, to dispatch request 22f. The combination of assigning candidate vehicles 232d and 232j to dispatch requests 22d and 22f in this way is called pair group E. Similarly, as shown in Figure 11B, the dispatch unit 172 assigns candidate vehicle 232d to dispatch request 22f and assigns candidate vehicle 232f, which has the next highest vehicle priority after candidate vehicle 232d, to dispatch request 22d. The combination of assigning candidate vehicles 232f and 232d to dispatch requests 22d and 22f in this way is called pair group F. In this way, in each pair group E and F, it is possible to avoid the duplication of assigning the candidate vehicle with the highest vehicle priority to dispatch requests 22d and 22f.

[0059] The dispatch unit 172, similar to pair groups A to D, sums the estimated arrival times of vehicle 32 at the pick-up location for all combinations of dispatch request 22 and candidate pair vehicle 232 for each pair group E and F. The dispatch unit 172 then identifies the pair group with the shorter total estimated arrival time as the matching result for the dispatch request 22 and the vehicle to be dispatched. For example, suppose that in pair groups E and F, the total estimated arrival times are less than those of pair group F. In this case, the dispatch unit 172 identifies pair group E, which has a shorter total estimated arrival time, as the matching result. Once the dispatch unit 172's matching process identifies a pair group (for example, pair group E) as the matching result, the combinations of pair group E are reflected, and candidate pair vehicle 232d becomes the vehicle to be dispatched for dispatch request 22d, and candidate pair vehicle 232j becomes the vehicle to be dispatched for dispatch request 22f.

[0060] Furthermore, if vehicle 32, which has been designated as a vehicle to be dispatched, is unable to accept the dispatch request for any reason, the dispatch unit 172 extracts the pair candidate vehicle 232, which has the second highest vehicle priority, as the vehicle to be dispatched. Therefore, even after pair group E has been designated as a matching result, the vehicle priority of the pair candidate vehicle 232 associated with dispatch requests 22d and 22f is maintained, just as when pair group D has been designated as a matching result.

[0061] Figures 12A and 12B are explanatory diagrams illustrating the processing of the dispatch unit 172. As described above, once the pair group E is identified and the pair candidate vehicle 232 with the highest vehicle priority is exclusively determined for dispatch requests 22d and 22f, that pair candidate vehicle 232 is removed from the pair candidate vehicles 232 associated with the other dispatch requests 22. In this way, for example, pair candidate vehicles 232d and 232j that were matched with dispatch requests 22d and 22f are removed from the pair candidate vehicles 232 associated with the other dispatch requests 22, as shown in Figure 12A. Thus, as shown in Figure 12B, new combinations are generated in which pair candidate vehicles 232 are associated with each of the dispatch requests 22a to 22f in order of vehicle priority.

[0062] When the matching process of the dispatch unit 172 identifies pairs (for example, pair group D, pair group E) as matching results, candidate pair vehicle 232b becomes the vehicle to be dispatched for dispatch request 22a, candidate pair vehicle 232h becomes the vehicle to be dispatched for dispatch request 22b, candidate pair vehicle 232e becomes the vehicle to be dispatched for dispatch request 22c, candidate pair vehicle 232d becomes the vehicle to be dispatched for dispatch request 22d, candidate pair vehicle 232i becomes the vehicle to be dispatched for dispatch request 22e, and candidate pair vehicle 232j becomes the vehicle to be dispatched for dispatch request 22f.

[0063] Here, we have explained an example in which the dispatching unit 172 performs matching processing to ensure that the pair candidate vehicle 232 with the highest vehicle priority does not overlap between dispatch requests 22. However, as can be understood by referring to Figure 12B, there may be cases where the pair candidate vehicle 232 with the second highest vehicle priority (for example, pair candidate vehicle 232c or pair candidate vehicle 232f) overlaps. In this case, if the pair candidate vehicle 232 with the second highest vehicle priority overlaps between dispatch requests 22, the dispatching unit 172 may choose not to perform matching processing for that pair candidate vehicle 232. This is for the following reason: The pair candidate vehicle 232 with the highest vehicle priority is assigned as the vehicle to be dispatched to dispatch request 22, and the pair candidate vehicle 232 with the second highest vehicle priority is merely a backup in case the pair candidate vehicle 232 with the highest vehicle priority does not accept dispatch request 22. Nevertheless, if the pair candidate vehicle 232 with the second highest vehicle priority is exclusively associated with dispatch request 22, it may result in inefficient dispatching.

[0064] For example, in dispatch requests 22a and 22f in Figure 12B, the candidate vehicle 232 with the second highest vehicle priority is candidate vehicle 232c. Suppose the dispatch unit 172 performs a matching process between dispatch requests 22a and 22f and candidate vehicle 232c with the second highest vehicle priority. For example, for dispatch request 22a, it selects candidate vehicle 232c as candidate vehicle 232, and for dispatch request 22f, it excludes candidate vehicle 232c and changes the candidate vehicle 232 with the second highest priority to candidate vehicle 232f. Then, the candidate pair vehicles 232 for dispatch request 22a become {232b, 232c, 232a, ...} in order of vehicle priority, and the candidate pair vehicles 232 for dispatch request 22f become {232j, 232f, 232g, ...} in order of vehicle priority, with candidate pair vehicle 232c being removed.

[0065] Here, for example, suppose that in response to dispatch request 22a, the candidate vehicle pair 232b, which has the highest vehicle priority, accepts the dispatch request, and that the candidate vehicle pair 232j, which also has the highest vehicle priority, does not accept dispatch request 22f. In this case, candidate vehicle pair 232c, which has the second highest vehicle priority, will not be the vehicle to be dispatched for dispatch request 22a, but candidate vehicle pair 232f, which has the second highest vehicle priority, will be the vehicle to be dispatched for dispatch request 22f. However, for dispatch request 22f, candidate vehicle pair 232c, which has a higher vehicle priority than candidate vehicle pair 232f, should ideally be the vehicle to be dispatched. Thus, when it is unclear whether candidate vehicle pair 232, which has the highest vehicle priority, will accept dispatch request 22, it is not advisable to match candidate vehicle pair 232, which has the second highest vehicle priority.

[0066] Therefore, the dispatch unit 172 does not perform matching processing for candidate vehicle pairs 232 other than the candidate vehicle pair 232 with the highest vehicle priority, and allows for overlapping candidate vehicle pairs 232 between dispatch requests 22. In this way, even if the candidate vehicle pair 232 with the highest vehicle priority does not accept the dispatch request 22, it is possible to appropriately assign the candidate vehicle pair 232 with the second highest vehicle priority.

[0067] Furthermore, if the dispatch unit 172 does not perform matching processing for any candidate vehicle 232 other than the candidate vehicle 232 with the highest vehicle priority, then multiple candidate vehicle 232 may become eligible for dispatch for the dispatch request 22. For example, in the example in Figure 12B, candidate vehicle 232b, which is matched with dispatch request 22a, may not accept dispatch request 22a, and candidate vehicle 232j, which is matched with dispatch request 22f, may also not accept dispatch request 22f. In this case, the candidate vehicle 232 with the second highest vehicle priority in both dispatch requests 22a and 22f will be candidate vehicle 232c.

[0068] However, it is unlikely, or extremely unlikely, that the timing at which candidate vehicle 232b rejects dispatch request 22a and the timing at which candidate vehicle 232j rejects dispatch request 22f will be exactly the same. In this case, the dispatch management server 50 assigns candidate vehicle 232, which has the second highest vehicle priority, as the vehicle to be dispatched to dispatch request 22, which was rejected first, and removes candidate vehicle 232 from the list of candidate vehicles 232 associated with other dispatch requests 22. For example, suppose candidate vehicle 232b, which was matched with dispatch request 22a, rejects dispatch request 22a, and then candidate vehicle 232j, which was matched with dispatch request 22f, also rejects dispatch request 22f. In this case, the dispatch management server 50 assigns candidate vehicle 232c as the vehicle to be dispatched to dispatch request 22a, which was rejected first, and removes candidate vehicle 232c from the list of candidate vehicles associated with dispatch request 22f. In this way, for example, candidate vehicle 232c will not be selected as the vehicle to be dispatched for dispatch request 22f, so candidate vehicle 232 will not be selected as the vehicle to be dispatched for any dispatch request 22.

[0069] Furthermore, the matching algorithm between the dispatch request 22 and the candidate vehicle pair 232 is not limited to this case; it is sufficient that at least one candidate vehicle pair 232 in each dispatch request 22, in particular the candidate vehicle pair 232 with the highest vehicle priority, does not overlap with the candidate vehicle pair 232 with the highest vehicle priority in other dispatch requests 22, and various matching algorithms can be applied. For example, the dispatch unit 172 estimates the estimated arrival time of the vehicle to the pick-up location for all combinations of the dispatch request 22 and the candidate vehicle pair 232 for each of the multiple pair groups A to D (or pair groups E, F). The dispatch unit 172 may then identify the pair group with the shorter estimated arrival time among pair groups A to D (or pair groups E, F) for each pair group A to D (or pair groups E, F). Furthermore, the dispatch unit 172 may sum the distances (travel distances) to the pick-up location of each vehicle for all combinations of the dispatch request 22 and the candidate vehicle 232 for each pair group A to D (or pair groups E and F). In this case, the dispatch unit 172 identifies the pair group with the shortest total distance as the matching result. Note that an existing matching algorithm may be used as the matching algorithm between the dispatch request 22 and the candidate vehicle 232.

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

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

[0072] If, for any reason, driver 3 is unable to accept the dispatch request 22, driver 3 will either tap the "Reject Request" button displayed on the input device 136 of the crew terminal 30 to reject the dispatch request 22, or will not tap the position corresponding to "Accept Request". The crew terminal control unit 174 waits for a predetermined time (for example, 10 seconds) from the time the dispatch target notification is sent, and if it does not receive information regarding acceptance of the dispatch request 22 (acceptance response) from the crew terminal 30 during this waiting time, it determines that the driver 3 of the dispatch target vehicle did not accept the dispatch request 22. In this case, the dispatch unit 172 determines the vehicle 32 with the second highest vehicle priority among the vehicles 32 associated with the dispatch request 22 in the matching process S6 as the new dispatch target vehicle. Next, the crew terminal control unit 174 notifies the crew terminal 30 of the other vehicle 32 that has become a dispatch target vehicle of information (dispatch target notification) indicating that it has become a dispatch target vehicle.

[0073] (Vehicle dispatch completion notification process S9) When the crew terminal control unit 174 receives information regarding the acceptance of the dispatch request 22 (acceptance response) from the crew terminal 30, it confirms the dispatch of the vehicle to be dispatched for the dispatch request 22 and sends a dispatch completion notification to the crew terminal 30 indicating that the dispatch has been confirmed. At this time, the display device 134 of the crew terminal 30 displays information regarding the dispatch request 22, such as the pick-up location and the route to the pick-up location. With this configuration, the driver 3 of the vehicle 32 can grasp the information regarding the dispatch request 22, drive the appropriate route toward the pick-up location, and find the user 2 early. If the vehicle to be dispatched is a vehicle with specific requirements (NRS vehicle or specific vehicle), the crew terminal control unit 174 may display other information on the display device 134 as information regarding the dispatch request 22, such as the drop-off location in addition to the pick-up location.

[0074] (User dispatch completion notification process S10) When the user terminal control unit 170 confirms the dispatch of a vehicle for the dispatch request 22, it sends a dispatch completion notification to the user terminal 20 indicating that the dispatch has been confirmed. At this time, the display device 124 of the user terminal 20 shows the location of the vehicle 32 that has been assigned, the estimated arrival time, etc. Thus, user 2 can board vehicle 32 at the boarding location after the estimated arrival time. If the dispatch unit 172 is unable to assign a vehicle for the dispatch request 22, the dispatch request 22 will temporarily enter a dispatch failure (dispatch impossible) state. In this case, the display device 124 of the user terminal 20 will display information indicating that dispatch was not possible, and information indicating that the dispatch request 22 can be executed again. Based on this information, user 2 will execute the dispatch request 22 again.

[0075] In the dispatch service described above, information on multiple dispatch requests 22 and multiple vehicles 32 is accumulated and matched at once. By matching multiple dispatch requests 22 and multiple vehicles 32 at once in this way, the relative positions of user 2 and vehicle 32 can be comprehensively determined, enabling more efficient dispatch compared to sequentially matching each dispatch request 22 individually. In this case, by shortening the accumulation time, the frequency of dispatch matching processing (S6) can be increased, thus enabling efficient dispatch while maintaining convenience for user 2.

[0076] Below, we will describe the priority dispatch service, dispatch reservation service, and early dispatch service, which can be selectively added to the above-mentioned ride-hailing service.

[0077] (Priority ride-hailing service) There are peak hours and areas where the supply of vehicles 32 is insufficient to meet the demand for rides. In such peak hours and areas, it may not be possible to assign a vehicle 32 to a ride request 22, or even if one is assigned, the estimated arrival time may be significantly delayed. Under these circumstances, a user 2 who is in a hurry to travel by vehicle 32 may be willing to pay a small additional fee to board the vehicle 32 as soon as possible.

[0078] In such cases, User 2 can receive a priority ride-hailing service (priority pass) by paying an additional fee on top of the regular ride-hailing service fee, which will give them priority in getting a ride over other Users 2. By using this priority ride-hailing service and paying the additional fee, User 2 can board vehicle 32 earlier than if they made a regular ride-hailing request without paying the additional fee.

[0079] This priority dispatch service can be implemented by assigning a vehicle 32 to a dispatch request 22 that utilizes the priority dispatch service, prioritizing it over other dispatch requests 22. Here, the dispatch request itself is prioritized by setting a priority for the dispatch request 22. Hereafter, the priority set for a dispatch request will be referred to as the "request priority" to distinguish it from the "vehicle priority" mentioned above.

[0080] Here, based on the relationship between dispatch requests 22a to 22f and candidate pair vehicles 232a to 232j explained using Figures 7 and 8, let's assume that users 2b and 2d make dispatch requests 22b and 22d using the priority dispatch service. In this case, dispatch requests 22b and 22d will have a higher request priority than the other dispatch requests 22a, 22c, 22e, and 22f. Therefore, the dispatch unit 172 first performs a matching process for dispatch requests 22b and 22d, which have a high request priority (request priority "high"), so that the candidate pair vehicle 232 with the highest vehicle priority does not overlap between them.

[0081] Figures 13A to 13C are explanatory diagrams illustrating the processing of the dispatch unit 172. First, as shown in Figure 13A, the dispatch unit 172 extracts multiple dispatch requests 22b and 22d with a "high" request priority and performs a matching process. It assigns the pair candidate vehicle 232i with the highest vehicle priority to dispatch request 22b, and the pair candidate vehicle 232d with the highest vehicle priority to dispatch request 22d. Then, as indicated by the "×", the dispatch unit 172 removes the pair candidate vehicles 232i and 232d that were assigned to the other dispatch requests 22b and 22d from the pair candidate vehicles 232 of dispatch requests 22a to 22f.

[0082] Next, as shown in Figure 13B, the dispatch unit 172 extracts multiple dispatch requests 22a, 22c, 22e, and 22f with a "low" request priority and performs a matching process. It assigns the pair candidate vehicle 232b, which has the highest vehicle priority, to dispatch request 22a, the pair candidate vehicle 232e, which has the highest vehicle priority, to dispatch request 22c, the pair candidate vehicle 232h, which has the highest vehicle priority, to dispatch request 22e, and the pair candidate vehicle 232j, which has the highest vehicle priority, to dispatch request 22f. Then, as indicated by the "×", the dispatch unit 172 removes the pair candidate vehicles 232b, 232e, 232h, and 232j that were assigned to the other dispatch requests 22a, 22c, 22e, and 22f from the pair candidate vehicles 232 of dispatch requests 22a to 22f.

[0083] Thus, as shown in Figure 13C, candidate vehicle 232b becomes the vehicle to be dispatched for dispatch request 22a, candidate vehicle 232i becomes the vehicle to be dispatched for dispatch request 22b, candidate vehicle 232e becomes the vehicle to be dispatched for dispatch request 22c, candidate vehicle 232d becomes the vehicle to be dispatched for dispatch request 22d, candidate vehicle 232h becomes the vehicle to be dispatched for dispatch request 22e, and candidate vehicle 232j becomes the vehicle to be dispatched for dispatch request 22f.

[0084] Here, it can be seen that for ride requests 22b and 22d, which have a request priority set to "high," the pair candidate vehicles 232i and 232d, which have the highest vehicle priority, are assigned. In this way, users 2b and 2d, who made ride requests 22b and 22d using the priority ride service, are able to board vehicle 32 earlier than with a regular ride request.

[0085] (Ride-hailing reservation service) In addition, User 2 can also receive a ride-hailing reservation service (AI reservation) by paying an additional fee on top of the regular ride-hailing service fee, which allows them to reserve a vehicle 32 in advance by specifying their desired pick-up location and pick-up time.

[0086] In this ride-hailing reservation service, when a user 2 submits a ride-hailing request 22 using the ride-hailing reservation service, the vehicle 32 is not dispatched at the time the request 22 is received. That is, at this point, the vehicle 32 that will carry user 2 has not yet been determined. Then, at the dispatch start time, which is the dispatch operation time (for example, 15 minutes) before the boarding time, the dispatch unit 172 performs a matching process together with other ride-hailing requests 22 in the aforementioned ride-hailing service. Here, the dispatch start time is the time when dispatching begins based on the ride-hailing request 22 using the ride-hailing reservation service. When the dispatch start time arrives, the dispatch unit 172 of the dispatch management server 50 adds the ride-hailing request 22 using the ride-hailing reservation service to the ride-hailing requests 22 extracted in the ride-hailing request extraction process S3 of the ride-hailing service, and identifies the vehicle to be dispatched through the vehicle extraction process S4, pair generation process S5, and matching process S6. Then, in the vehicle dispatch completion notification process S9, the crew terminal control unit 174 sends a dispatch completion notification to the crew terminal 30 indicating that the dispatch has been confirmed. Upon receiving the dispatch completion notification, the vehicle 32 proceeds to the boarding location. In this way, the dispatch operation time is the maximum time required for the dispatched vehicle to arrive at the designated boarding location, starting from the dispatch start time.

[0087] Furthermore, the dispatch unit 172 can set a high priority for dispatch requests 22 using the dispatch reservation service, similar to the priority dispatch service. In this way, the dispatch management server 50 can appropriately dispatch a vehicle 32 to the specified pick-up location and pick-up time.

[0088] Thus, in this ride-hailing reservation service, the dispatch unit 172 does not pre-determine which vehicle 32 will pick up user 2, but performs matching processing before the pick-up time (dispatch start time). As a result, depending on the operating status of vehicles 32 near the pick-up location at the dispatch start time, it is possible that no vehicle 32 will be available to arrive at the pick-up location by the pick-up time. While this ride-hailing reservation service strives to have a vehicle 32 on the way to the pick-up location by the pick-up time, it does not guarantee the pick-up time.

[0089] Figure 14 is a flowchart illustrating the operation of the dispatch management server 50 in the ride-hailing reservation service. Note that the processing based on this ride-hailing reservation service is executed in parallel for multiple users 2.

[0090] (Step S100) The user terminal control unit 170 of the dispatch management server 50 determines whether or not a dispatch request 22 using the dispatch reservation service has been received from the user terminal 20. If no dispatch request 22 using the dispatch reservation service has been received, the process in step S100 is repeated. If a dispatch request 22 has been received, the process moves to step S101.

[0091] In a ride-hailing request 22 using the ride-hailing reservation service, at least the desired pick-up location and pick-up time are set by user 2's specified operation. In addition to the pick-up location and pick-up time, the ride-hailing request 22 using the ride-hailing reservation service may also include setting items such as drop-off location, payment information, ride-hailing category, taxi operator, vehicle attributes, toll road information, and ride-sharing permission information.

[0092] (Step S101) The user terminal control unit 170 determines whether the difference between the time a ride request 22 using the ride reservation service is received and the time of boarding is greater than or equal to a predetermined acceptance tolerance time (for example, 20 minutes). The acceptance tolerance time is a sufficiently long time that does not fall short of the time required to identify a vehicle to be dispatched in response to the ride request 22 and for the vehicle 32 to arrive at the boarding location. If the difference between the time a ride request is received and the boarding time is less than the acceptance tolerance time, the user terminal control unit 170 returns to processing from step S100 without accepting the ride request 22, assuming that even if the ride request 22 is accepted, there is a possibility that the vehicle 32 may not be able to arrive at the boarding location at the boarding time. On the other hand, if the difference between the time a ride request 22 is received and the boarding time is greater than or equal to the acceptance tolerance time, the user terminal control unit 170 moves to step S102.

[0093] (Step S102) The dispatch unit 172 of the dispatch management server 50 performs a supply and demand simulation based on the pick-up location and pick-up time included in the pick-up request 22 using the pick-up reservation service, and derives the probability of availability if dispatching is started at the dispatch start time. Here, the probability of availability is the probability that a vehicle to be dispatched will be identified within the dispatch operation time and that the vehicle 32 that has been dispatched will be able to arrive at the pick-up location. The dispatch operation time is set to, for example, 15 minutes. Here, the dispatch unit 172 determines, for example, whether it can secure more vehicles 32 than the total number of pick-up requests 22 received from one or more users 2, including user 2 who made the pick-up request 22 using the pick-up reservation service, through the probability of availability.

[0094] Specifically, the dispatch unit 172 performs supply and demand simulations using statistical information. The statistical information associates the average number of vehicles supplied and the actual travel time for each date, day of the week, time of day, and area range in the past. Here, the area range is, for example, a region where the service area is divided into predetermined areas (e.g., 2km x 2km). The average number of vehicles supplied is the average number of dispatchable vehicles 32 included in a predetermined range (e.g., a circle with a radius of 5km) centered on the area range. The actual travel time is the travel time required for a dispatched vehicle to be dispatched with a predetermined probability (e.g., the 95th percentile) for each date, day of the week, time of day, and area range.

[0095] The dispatch unit 172 extracts, based on statistical information, the average number of vehicles supplied and the actual travel time in the past, associated with the area range including the boarding location, for the time period of the month, day, or day of the week that includes the boarding time. Based on the average number of vehicles supplied and the actual travel time, the dispatch unit 172 derives the estimated travel time, which is the estimated travel time required for dispatching a vehicle. For example, even if the actual travel time is the same, the estimated travel time will be shorter if the average number of vehicles supplied is high. The dispatch unit 172 derives the number of vehicles 32 that can be dispatched within the difference time obtained by subtracting the estimated travel time from the dispatch operation time.

[0096] The dispatch unit 172 then derives the probability of dispatch availability based on the ratio of the actual number of dispatch requests 22 received within the past time difference to the number of available vehicles. For example, if the actual number of dispatch requests 22 > the number of available vehicles, the probability of dispatch availability is expressed as (number of available vehicles / actual number of dispatch requests 22), and if the actual number of dispatch requests 22 ≤ the number of available vehicles, the probability of dispatch availability is 100%.

[0097] In this explanation, we have used an example of supply and demand simulation in which statistical information is referenced to derive the probability of vehicle availability based on the boarding location and time of boarding. However, supply and demand simulations are not limited to this example; various methods can be employed to derive an indicator of whether or not a vehicle will be available at the boarding location at a future boarding time.

[0098] (Step S103) The dispatch unit 172 determines whether the probability of dispatching a vehicle is equal to or greater than a threshold (for example, 95%). If the probability of dispatching a vehicle is equal to or greater than the threshold, the process moves to step S104. If the probability of dispatching a vehicle is less than the threshold, the system determines that it is not possible to dispatch a vehicle to the pick-up location at the pick-up time, and the process from step S100 is repeated. If the probability of dispatching a vehicle is less than the threshold, the dispatch management server 50 may send information to the user terminal 20 indicating that it cannot guarantee the dispatch request 22 using the dispatch reservation service, or it may send to the user terminal 20 alternative pick-up times that are different from the pick-up time requested by user 2, but where the probability of dispatching a vehicle is equal to or greater than the threshold.

[0099] (Step S104) The dispatch unit 172 derives the dispatch start time by subtracting the dispatch operation time from the boarding time. In the example above, the dispatch operation time is given as 15 minutes, but it may be arbitrarily determined between 10 and 20 minutes, not limited to this example. The dispatch unit 172 increases or decreases the dispatch operation time depending on the driving environment, such as weather, temperature, and congestion due to events. For example, the dispatch unit 172 may set the dispatch operation time to be longer when the weather forecast is rain or snow, when congestion is expected due to an event, or during times when the vehicle 32 is likely to be hailed by passengers.

[0100] (Step S105) The dispatch unit 172 determines whether the current time has reached the dispatch start time. If the dispatch start time has been reached, the process moves to step S106; otherwise, the process in step S105 is repeated.

[0101] (Step S106) When the current time reaches the dispatch start time, the dispatch unit 172 performs a matching process together with the dispatch requests 22 that have been generated in the same service area up to that execution time.

[0102] Furthermore, the dispatch unit 172 may, as explained using Figure 13, set the request priority of the dispatch request 22 using the dispatch reservation service to "high" before executing the matching process, similar to the priority dispatch service. In this case, if a dispatch request 22 using the dispatch reservation service and a dispatch request 22 using the priority dispatch service overlap, the dispatch unit 172 may set the request priority of the dispatch request 22 using the dispatch reservation service higher than that of the dispatch request 22 using the priority dispatch service before executing the matching process. With this configuration, the dispatch management server 50 can more reliably dispatch the vehicle 32 by the time of boarding desired by the user 2. Furthermore, the dispatch unit 172 may set the request priority of the dispatch request 22 using the dispatch reservation service to be equal to that of the dispatch request 22 using the priority dispatch service before executing the matching process. Alternatively, the dispatch unit 172 may set the request priority of the dispatch request 22 using the dispatch reservation service lower than that of the dispatch request 22 using the priority dispatch service before executing the matching process.

[0103] (Step S107) The crew terminal control unit 174 sends a dispatch notification to the vehicle 32 that has been designated as the vehicle to be dispatched in response to the dispatch request 22. Upon receiving an acceptance response from the crew terminal control unit 174, the dispatch of the vehicle to be dispatched in response to the dispatch request 22 is confirmed.

[0104] (Step S108) When the user terminal control unit 170 confirms the dispatch of a vehicle for the dispatch request 22, it sends a dispatch completion notification to the user terminal 20 indicating that the dispatch has been confirmed.

[0105] Furthermore, the ride-hailing reservation service may provide incentives such as points or wages to the drivers 3 of the 32 vehicles that have accepted the dispatch notification.

[0106] In this ride-hailing reservation service, a vehicle is not dispatched at the time of the request, nor is the vehicle 32 that will carry user 2 specified at the time of the request. Therefore, vehicle 32 is not restricted in its normal operations by the obligation to head to the pick-up location at the pick-up time, and can respond to the pick-up notification as in a normal ride-hailing service. Thus, the time efficiency and regional efficiency of vehicle 32's operations can be improved.

[0107] Furthermore, the ride-hailing reservation service only accepts ride requests 22 if the probability of a ride being available is above a certain threshold. Therefore, it is possible to minimize situations where a ride request 22 is accepted, but the vehicle 32 does not arrive at the pick-up location at the desired pick-up time.

[0108] Furthermore, in the ride-hailing reservation service, for each ride request 22 using the ride-hailing reservation service, the dispatch operation time required for the vehicle 32 to arrive at the pick-up location is appropriately set, and the dispatch start time is set by calculating backward from the pick-up time and the dispatch operation time. Therefore, the vehicle 32 can be dispatched to the pick-up location stably and efficiently at the desired pick-up time.

[0109] Furthermore, by setting the request priority to "high" in the vehicle matching process, it becomes possible to dispatch vehicles earlier and more reliably than with a normal dispatch request 22.

[0110] In the embodiment described above, an example was given in which the positional relationship between the pick-up location and the vehicle 32 is comprehensively judged within the dispatch operation time to enable early dispatch to the pick-up location. However, in such a case, the vehicle 32 is likely to arrive at the pick-up location in an estimated travel time shorter than the dispatch operation time. Furthermore, if the dispatch unit 172 sets the request priority of the dispatch request 22 using the dispatch reservation service to "high" before executing the matching process, the vehicle 32 may arrive at the pick-up location in an even shorter time. In that case, the vehicle 32 will arrive at the pick-up location earlier than the pick-up time (early arrival), and the driver will lose a business opportunity equivalent to the waiting time for the user 2 to board. Therefore, the dispatch management server 50 may provide the driver 3 with an incentive, such as points or wages, according to the difference between the time the vehicle 32 actually arrives at the pick-up location and the pick-up time.

[0111] To avoid such early arrivals, the dispatch unit 172 may, in the matching process, select a vehicle 32 that can arrive at the boarding location just before the boarding time, rather than the vehicle 32 that will arrive at the boarding location the earliest. Specifically, for example, in step S106, the dispatch unit 172 sets the request priority of the dispatch request 22 using the dispatch reservation service to "high," as explained with reference to Figure 13. Subsequently, the dispatch unit 172 may match the dispatch request 22 with a candidate vehicle 232 from among multiple candidate vehicle pairs 232 whose estimated arrival time is less than or equal to the dispatch operation time and which is closest to the boarding time. With this configuration, the vehicle 32 will arrive at the boarding location near the boarding time or a few minutes before the boarding time. Therefore, the dispatch management server 50 can dispatch the vehicle 32 without making the vehicle 32 wait for a long time and in a way that ensures it arrives on time for the boarding.

[0112] (Early dispatch service) As described above, User 2 can request a ride 22 for vehicle 32 through the user application on the user terminal 20. Alternatively, User 2 can hail a vehicle 32 that is cruising for fares and get in. Hereinafter, the act of User 2 requesting a ride 22 for vehicle 32 through the user application may be referred to as "app-based ride dispatch," and the act of getting into a vehicle 32 that is cruising for fares may be referred to as "cruising ride."

[0113] Compared to hailing a ride on the street, app-based ride-hailing requires a fee for using the user application to request a ride 22, as well as a pick-up fee for the vehicle 32 to travel to the pick-up location.

[0114] However, there are also problems when user 2 tries to hail a taxi on the street. For example, user 2 has to find a vehicle 32 that is cruising for fares outdoors, but depending on the season and weather, being outdoors itself may be unpleasant. Also, the routes of vehicles 32 that are cruising for fares are not fixed, so user 2 may not be able to find a vehicle 32 that is cruising for fares right away. Furthermore, even if user 2 does find a vehicle 32, user 2 has to hail the vehicle 32 at the right time, and the vehicle 32 may be traveling on a route that does not allow it to stop at user 2's location, or it may not be the taxi company or vehicle type that user 2 wanted. In addition, user 2 has the inconvenience of having to verbally tell the driver 3 their destination after getting into vehicle 32.

[0115] Furthermore, there are problems not only with the passenger experience of cruising for rides, but also with the functionality of cruising for rides. For example, with cruising for rides, it is not possible to set the payment method before getting off, rides do not count towards the loyalty program (described later), and only paper receipts are available.

[0116] In contrast, with app-based ride-hailing, user 2 can complete their ride request 22 indoors and secure a vehicle 32 of their preferred taxi company and vehicle type. Furthermore, vehicle 32 can stop at the desired pick-up location and may even wait a short time, ensuring user 2 can board vehicle 32 at the pick-up location. User 2 can also set their drop-off location and payment method through the user application before arrival, and can participate in loyalty program accrual and obtain electronic receipts.

[0117] Thus, while app-based ride-hailing requires a small additional fee compared to hailing a taxi on the street, it is superior in terms of both the ride itself and its functionality. However, some users (2) may hesitate to use app-based ride-hailing because they believe they can get a ride more quickly with a vehicle (32) that is hailing on the street. Therefore, it is desirable to shorten the time required to board a taxi using app-based ride-hailing so that users (2) recognize that app-based ride-hailing is also more advantageous in terms of time than hailing a taxi on the street.

[0118] Therefore, we propose an expedited dispatch service in which the estimated arrival time from User 2's dispatch request 22 to arrival at the pick-up location is within a predetermined target time (e.g., 5 minutes). Here, 5 minutes is given as the target time, but it may be arbitrarily determined on a case-by-case basis depending on the service area or taxi company. Furthermore, the target time may differ from the time presented to User 2 in the expedited dispatch service. For example, the expedited dispatch service may state that arrival at the pick-up location will be within 5 minutes, but in reality, the target time may be shorter than 5 minutes, such as 4 minutes, to allow for a margin.

[0119] Specifically, the early dispatch service utilizes the dispatch reservation service mechanism described above, setting the dispatch operation time as the target time to ensure dispatch within that time. Furthermore, the matching process also utilizes the mechanism for setting request priority using the priority dispatch service described above. The dispatch management server 50 then determines whether dispatch is possible within the target time and provides the early dispatch service only if dispatch is possible within that timeframe.

[0120] By providing an early dispatch service, even in situations where user 2 might think that a vehicle 32 cruising for fares would be available sooner, it becomes possible to make them realize that app-based dispatch offers a quicker ride. Therefore, it is possible to encourage user 2 to use app-based dispatch.

[0121] Figure 15 is a flowchart illustrating the operation of the dispatch management server in the early dispatch service. Note that the processing based on this early dispatch service is executed in parallel for multiple users 2. Furthermore, this example explains the service without restricting which users 2 are eligible to receive the early dispatch service. However, as will be discussed later, the early dispatch service may be restricted to users 2 with higher user ranks or users 2 with a subscription plan.

[0122] (Step S200) The user terminal control unit 170 determines whether user 2 has performed a start operation. A start operation is, for example, an operation in which user 2 launches a user application. If it is determined that user 2 has performed a start operation, the process moves to step S201; if it is determined that user 2 has not performed a start operation, the process in step S200 is repeated.

[0123] Here, the operation to initiate the early dispatch service is defined as, for example, the operation by user 2 to launch the user application. This is because it is assumed that when user 2 attempts to make a dispatch request 22, they will first launch the user application. By limiting the trigger for initiating the early dispatch service to the operation to launch the user application in this way, the processing load on the dispatch management server 50 can be reduced. However, if, after the user application has been launched, it is running in the background (the user application has not been killed, and another application is running in the foreground), and then switched to running in the foreground by an operation by user 2, it is not considered that user 2 is actively attempting to make a dispatch request 22, so this operation may not be treated as an initiation operation.

[0124] Furthermore, the start operation is not limited to launching a user application; various triggers performed within the user application, such as screen switching or information update operations, can be adopted. For example, if User 2 launches a user application and the top screen is displayed, then the start operation could be an operation in which User 2 switches from the top screen to the main screen for receiving the ride-hailing service (for example, the screen shown in Figure 16A described later) (including operations that result in a screen switch), an operation in which User 2 switches from the main screen to another screen (for example, the screen shown in Figure 16B described later), or an operation in which another screen is called up. Furthermore, User 2 may choose to initiate the process by performing any of the following actions: a preliminary action to input some information (e.g., a boarding location) (e.g., tapping the boarding location input box), an action to input some information (e.g., a boarding location), an action to identify some information (e.g., tapping a location on the map to identify it as a boarding location, or tapping or swiping to move the boarding location on the map), an action to select some information (e.g., a boarding location), or an action to confirm some information (e.g., a boarding location) (e.g., pressing a button to indicate confirmation when the boarding location has been identified).

[0125] Furthermore, the dispatch request unit 160 of the user terminal 20 transmits the current location of user 2, i.e., the current location of user terminal 20, to the dispatch management server 50 as the boarding location in response to the start operation. At this time, the dispatch request unit 160 may identify a location where the vehicle 32 closest to the current location of user terminal 20 can stop (for example, a road near the current location, or, if the current location is inside a facility or building, a designated stopping location within the facility or building), and transmit this location, instead of the current location of user terminal 20, to the dispatch management server 50 as the boarding location. Furthermore, if User 2 has individually registered "favorite locations" as candidates for pick-up and drop-off locations through the user application, the dispatch request unit 160 may, if there are one or more "favorite locations" within a predetermined range (for example, 80m) from the current location of User Terminal 20, send the closest "favorite location," a pre-specified "favorite location," or the "favorite location" used in the previous dispatch request 22 to the dispatch management server 50 as the pick-up location. Alternatively, if the pick-up location and current location are to be transmitted separately, the dispatch request unit 160 may send the current location of User Terminal 20 directly to the dispatch management server 50.

[0126] Furthermore, the dispatch request unit 160 may send the updated pick-up location to the dispatch management server 50 each time the pick-up location is updated by user 2's operation. The dispatch unit 172 may, in step S200, assume that a start operation has been performed each time the pick-up location is updated by user 2's operation and proceed to step S201. In this way, the dispatch unit 172 can determine whether the vehicle 32 can arrive at the pick-up location within the target time with a predetermined probability or higher based on the latest pick-up location requested by user 2, and dispatch the vehicle 32 more appropriately within the target time.

[0127] Alternatively, the dispatch unit 172 may determine that only the operation in which user 2 launches the user application is a start operation and proceed to step S201, and even if the pick-up location is updated thereafter, it may determine that no start operation has been performed and not proceed to step S201. In this way, user 2 can understand that they can receive the early dispatch service immediately after launching the user application and can decide early whether or not to make a dispatch request 22.

[0128] (Step S201) The dispatch unit 172 estimates the dispatch status if a dispatch request 22 is made immediately in response to the user application's start operation. The dispatch unit 172 considers the time obtained by adding the target time (dispatch operation time) to the current time as the boarding time, and considers the time prior to the boarding time, i.e., the current time, as the dispatch start time. If the boarding location received from the user terminal 20 is a place where the vehicle 32 cannot stop, the dispatch unit 172 may use the nearest place where the vehicle 32 can stop or a "favorite location" registered in association with the user terminal 20 as the boarding location. Furthermore, if the location information included in the dispatch request 22 received from the user terminal 20 indicates the current location of user 2, i.e., the current location of the user terminal 20, the dispatch unit 172 considers the received current location as the boarding location. Furthermore, if the received current location is a place where vehicle 32 cannot stop, the dispatch unit 172 may consider the nearest location where vehicle 32 can stop or a "favorite location" as the pick-up location. In any case, for the purpose of performing matching processing with other dispatch requests 22, the dispatch unit 172 replaces the current location with the pick-up location and proceeds with the processing.

[0129] The dispatch unit 172 then performs a supply and demand simulation based on the pick-up location and pick-up time, and derives the probability of a vehicle being available. Since the supply and demand simulation and the probability of vehicle availability are substantially the same as those described in the above-mentioned ride-hailing reservation service, a detailed explanation is omitted here.

[0130] However, while the ride-hailing reservation service was explained using an example where the dispatch operation time is set to approximately 15 minutes, the early dispatch service sets a shorter target time, such as 5 minutes. Therefore, the range of vehicles 32 that are targeted when performing the supply and demand simulation is limited to a narrow range in which vehicles 32 can reach the pick-up location within the target time.

[0131] Therefore, the dispatch unit 172 derives the average number of vehicles supplied and the actual travel time from the statistical information, after excluding information on vehicles 32 whose dispatch time was longer than the target time. In the early dispatch service, the predetermined probability used to derive the actual travel time may be different from the predetermined probability in the dispatch reservation service. For example, in the early dispatch service, the predetermined probability is set to the 99th percentile. Based on the derived average number of vehicles supplied and the actual travel time, the dispatch unit 172 estimates the estimated travel time required for dispatch. The dispatch unit 172 derives the number of vehicles 32 that can be dispatched within the difference time obtained by subtracting the estimated travel time from the target time (dispatch operation time). Then, the dispatch unit 172 derives the probability of dispatch availability from the ratio of the actual number of dispatch requests 22 received within the difference time in the past to the number of vehicles that can be dispatched. Here, because the range of target vehicles 32 is limited, the probability of dispatch availability tends to be lower than in the dispatch reservation service. At this point, since the dispatch request 22 has not yet been received, the dispatch department 172 does not perform the actual matching process.

[0132] (Step S202) In addition to supply and demand simulations, the dispatch unit 172 performs dispatch simulations based on dispatch requests 22 and the dispatch status of vehicles 32 in the vicinity of the pick-up location (for example, the current location of user 2) at the current time. The dispatch unit 172 defines the number of vehicles 32 that are included in a predetermined range (for example, a circle with a radius of 2 km) centered on the pick-up location, within which the vehicles 32 can reach the pick-up location within the target time, as the current supply. The dispatch unit 172 also defines the current travel time as the travel time required for the vehicle 32 to be dispatched with a predetermined probability (for example, the 99th percentile).

[0133] The dispatch unit 172 estimates the estimated travel time required for dispatching a vehicle based on the current supply and current travel time. For example, even if the current travel time is the same, the estimated travel time will be shorter if the current supply is large. The dispatch unit 172 derives the number of user terminals 20 that have launched their user application but have not yet made a dispatch request 22 within a predetermined range centered on the pick-up location, i.e., the number of user terminals 20 that are likely to make a dispatch request 22 within the difference time obtained by subtracting the estimated travel time from the target time. The dispatch unit 172 also derives the supply of vehicles 32 that can be dispatched within the difference time, for example, vehicles 32 whose dispatch status is "available" within a predetermined range centered on the pick-up location. The dispatch unit 172 may also include vehicles 32 whose dispatch status is "paid" or "settlement completed" within a predetermined range in the supply of available vehicles 32, as vehicles 32 whose dispatch status will become "available" in a few minutes.

[0134] The dispatch unit 172 then derives the probability of dispatching a vehicle based on the ratio of the number of planned dispatch requests to the number of available vehicles. For example, if the number of planned dispatch requests > the number of available vehicles, the probability of dispatching a vehicle is expressed as (number of available vehicles / number of planned dispatch requests), and if the number of planned dispatch requests ≤ the number of available vehicles, the probability of dispatching a vehicle is 100%.

[0135] In this explanation, we have used an example of a ride-hailing simulation in which the probability of a ride being available is derived based on the pick-up location and the current time. However, various methods can be employed in ride-hailing simulations to derive an indicator of whether or not a ride is available at the pick-up location at the pick-up time, which is calculated by adding the target time to the current time.

[0136] In the aforementioned ride-hailing reservation service, the timing of user 2's ride request 22 differs from the ride-hailing start time, so the ride-hailing status at the start time can only be estimated through supply and demand simulation. In contrast, with this early ride-hailing service, the current time is approximately the same as the ride-hailing start time, so in addition to supply and demand simulation, the ride-hailing status at the start time can be estimated through a ride-hailing simulation that takes the current situation into account. Therefore, it becomes possible to increase the accuracy of estimating the probability of a ride being available.

[0137] Furthermore, since the early dispatch service aims to dispatch vehicles within a target time, it is necessary to improve the accuracy of the dispatch simulation. For example, the dispatch unit 172 rigorously determines which lane the pickup location is on, which direction the vehicle 32 is traveling, and what route the vehicle 32 will take to get to the pickup location, and derives the current travel time with high accuracy. In this way, the accuracy of deriving the planned number of dispatch requests and the number of available vehicles 32 can be improved.

[0138] Furthermore, the dispatch unit 172 may perform a dispatch simulation considering the state of the user terminal 20 from a predetermined time (for example, 30 minutes) before the current time. For example, if the user application was launched more than a predetermined time (for example, 10 minutes) before the current time (i.e., a predetermined time has elapsed since launch), or if the user application is running in the background, the dispatch unit 172 will consider the likelihood of a dispatch request 22 to be low and will exclude from the count user terminal 20 whose user application is running but has not yet made a dispatch request 22. In this way, the accuracy of deriving the planned number of dispatch requests can be improved.

[0139] Furthermore, the dispatch unit 172 may perform a dispatch simulation considering the driving status of available vehicles 32 from a predetermined time (for example, 30 minutes) before the current time. For example, the dispatch unit 172 excludes vehicles 32 that are about to move outside a predetermined range centered on the boarding location from the vehicles 32 that can be dispatched within the difference time. Also, the dispatch unit 172 includes vehicles 32 that are not included in the predetermined range centered on the boarding location but are about to move from outside to the predetermined range as vehicles 32 that can be dispatched within the difference time. In addition, the dispatch unit 172 may include vehicles 32 that are about to move from outside to the predetermined range, even if their dispatch status is "occupied," if the disembarking location of the user 2 currently riding is within the predetermined range and the dispatch status could become "vacant" within the target time. In this way, the accuracy of deriving the number of available vehicles 32 can be improved.

[0140] (Step S203) The dispatch unit 172 determines whether the probability of dispatching a vehicle based on the supply and demand simulation is above a threshold (e.g., 99%) and whether the probability of dispatching a vehicle based on the dispatch simulation is above a threshold (e.g., 99%). If both probability of dispatching a vehicle is above the threshold, the process moves to step S204. If either probability of dispatching a vehicle is below the threshold, it is determined that dispatching a vehicle within the target time is not possible, and the process from step S200 is repeated. Note that the threshold is set higher in the early dispatch service than in the reservation service. This is to ensure that dispatching a vehicle within the target time in the early dispatch service is more strictly enforced than in the reservation service.

[0141] Here, the dispatching unit 172 compares the probability of dispatching based on the supply and demand simulation with the same threshold. However, the system is not limited to this example; the threshold for the probability of dispatching based on the dispatching simulation and the threshold for the probability of dispatching based on the supply and demand simulation may be different. Alternatively, the dispatching unit 172 may add the probability of dispatching based on the dispatching simulation and the probability of dispatching based on the supply and demand simulation and compare the result of this addition with a threshold (e.g., 198%). In this case, the dispatching unit 172 may also weight the probability of dispatching based on the dispatching simulation more highly than the probability of dispatching based on the supply and demand simulation. In this way, the influence of the probability of dispatching based on the dispatching simulation can be increased, and the probability of dispatching can be determined more rigorously.

[0142] (Step S204) If the probability of dispatching a vehicle exceeds a threshold, the user terminal control unit 170 immediately sends early dispatch availability information to the user terminal 20, which indicates that a vehicle 32 can be dispatched within the target time by making a dispatch request 22.

[0143] Figures 16A and 16B are explanatory diagrams illustrating an example of the operation of the user terminal control unit 170. When user 2 launches a user application through the user terminal 20, the user terminal control unit 170 displays the main screen shown in Figure 16A on the display device 124.

[0144] As shown in Figure 16A, the main screen displays a map of a predetermined area including the current location of user 2. The main screen also displays a message box 250. The message box 250 displays a boarding location input box 252 where the boarding location can be entered, a disembarking location input box 254 where the disembarking location can be entered, and a proceed button 256 with the message "Proceed to next". Immediately after the user application is launched, the boarding location input box 252 displays the current location of the user terminal 20 as an initial value (for example, "5-6 Toyosu, Koto-ku"). The user terminal 20 sends information indicating the boarding location (the current location of the user terminal 20 immediately after the user application is launched) displayed in the message box 250 to the dispatch management server 50. Based on the received information, the dispatch management server 50 estimates the dispatched vehicle and estimated arrival time that are most likely to be matched if a dispatch request 22 is made, and sends the estimated arrival time to the user terminal 20. Thus, as shown in Figure 16A, a message box 260 is displayed on the display device 124 of the user terminal 20, showing the estimated arrival time (for example, "boarding in approximately 3-10 minutes") when a dispatch request 22 is made.

[0145] User 2 can select the boarding location input box 252 and re-enter their desired boarding location. Alternatively, User 2 can select the disembarking location input box 254 and enter their disembarking location.

[0146] Below the message box 250, one or more tabs are displayed, including, for example, a dispatch request settings tab 262 with the message "Call Now". When the dispatch request settings tab 262 is selected and the proceed button 256 with the message "Next" is pressed, the user terminal 20 sends the information displayed in the message box 250 to the dispatch management server 50. Based on the received information, the dispatch management server 50 estimates the most likely dispatched vehicle and estimated arrival time that would be matched if a dispatch request were made, and sends the estimated arrival time to the user terminal 20. Thus, as shown in Figure 16B, a message box 270 showing the estimated arrival time if a dispatch request 22 were made is displayed on the display device 124 of the user terminal 20. At this point, when the dispatch request button 280 with the message "Call a Taxi" is pressed, the dispatch request 22 is sent to the dispatch management server 50, and the dispatch service is executed.

[0147] As described above, if the probability of a vehicle being available at the time the user application is launched (the time when information indicating the boarding location is sent to the dispatch management server 50) exceeds a threshold, the user terminal 20 receives early vehicle availability information from the dispatch management server 50. In this case, as shown in Figure 16B, an early vehicle dispatch button 282 with the message "Call in 5 minutes" appears on the display device 124 of the user terminal 20.

[0148] The message displayed on the early dispatch button 282 is not limited to "Call in 5 minutes." It can also use phrases that give the impression of faster boarding, such as "Board within 5 minutes" or "Quick dispatch." When user 2 operates the early dispatch button 282, the dispatch request unit 160 of the user terminal 20 sends a dispatch request 22 utilizing the early dispatch service to the dispatch management server 50. The dispatch management server 50 then executes the early dispatch service in response to the dispatch request 22 utilizing the early dispatch service. In this way, user 2 is able to board the vehicle 32 within the target time.

[0149] In this explanation, we have used an example where an early dispatch button 282, which allows for the dispatch of vehicle 32 within the target time, is displayed at the time of the dispatch request 22 shown in Figure 16B. However, the explanation is not limited to this example; information indicating that vehicle 32 can be dispatched within the target time may be displayed at any time or on any screen after the user application is launched.

[0150] For example, in the above explanation, an example was given in which, in response to the operation of the proceed button 256 on the main screen in Figure 16A, a message box 270 and a dispatch request button 280 are displayed as in Figure 16B, and an early dispatch button 282 appears along with them. Alternatively, as in Figure 16C, when the user application is launched, the user terminal 20 sends information indicating the boarding location (the current location of the user terminal 20 immediately after the user application is launched) to the dispatch management server 50, and when the probability of dispatching a vehicle exceeds a threshold, the user terminal 20 may make the early dispatch button 282 appear on the main screen, for example, in the message box 260. In this case, when user 2 changes the boarding location on the main screen, the user terminal 20 sends information indicating the boarding location to the dispatch management server 50 each time it is changed. Then, when the probability of dispatching a vehicle at that boarding location also exceeds a threshold, and the user terminal 20 receives early dispatch availability information from the dispatch management server 50, the early dispatch button 282 appears.

[0151] With the main screen shown in Figure 16C displayed, if user 2 operates the early dispatch button 282, the dispatch request unit 160 of the user terminal 20 may directly send a dispatch request 22 to the dispatch management server 50 to use the early dispatch service without displaying a message box 270 or the dispatch request button 280 as shown in Figure 16B. The dispatch management server 50 then executes the early dispatch service in response to the dispatch request 22 using the early dispatch service. In this way, user 2 is able to board the vehicle 32 within the target time.

[0152] Furthermore, when the main screen shown in Figure 16C is displayed and the user 2 operates the early dispatch button 282, a message box 272 displaying the message "You can make a reservation for 5 minutes from now" and a dispatch request button 280 may be temporarily displayed on the display device 124, as shown in Figure 16D. At this time, when the dispatch request button 280 is operated, the dispatch request unit 160 sends a dispatch request 22 using the early dispatch service to the dispatch management server 50. The dispatch management server 50 executes the early dispatch service in response to the dispatch request 22 using the early dispatch service. In this way, user 2 is able to board the vehicle 32 within the target time.

[0153] Furthermore, this explanation uses an example where the early dispatch button 282 is displayed when user 2 attempts to use the dispatch service. However, when user 2 attempts to use the priority dispatch service or the dispatch reservation service, a message such as "You can call a taxi in 5 minutes now" or "You can make a reservation in 5 minutes now" may be displayed near the execution button, for example in a speech bubble, to encourage the user to press the execution button. When the execution button is pressed while the message "You can make a reservation in 5 minutes now" is displayed, the dispatch request unit 160 sends a dispatch request 22 to the dispatch management server 50 to use the early dispatch service.

[0154] Furthermore, when user 2 attempts to use the priority dispatch service or the dispatch reservation service, the user terminal 20 may prompt the user to press the execute button by outputting voice guidance such as "You can call a vehicle in 5 minutes now" or "You can make a reservation in 5 minutes now." If the execute button is pressed within a predetermined time (for example, 5 seconds) after the voice "You can make a reservation in 5 minutes now" is output, the dispatch request unit 160 sends a dispatch request 22 to the dispatch management server 50 to use the early dispatch service.

[0155] (Step S205) The user terminal control unit 170 determines whether or not a dispatch request 22 using the early dispatch service has been received. If a dispatch request 22 using the early dispatch service is received, that is, if the early dispatch button 282 is operated on the user terminal 20, the process proceeds to step S206. If no dispatch request 22 has been received, the process of step S205 is repeated.

[0156] (Step S206) When a dispatch request 22 utilizing the early dispatch service is received, the dispatch unit 172 performs a matching process together with other dispatch requests 22 that have occurred in the same service area up to the same execution time.

[0157] Furthermore, the dispatch unit 172, similar to the priority dispatch service, sets the request priority of dispatch requests 22 using the early dispatch service to "high" before executing the matching process, as explained using Figure 13. With this configuration, the dispatch management server 50 can more reliably dispatch vehicles within the target time.

[0158] Furthermore, if a dispatch request 22 using the early dispatch service and a dispatch request 22 using the dispatch reservation service overlap, the dispatch unit 172 may set the request priority of the dispatch request 22 using the early dispatch service higher than that of the dispatch request 22 using the dispatch reservation service before executing the matching process. Alternatively, the dispatch unit 172 may set the request priority of the dispatch request 22 using the early dispatch service to be equal to that of the dispatch request 22 using the dispatch reservation service before executing the matching process. Alternatively, the dispatch unit 172 may set the request priority of the dispatch request 22 using the early dispatch service lower than that of the dispatch request 22 using the dispatch reservation service before executing the matching process. In this case, the dispatch unit 172 may set the request priority of the dispatch request 22 using the early dispatch service lower than that of the dispatch request 22 using the dispatch reservation service, but higher than that of the dispatch request 22 using the priority dispatch service before executing the matching process. Furthermore, in situations where various services such as priority dispatch services and dispatch reservation services are available, the dispatch unit 172 may set the priority of dispatch requests 22 that utilize the early dispatch service to the highest level before executing the matching process.

[0159] Furthermore, in order to prioritize dispatching within the target time in the early dispatch service, the dispatch unit 172 may exclude as many conditions other than vehicle dispatch as possible. For example, the dispatch unit 172 does not consider setting items such as payment information other than the pick-up location, dispatch category, taxi operator, and vehicle attributes. In this way, the dispatch management server 50 can designate vehicles 32 that can move to the pick-up location quickly as vehicles to be dispatched, regardless of the setting items.

[0160] In this case, the user application may have pages explaining various services, and the page explaining the early dispatch service may include a note stating that, in order to prioritize dispatching within the target time, other conditions other than the dispatch of vehicle 32 will be excluded as much as possible. Alternatively, the user terminal 20 may, in response to the user 2's operation of the early dispatch button 282, temporarily display a warning message stating that, in order to prioritize dispatching within the target time, other conditions other than the dispatch of vehicle 32 will be excluded as much as possible, and display an OK button with the message "OK" on it, and in response to the user 2's operation of the OK button, send a dispatch request 22 using the early dispatch service to the dispatch management server 50.

[0161] Furthermore, by not considering these settings, for example, User 2 will not be able to set payment information when requesting a ride. In this case, the dispatch management server 50 will set the payment information to in-vehicle payment. Thus, even if User 2 has not set up cashless automatic payment, they will be able to complete the payment uniformly by in-vehicle payment. Alternatively, the dispatch management server 50 may set the payment method used in the previous ride as the payment method for the early dispatch service. With this configuration, User 2 can make a payment using the same payment method as last time without having to set payment information. Thus, User 2 does not have to go through the hassle of setting payment information again. Furthermore, even if the payment method is forcibly set to in-vehicle payment or the previous payment method, User 2 may be allowed to change the payment method retrospectively, for example, before arriving at the pick-up location.

[0162] (Step S207) The crew terminal control unit 174 sends a dispatch notification to vehicle 32, which has been designated as a vehicle for dispatch request 22. Upon receiving an acceptance response from the crew terminal control unit 174, the dispatch of vehicle 32 to dispatch request 22 using the early dispatch service is confirmed.

[0163] (Step S208) When the user terminal control unit 170 confirms the dispatch of a vehicle for the dispatch request 22, it sends a dispatch completion notification to the user terminal 20 indicating that the dispatch has been confirmed.

[0164] Furthermore, in the early dispatch service, similar to the dispatch reservation service, incentives such as points or wages may be provided to the drivers 3 of the 32 vehicles that have accepted the dispatch notification.

[0165] In the ride-hailing reservation service, an example was given where, if vehicle 32 arrives at the pickup location earlier than the scheduled pickup time (early arrival), an incentive such as points or wages is awarded based on the difference between the actual arrival time of vehicle 32 and the scheduled pickup time. In contrast, the early dispatch service is intended to dispatch vehicles within a short target time of about 5 minutes, so it is unlikely that the vehicle will arrive at the pickup location significantly earlier than the scheduled pickup time. Therefore, in the early dispatch service, it is acceptable not to award incentives such as points or wages to driver 3.

[0166] Here, the ride-hailing reservation service mechanism is used to ensure that a vehicle is dispatched within the target time. Therefore, user 2 can be encouraged to use the app-based ride-hailing service. In addition, the dispatch management server 50 is designed to determine in advance whether a vehicle can be dispatched within the target time, and only provides the early dispatch service to user 2 if it is possible to dispatch a vehicle within the target time. Therefore, the dispatch management server 50 is able to appropriately dispatch a vehicle 32 within the target time.

[0167] Furthermore, since User 2 can be assured that vehicle 32 will arrive within the target time, they can effectively utilize the time until vehicle 32 arrives. For example, User 2 can make a ride request 22 using the early dispatch service at a shop before paying for goods, and then board vehicle 32 immediately after leaving the shop after payment. Also, for example, User 2 can make a ride request 22 using the early dispatch service at an office after completing work, and then board vehicle 32 immediately after leaving the office. Additionally, if there is a suitable pick-up location within a reasonable distance that can be reached within the target time, User 2 can make a ride request 22 using that location as the pick-up location, and then board vehicle 32 immediately upon reaching the pick-up location.

[0168] However, if, for example, user 2 hesitates to press the early dispatch button 282, a time lag may occur between the timing of the supply and demand simulation and dispatch simulation in steps S201 and S202 and the timing of the matching process for the dispatch request 22 using the early dispatch service in step S206. In such a case, dispatch within the target time may be possible in step S202, but it may become difficult to dispatch within the target time at the time of the matching process. Also, if the dispatched vehicle does not take the shortest route to the pick-up location, or if some kind of delay occurs, there is a risk that the vehicle 32 will not arrive within the target time.

[0169] However, in the early dispatch service, since the service offers user 2 a dispatch within the target time, it should not easily allow dispatches that exceed the target time. Therefore, the dispatch management server 50 updates, for example, the estimated arrival time from the vehicle 32's location to the pick-up location, and if it becomes difficult for vehicle 32, which is heading to the pick-up location, to arrive at the pick-up location within the target time based on its current location and the server's position, it sends information indicating that vehicle 32 is delayed and updated arrival time information to the user terminal 20. User 2 uses the early dispatch service (makes a dispatch request 22 using the early dispatch service) on the premise that they are guaranteed to be able to board vehicle 32 within the target time, so if they cannot board within the target time, they may want to cancel the ride. In this case, user 2 may be allowed to cancel without charge (free of charge). Also, if it becomes difficult to arrive at the pick-up location within the target time, user 2 may be allowed to use other services, such as the priority dispatch service, free of charge.

[0170] Furthermore, some users (2) may think that they can get a ride sooner from vehicle 32, which is cruising for fares, than from using the early dispatch service. To such users (2), we want to emphasize that the app-based dispatch service allows them to get a ride within their target time and is superior in terms of both the ride itself and its functionality.

[0171] Therefore, for example, if user 2, who has made a ride request 22 using the early dispatch service, is waiting for a vehicle 32 dispatched via the app, and then becomes available to ride in a vehicle 32 that is cruising for business, the user 2 may be allowed to cancel the ride request 22 free of charge or for a small fee. This would encourage users 2, who might think that they could get a ride in a vehicle 32 that is cruising for business, to use the early dispatch service. Furthermore, even if such a measure is implemented, it is expected that few users 2 will actually ride in a vehicle cruising for business and cancel their ride request 22 for the early dispatch service, so it would not have a significant impact on the early dispatch service.

[0172] This early dispatch service can be implemented by assigning a vehicle 32 to dispatch requests 22 that utilize the early dispatch service, giving them a higher priority than other dispatch requests 22. Furthermore, the early dispatch service can be made more reliable by assigning a vehicle 32 to a higher priority than the priority dispatch service. The processing of the dispatch unit 172 in the early dispatch service will be explained below.

[0173] Figures 17A to 17D are explanatory diagrams for illustrating the processing of the dispatch unit 172. Here, based on the relationship between dispatch requests 22a to 22f and candidate pair vehicles 232a to 232j explained using Figures 7 and 8, let's assume that user 2c uses the early dispatch service through dispatch request 22c, and users 2b and 2d use the priority dispatch service through dispatch requests 22b and 22d.

[0174] In this case, dispatch request 22c has a higher priority than dispatch requests 22b and 22d, and dispatch requests 22b and 22d have a higher priority than dispatch requests 22a, 22e, and 22f. Therefore, the dispatch unit 172 matches candidate vehicles 232 starting with the dispatch request 22 with the highest priority. In the above embodiment, two levels of request priority, "high" and "low," were used, but here, multiple levels such as "1," "2," and "3" are used as request priority.

[0175] The dispatch unit 172 extracts one or more dispatch requests 22 with the same priority level from the highest priority level (lowest numerical priority level) and performs a matching process.

[0176] First, the dispatch unit 172 extracts dispatch request 22c, which has a request priority of "1", as shown in Figure 17A, performs a matching process, and assigns the pair candidate vehicle 232i with the highest vehicle priority to dispatch request 22c. Then, as indicated by the "×", the dispatch unit 172 removes the pair candidate vehicle 232i assigned to dispatch request 22c from the pair candidate vehicles 232 of dispatch requests 22a, 22b, 22d-22f.

[0177] Next, as shown in Figure 17B, the dispatch unit 172 extracts multiple dispatch requests 22b and 22d with a request priority of "2" and performs a matching process. It assigns the pair candidate vehicle 232h with the highest vehicle priority to dispatch request 22b, and the pair candidate vehicle 232d with the highest vehicle priority to dispatch request 22d. As indicated by the "×", the dispatch unit 172 removes the pair candidate vehicles 232h and 232d that were assigned to the other dispatch requests 22b and 22d from the pair candidate vehicles 232 of dispatch requests 22a to 22f.

[0178] Next, as shown in Figure 17C, the dispatch unit 172 extracts multiple dispatch requests 22a, 22e, and 22f with a request priority of "3" and performs a matching process. It assigns the pair candidate vehicle 232b, which has the highest vehicle priority, to dispatch request 22a, the pair candidate vehicle 232f, which has the second highest vehicle priority, to dispatch request 22e, and the pair candidate vehicle 232j, which has the highest vehicle priority, to dispatch request 22f. Then, as indicated by the "×", the dispatch unit 172 removes the pair candidate vehicles 232b, 232f, and 232j that were assigned to the other dispatch requests 22a, 22e, and 22f from the pair candidate vehicles 232 of dispatch requests 22a to 22f.

[0179] Thus, as shown in Figure 17D, candidate vehicle 232b becomes the vehicle to be dispatched for dispatch request 22a, candidate vehicle 232h becomes the vehicle to be dispatched for dispatch request 22b, candidate vehicle 232i becomes the vehicle to be dispatched for dispatch request 22c, candidate vehicle 232d becomes the vehicle to be dispatched for dispatch request 22d, candidate vehicle 232f becomes the vehicle to be dispatched for dispatch request 22e, and candidate vehicle 232j becomes the vehicle to be dispatched for dispatch request 22f.

[0180] Here, it can be seen that for dispatch request 22c, which has a request priority set to "1", the pair candidate vehicle 232i, which has the highest vehicle priority, is assigned. Subsequently, for dispatch requests 22b and 22d, which have a request priority set to "2", the pair candidate vehicles 232h and 232d, which have the highest vehicle priority, are assigned. In this way, user 2c, who used the early dispatch service, can receive a dispatch earlier than user 2, who used the priority dispatch service. Also, users 2b and 2d, who used the priority dispatch service, can receive a dispatch earlier than with a regular dispatch request.

[0181] (Loyalty Program) To promote the use of the app-based ride-hailing service as described above, the ride-hailing management system 1 employs a loyalty program. The loyalty program grants benefits to users 2 based on factors such as the number of rides taken with vehicle 32, the total distance traveled, and the total amount paid through the app-based ride-hailing service. For example, the ride-hailing management server 50 updates the user rank according to the frequency of use of the ride-hailing service by a designated user 2, setting it so that the higher the frequency of use, the higher the user rank.

[0182] The following example illustrates how the dispatch management server 50 updates (promotes or demotes) the user rank based on the frequency of the user's use of the dispatch service. However, the dispatch management server 50 is not limited to this case; it can also award points to user 2 based on their use of the dispatch service, and user 2 can use these points for future payments, accumulate them as points in a mileage program, and exchange them for goods or services.

[0183] Figure 18 is an explanatory diagram illustrating the benefits of the loyalty program. In Figure 18, user ranks from Rank 1 to Rank 7 are set. Here, the higher the number assigned to the rank, the higher the user rank, and the greater the benefits granted to User 2.

[0184] The user rank is associated with user 2's user account in the dispatch management system 1. However, for the sake of explanation, in this embodiment, the user application that operates when logged in with user 2's user account, the user terminal 20 on which that application is installed, and user 2 who owns the user terminal 20 are all treated as objects to which a user rank is associated, just like user 2's user account. Therefore, expressions such as the user rank of user terminal 20 and the user rank of user 2 are synonymous with the user rank of user 2's user account.

[0185] Furthermore, each user account is associated with a phone number that can identify user 2, for example. Therefore, if user terminal 20 has multiple SIM (Subscriber Identity Module) cards, each with a different phone number, it is possible to create as many user accounts as there are SIM cards on that user terminal 20, and associate a user rank with each of them. In addition, user 2 can use the ride-hailing service by inserting the SIM card corresponding to their user account into another user terminal 20, and logging into the user application with their user account on that other user terminal 20. Moreover, as long as the user account can be identified, user 2 can use the ride-hailing service based on that user account, regardless of the type of electronic device running the user application (smartphone, personal computer, tablet, etc.).

[0186] The user rank is determined, for example, by the number of times the user has ridden in vehicle 32. Here, the number of rides refers to the number of times user 2 has ridden in vehicle 32 that they requested through the user application 22. The dispatch management server 50 updates the user rank for the current month according to the number of rides in the previous month. For example, when user 2 installs the user application, the user rank is set to rank 1 as the initial value. Then, as the number of rides in vehicle 32 increases, the user rank is promoted. For example, if the user rank is rank 1 and the number of app-dispatched and boarding rides in the previous month was between 5 and 9, the user rank will be updated to rank 2. Here, boarding includes the aforementioned cruising rides and boarding vehicle 32 from a designated vehicle boarding location at a station, etc., and includes boarding vehicle 32 without using the app to request a ride.

[0187] Similarly, if your user rank is rank 1 or 2, and you have taken 10 to 14 rides using the app for both ride-hailing and ride-on services in the previous month, your user rank will be updated to rank 3. Also, if your user rank is any of ranks 1 through 3, and you have taken 15 to 29 rides using the app with cashless automatic payment enabled in the previous month, your user rank will be updated to rank 4. Furthermore, if your user rank is any of ranks 1 through 4, and you have taken 30 to 49 rides using the app with cashless automatic payment enabled in the previous month, your user rank will be updated to rank 5. Also, if your user rank is any of ranks 1 through 5, and you have taken 50 to 79 rides using the app with cashless automatic payment enabled in the previous month, your user rank will be updated to rank 6. Furthermore, if your user rank is any of ranks 1 through 6, and you have taken 80 or more rides using the app with cashless automatic payment enabled on average over the two-month period (the previous two months), your user rank will be updated to rank 7. Please note that once a user reaches rank 7, their user rank will not increase any further.

[0188] In this example, the criteria for promotion to relatively low user ranks (e.g., ranks 2 and 3) include rides taken by passengers, while the criteria for promotion to relatively high user ranks (e.g., ranks 4 to 7) do not. This is because user 2, who uses vehicle 32 infrequently (low user rank), may not be familiar with app-based ride-hailing, so counting both app-based and rides increases their motivation to be promoted. On the other hand, user 2, who uses vehicle 32 frequently (high user rank), will likely increase their usage frequency as they understand the convenience of app-based ride-hailing, so their user rank can be promoted even if only app-based rides are counted. However, this example is not limited to these cases; it is also acceptable to exclude rides taken by passengers from the criteria for promotion to relatively low user ranks (e.g., ranks 2 and 3), and to include rides taken by passengers from relatively high user ranks (e.g., ranks 4 to 7).

[0189] Additionally, a user's rank will be downgraded if the number of rides on vehicle 32 decreases. For example, if a user's rank is 7 and the number of rides using the app with cashless automatic payment enabled has never exceeded 80 in the last three months, their user rank will be updated to rank 6. Also, if a user's rank is 6 and the number of rides using the app with cashless automatic payment enabled has never exceeded 50 in the last three months, their user rank will be updated to rank 5. Furthermore, if a user's rank is 5 and the number of rides using the app with cashless automatic payment enabled has never exceeded 30 in the last three months, their user rank will be updated to rank 4. Furthermore, if a user's rank is 4 and the number of rides using the app with cashless automatic payment enabled has never exceeded 15 in the last three months, their user rank will be updated to rank 3. Additionally, if a user's rank is 3 and they have not exceeded 10 rides using the app in the past three months, their user rank will be updated to 2. Furthermore, if a user's rank is 2 and they have not exceeded 5 rides using the app in the past three months, their user rank will be updated to 1. Once a user reaches rank 1, their user rank will not be lowered further.

[0190] As shown in Figure 18, the dispatch unit 172 determines user rank promotion based on the number of rides over a short period (one or two months), and user rank demotion based on the number of rides over a longer period (three months). Due to this hysteresis characteristic that differentiates the conditions for promotion and demotion, once user 2 has achieved a user rank promotion, their user rank will not be demoted in a short period even if the number of rides decreases. In this way, user 2 can maintain the motivation to promote their user rank.

[0191] In this explanation, we have used an example where the dispatch unit 172 updates the user rank based on the number of rides. However, the dispatch unit 172 may update the user rank based on the number of payments instead of, or in addition to, the number of rides. Here, the number of payments is the number of times that the fare based on the user 2's ride in the vehicle 32 assigned to the dispatch request 22 has been paid using a payment method associated with the user terminal 20 (set in the user application logged into with the user account) (for example, cashless automatic payment using a credit card, QR code, points, taxi ticket, etc.). For example, the dispatch unit 172 updates the user rank based on the number of payments made using cashless automatic payment, rather than the number of rides in the app dispatch service where cashless automatic payment is set up, as shown in Figure 18. Furthermore, the dispatch unit 172 may update the user rank not only based on the number of rides and the number of payments, but also based on both the number of rides and the number of payments. For example, if cashless automatic payment is set up in the user application, and user 2 boards vehicle 32 via app dispatch and pays the fare based on boarding vehicle 32 using cashless automatic payment, the dispatch unit 172 may count the number of "boarding and payment" as one set, or it may count the number of boarding and the number of payments as one each.

[0192] Furthermore, user 2, who uses the app-based ride-hailing service, often uses cashless automatic payment due to its convenience. Therefore, the number of rides using the app-based ride-hailing service and the number of payments made through the user application should be roughly equal. However, even when boarding a vehicle, there are cases where automatic payment through the user application is set up after boarding vehicle 32 (the number of rides using the app-based ride-hailing service is not counted, but the number of payments made through the user application is counted). Also, even with app-based ride-hailing, there are cases where automatic payment through the user application is not used, such as cash payment (the number of rides using the app-based ride-hailing service is counted, but the number of payments made through the user application is not counted). Therefore, the number of rides using the app-based ride-hailing service and the number of payments made through the user application are not necessarily equal.

[0193] Next, we will explain the benefits of the loyalty program. In the loyalty program, depending on the user rank, the allocation of vehicles 32 to dispatch requests 22 can be given preferential treatment (dispatch priority) compared to the allocation of vehicles 32 to other dispatch requests 22. For example, as shown in Figure 18, in the loyalty program, a priority index (1 to 7) is associated with the user rank. The dispatch unit 172 determines that the higher the priority index, the higher the priority of the request. The dispatch unit 172 then assigns dispatch requests 22 with a higher priority to vehicles 32, prioritizing them over other dispatch requests 22. At this time, the user terminal control unit 170 of the dispatch management server 50 may display the message "Priority search in progress" on the display device 124 of the user terminal 20 to indicate that the request is being given preferential treatment.

[0194] Thus, user 2, who has a higher user rank, can board vehicle 32 earlier and more reliably than user 2, who has a lower user rank. Therefore, user 2 can benefit from a synergistic effect: by increasing their user rank, they can more easily use the ride-hailing service, and as a result, the frequency of using the ride-hailing service increases, making it easier for them to increase their user rank.

[0195] Furthermore, the loyalty program allows for priority dispatch of vehicles 32 driven by high-quality drivers with superior qualities, driving skills, and knowledge, depending on the user rank. For example, the dispatch unit 172 determines that the higher the priority index associated with the user rank, the higher the priority (driver priority) for assigning vehicles 32 driven by high-quality drivers. The dispatch unit 172 then prioritizes assigning vehicles 32 driven by high-quality drivers to dispatch requests 22 with a high driver priority over other dispatch requests 22.

[0196] However, the number of excellent drivers is not very large. Therefore, if the dispatch unit 172 were to always assign a vehicle 32 driven by an excellent driver to a dispatch request 22 with a high user rank, the number of assignable vehicles 32 would be limited, which could actually make it difficult to dispatch a vehicle 32 quickly. Therefore, the dispatch unit 172 extracts one or more vehicles 32 that can be dispatched within the time range that user 2 is willing to accept for dispatch, and if a vehicle 32 driven by an excellent driver is included in the extracted vehicles 32, it assigns that vehicle 32 driven by the excellent driver to the dispatch request 22.

[0197] The dispatch unit 172 assigns vehicles 32 driven by high-quality drivers to dispatch requests 22 in stages, in order of driver priority. In this way, users 2 with a high user rank have a higher probability of riding in a vehicle 32 driven by a high-quality driver than users 2 with a low user rank. Therefore, users 2 can enjoy safer and more comfortable rides by increasing their user rank, and this, in turn, increases their frequency of using the dispatch service, resulting in a synergistic effect that makes it easier for them to increase their user rank.

[0198] In this explanation, we have used an example where the user 2 assigned to the vehicle 32 driven by a good driver is not restricted to a specific user rank. However, the user 2 assigned to the vehicle 32 driven by a good driver may be restricted to users 2 whose user rank is the first specific rank (for example, rank 4) or higher, or to users 2 who have set up a subscription plan as described later. In this explanation, rank 4 is given as the first specific rank, but the first specific rank can be set arbitrarily, and is not limited to this example.

[0199] Furthermore, NRS drivers generally differ from taxi drivers in that they may not possess a Class 2 driver's license for ordinary vehicles, or their driving qualifications, skills, and knowledge may be low. Therefore, it is acceptable not to assign an NRS vehicle to user 2, who has a high driver priority, or not to apply any mode that promotes the assignment of NRS vehicles.

[0200] Furthermore, the loyalty program allows for the priority allocation of premium vehicles, which have a larger interior space and are suitable for situations where there are many passengers or a lot of luggage, depending on the user rank. For example, the dispatch unit 172 determines that the higher the priority index, the higher the priority (vehicle type priority) for allocating premium vehicles. The dispatch unit 172 then allocates premium vehicles to dispatch requests 22 with a high vehicle type priority, prioritizing them over other dispatch requests 22.

[0201] However, the number of premium vehicles is not very large. Therefore, if the dispatch unit 172 were to always assign a premium vehicle to a dispatch request 22 from a high user rank, the number of available vehicles 32 would be limited, which could actually make it difficult to dispatch a vehicle 32 quickly. Therefore, the dispatch unit 172 extracts one or more vehicles 32 that can be dispatched within the time range that user 2 is willing to accept for dispatch, and if a premium vehicle is included in the extracted vehicles 32, it assigns that premium vehicle to the dispatch request 22.

[0202] The dispatch unit 172 then assigns premium vehicles to dispatch requests 22 in stages, in order of vehicle priority. In this way, users 2 with a higher user rank have a higher probability of riding in a premium vehicle than users 2 with a lower user rank. Therefore, users 2 can enjoy safer and more comfortable rides by increasing their user rank, and this, in turn, increases their frequency of using the dispatch service, resulting in a synergistic effect that makes it easier for them to increase their user rank.

[0203] In this example, we have not restricted the allocation of User 2 to a specific user rank. However, it is also possible to restrict the allocation of User 2 to a premium vehicle to Users 2 whose user rank is 1 specific rank (for example, rank 4) or higher, or to Users 2 who have set up a subscription plan as described later.

[0204] By the way, when using the ride-hailing service, user 2 enters the pick-up and drop-off locations through the user terminal 20. However, if user 2 has to enter the pick-up and drop-off locations every time they make a ride request 22, they may find this input process cumbersome. Therefore, the ride-hailing management system 1 allows user 2 to register their pick-up and drop-off locations as "favorite locations" in the user application. For example, user 2 with user rank 1 can register up to three "favorite locations".

[0205] Furthermore, the loyalty program allows for different limits on the number of favorite locations (number of locations) depending on the user's rank, as shown in Figure 18. For example, if a user's rank is 2, they can register up to 5 "favorite locations." If their rank is 3 or 4, they can register up to 10 "favorite locations." If their rank is 5 or higher, they can register an unlimited number of "favorite locations." Therefore, by increasing their user rank, user 2 can more easily set their pick-up and drop-off locations, and this, in turn, increases their frequency of using the ride-hailing service, creating a synergistic effect that makes it easier for them to increase their user rank.

[0206] Furthermore, the following problems may arise due to the number of "favorite locations" that can be registered varying depending on the user rank. For example, suppose a user's rank is rank 5 and they have registered 11 or more "favorite locations," but then their rank is demoted to rank 4, limiting the number of "favorite locations" to 10. In this case, there is a risk that the registered "favorite locations" may be deleted. Therefore, in the dispatch management system 1, even if the number of registered locations is limited due to a user rank demotion, the "favorite locations" that have already been registered will be retained. In this way, user 2 can register "favorite locations" and efficiently make dispatch requests 22 without worrying about the reduction of "favorite locations" due to a user rank demotion.

[0207] Furthermore, in this embodiment, user 2 can set up a subscription plan, as described later. As shown in Figure 18, when the user rank reaches a first specific rank (for example, rank 4) or higher, the dispatch management server 50 provides user 2 with guidance on setting up a subscription plan. Here, the ability to set up a subscription plan is restricted to users 2 whose user rank is the first specific rank or higher. Therefore, user 2 can appropriately receive the benefits obtained by setting up a subscription plan.

[0208] (Subscription plan) By using the priority dispatch service described above, User 2 can board vehicle 32 earlier and more reliably than with a regular dispatch request 22. Furthermore, by using the dispatch reservation service described above, User 2 can board vehicle 32 by their desired boarding time.

[0209] However, in order to use such priority dispatch and reservation services, User 2 is required to pay an additional fee each time, albeit a small amount. Therefore, some Users 2 may hesitate to use these services and endure the inconvenience of not using them. In this way, by being reluctant to pay the additional fee, User 2 misses out on opportunities to use convenient services.

[0210] Furthermore, for user 2, who frequently uses ride-hailing services, the additional charges for each ride may be small, but the total amount of these charges can become high, potentially forcing them to reconsider their frequency of using such services.

[0211] Therefore, in this embodiment, in order to promote the use of services such as priority dispatch and dispatch reservation services, a subscription plan is adopted that allows users to use such services for a fixed fee. User 2 sets up a subscription plan through the user application and, by paying the fee for the subscription plan, can receive any service free of charge and without limit as a benefit. Here, we will explain an example in which User 2 receives any service for free, but User 2 may also receive any service by paying a fee that is advantageous to him, for example, a discounted fee.

[0212] The subscription plan is associated with User 2's user account in the dispatch management system 1. However, for the sake of clarity, the user application, user terminal 20, and User 2 will also be treated as objects to which the subscription plan is associated, just like User 2's user account. Therefore, setting up a subscription plan for User 2's user account may be referred to as setting up a subscription plan for User Terminal 20 or User 2 in the following text.

[0213] Figure 19 is an explanatory diagram illustrating the benefits of a subscription plan. As shown in Figure 19, the benefits obtained under a subscription plan correspond to the user rank in the loyalty program. Therefore, even when a subscription plan is set up, similar to the loyalty program, the higher the user rank, the greater the benefits granted to User 2.

[0214] As mentioned above, User 2, whose user rank is below the first specific rank (for example, rank 4), will not be notified about setting up a subscription plan. Consequently, User 2 cannot set up a subscription plan until their user rank reaches the first specific rank or higher. Therefore, as shown in Figure 19, the benefits of the subscription plan are limited to User 2, whose user rank is the first specific rank or higher.

[0215] In this way, by restricting the ability of user 2 to set up a subscription plan to users whose user rank is 1st specific rank or higher, user 2 can appropriately receive the special benefits that come with setting up a subscription plan. Furthermore, since user 2 will try to increase their usage frequency and raise their user rank in order to set up a subscription plan, this promotes the use of the ride-hailing app.

[0216] User 2, whose user rank is 1st specific rank or higher, can set up a subscription plan to always use the priority dispatch service at no additional cost, as shown in Figure 19. The dispatch management system 1 makes it easier to assign a vehicle 32 to a dispatch request 22 that utilizes the priority dispatch service compared to a dispatch request 22 that does not utilize the priority dispatch service made by the same user 2. Therefore, when simulating the matching process between a dispatch request 22 that utilizes the priority dispatch service and a dispatch request 22 that does not utilize the priority dispatch service made by the same user 2, the former results in a higher likelihood of vehicle 32 being assigned. For example, if a dispatch request 22 that does not utilize the priority dispatch service fails to match vehicle 32, vehicle 32 will not be assigned, but if a dispatch request 22 that utilizes the priority dispatch service is guaranteed to be assigned, it is possible to make it easier to assign vehicle 32 to dispatch requests 22 that utilize the priority dispatch service. Alternatively, the dispatch unit 172 may prioritize assigning vehicles 32 to dispatch requests 22 that utilize the priority dispatch service, and assign the remaining vehicles to other dispatch requests 22 that do not utilize the priority dispatch service.

[0217] In this way, User 2 can board Vehicle 32 early and reliably without hesitation in using the priority ride-hailing service. Therefore, User 2, who has been able to set up a subscription plan by upgrading their user rank, can board Vehicle 32 early without worrying about how often they use the priority ride-hailing service and without additional charges by setting up a subscription plan. This creates a synergistic effect in which the increased frequency of ride-hailing service use makes it easier for User 2 to upgrade their user rank.

[0218] Furthermore, when assigning priority to dispatch requests 22 in parallel using both the priority dispatch service and the dispatch preferential treatment based on user rank as described above, the dispatch management server 50 may determine the request priority based on the magnitude of the priority index. For example, the higher the user rank in the loyalty program, the greater the priority index. When user 2 attempts to use the priority dispatch service, the dispatch unit 172 adds or multiplies a predetermined value to the priority index based on the user rank. The dispatch unit 172 determines that the larger the value calculated in this way, the higher the request priority. The dispatch unit 172 assigns the dispatch request 22 with the highest request priority to vehicle 32, prioritizing it over other dispatch requests 22. In this way, even when assigning priority to dispatch requests 22 in parallel using both the priority dispatch service and the dispatch preferential treatment based on user rank, the dispatch unit 172 is able to assign vehicles 32 to dispatch requests 22 with appropriate priority.

[0219] Furthermore, user 2 whose user rank is the second specific rank (for example, rank 5) or higher can easily use the ride-hailing service by setting up a subscription plan, as shown in Figure 19. However, the usage conditions for the ride-hailing service, such as time of day, may differ. Specifically, from the perspective of ensuring business opportunities for vehicle 32, the dispatch unit 172 may restrict usage during commuting hours, commuting hours, and late-night hours, depending on the user rank. For example, as shown in Figure 19, even if user rank is the first specific rank or higher, user 2 with rank 4, which is below the second specific rank, cannot use the ride-hailing service without an additional charge. Also, user 2 with ranks 5 and 6 can use the ride-hailing service without an additional charge, but their usage time is restricted to 9 am to 5 pm. User 2 with rank 7 can use the ride-hailing service at any time without time restrictions and without an additional charge. Here, rank 5 is given as the second specific rank for explanation, but the user rank is not limited to this example, and any user rank of the first specific rank or higher can be arbitrarily set.

[0220] In this explanation, we have used an example where the usage conditions, such as time slots, differ depending on the user rank for the ride-hailing reservation service. However, the explanation is not limited to this example; similar to the priority ride-hailing service, the usage conditions, such as time slots, may be made equal for the ride-hailing reservation service regardless of the user rank. In this case, user 2, who can use the ride-hailing reservation service without additional charges, may be designated as having a first specific rank (rank 4) or higher. This configuration can increase the motivation for user 2, who has a lower user rank (e.g., rank 4) but is at or above the first specific rank, to set up a subscription plan.

[0221] Thus, user 2, who is at a specific rank (for example, rank 5) or higher, can use the ride-hailing service without additional charges, allowing them to board vehicle 32 without hesitation. Therefore, user 2, who has become eligible to set up a subscription plan by upgrading their user rank, can board vehicle 32 at their desired time without worrying about how often they use the ride-hailing service. This creates a synergistic effect where increased usage of the ride-hailing service makes it easier for user 2 to upgrade their user rank.

[0222] For example, for children going to cram school or elderly people going to nursing homes, the pick-up times are somewhat fixed, and a ride-hailing reservation service that can dispatch a vehicle to their home at a set pick-up time is extremely convenient. However, if the frequency of use increases, the total amount of additional charges also increases, and paying the additional charges each time can be troublesome. By setting up a subscription plan, User 2 can safely and reliably transport children or elderly people in vehicle 32 without worrying about additional charges.

[0223] Furthermore, User 2, whose user rank is at or above the first specific rank, can set up a subscription plan to always use the early dispatch service without additional charges, as shown in Figure 19. In this way, User 2 can use the early dispatch service without hesitation and board vehicle 32 early and reliably. Therefore, User 2, who has become eligible to set up a subscription plan by upgrading their user rank, can use the early dispatch service to board vehicle 32 early without additional charges by setting up a subscription plan, and as a result the frequency of use of the dispatch service increases, a synergistic effect can be obtained where it becomes easier for User 2 to upgrade their user rank.

[0224] In this embodiment, user 2 whose user rank is below the first specified rank cannot receive the early dispatch service even if they pay an additional fee. This is because if the early dispatch service were available to everyone, all users 2 would want to use it, leading to competition among users 2 for the vehicle 32, and consequently, users 2 may not be able to effectively receive the early dispatch service. Therefore, the dispatch management server 50 restricts the provision of the early dispatch service to users 2 of the first specified rank or higher. With this configuration, the dispatch management server 50 can restrict the provision of the early dispatch service to users 2, so that users 2 who are eligible to receive the service can board the vehicle 32 appropriately within the target time. However, this is not the only example; users 2 whose user rank is below the first specified rank may also be able to use the early dispatch service by paying a predetermined additional fee.

[0225] Furthermore, in this embodiment, the dispatch management server 50 prevents the user rank of the loyalty program from being downgraded (prohibits downgrades) when a subscription plan is set. Note that setting a subscription plan restricts downgrades in user rank, but does not restrict promotions. In other words, as explained with reference to Figure 18, user 2 can raise their user rank by increasing the frequency of use of the dispatch service while a subscription plan is set.

[0226] Furthermore, the dispatch management server 50 ensures that when a user's rank is promoted while a subscription plan is set, the promoted user rank is not demoted. For example, user 2, whose rank is rank 4, can maintain rank 4 by setting up a subscription plan, even if their frequency of using the ride-hailing service decreases, as this will prevent their rank from being demoted. If user 2's frequency of using the ride-hailing service increases, since there is no restriction on user rank promotion, their rank may be promoted from rank 4 to rank 5. Thus, user 2, whose rank has reached rank 5, will maintain rank 5 as long as they have a subscription plan set up, even if their frequency of using the ride-hailing service decreases, as this will prevent their rank from being demoted. In other words, the user rank that is restricted from being demoted is the user rank after promotion (e.g., rank 5), not the user rank before promotion (e.g., rank 4).

[0227] In this way, User 2 can maintain or increase their user rank by setting up a subscription plan, and can continue to receive the priority dispatch service, dispatch reservation service, and early dispatch service shown in Figure 19 without any additional charges. By setting up a subscription plan after increasing their user rank, User 2 can prevent their user rank from being downgraded and only be able to increase it, and as a result the frequency of using the dispatch service increases, it becomes easier for them to increase their user rank, resulting in a synergistic effect.

[0228] Furthermore, in this embodiment, user 2 can set up account linking by setting up a subscription plan. As shown in Figure 19, when the user rank reaches a first specific rank (for example, rank 4) or higher and a subscription plan is set up, the dispatch management server 50 provides user 2 with instructions on how to set up account linking (general linking).

[0229] However, even if a user rank is at or above the first specified rank, account linking is restricted for rank 7 users. This is because allowing account linking with rank 7 user 2 would unintentionally increase the number of users 2 who can utilize the rare benefits of rank 7. Thus, here, account linking is restricted to users 2 whose user rank is at or above the first specified rank (excluding rank 7). Therefore, user 2 will be able to properly receive the benefits obtained by setting up account linking. Account linking will be explained in detail later.

[0230] Here, we have explained an example of restricting account linking for Rank 7, but the example is not limited to this one. In Rank 7, as with other user ranks, User 2 may be allowed to link accounts. In this case, the number of users (members) who can link accounts in Rank 7 (as described later) may be the same as the number of users in other user ranks (e.g., Ranks 4-6) (e.g., 3 people). Furthermore, to avoid unnecessarily increasing the number of users who can utilize Rank 7 benefits, the number of users who can link accounts in Rank 7 may be less than the number of users in other user ranks. Additionally, to increase the motivation of members who want to raise their user rank by sharing Rank 7 benefits, and to make it easier for administrators to maintain Rank 7 by increasing the bonus rate (as described later), the number of users who can link accounts in Rank 7 may be greater than the number of users in other user ranks.

[0231] Incidentally, the dispatch management server 50, in parallel with the control that restricts the demotion of user rank due to subscription plans, also manages the original user rank that would exist if a subscription plan were not set up, based on the frequency with which user 2 uses the ride-hailing service. When a subscription plan is canceled, the dispatch management server 50 reverts the user rank based on the subscription plan back to the original user rank in the loyalty program. For example, suppose user 2, whose user rank is rank 4, maintains rank 4 by setting up a subscription plan. However, suppose user 2's actual usage frequency of the ride-hailing service is low, and their original user rank, which is managed in parallel, has been demoted to rank 3. Here, when the subscription plan is canceled, the dispatch management server 50 demotes the user rank from rank 4, which was the user rank based on the subscription plan, back to rank 3, which is the original user rank. In addition, when the subscription plan is canceled, the dispatch management server 50 also cancels the account linkage described later. The dispatch management server 50 reverts the user rank of user 2 (member described later), whose account linkage has been canceled, back to their original user rank.

[0232] Therefore, User 2, who receives benefits from a high user rank, will continue to have their subscription plan active because they dislike the inconvenience of having their user rank downgraded. Furthermore, User 2 who tries to maintain a state where their user rank is easily promoted in order to receive even greater benefits will also want to continue having their subscription plan active. In this way, the use of subscription plans is promoted, and User 2 can continue to receive the benefits of their subscription plan.

[0233] Here, we explained that by setting up a subscription plan, users can access priority dispatch, reservation, and early dispatch services at no additional cost, depending on their user rank. However, even if a subscription plan is not included, it may be possible to offer a discount on the usage fees for priority dispatch, reservation, and early dispatch services at a predetermined rate, although an additional fee may be required.

[0234] Furthermore, this section explained that by setting up a subscription plan, User 2 can receive multiple services, specifically, priority ride-hailing services, ride-hailing reservation services, and expedited ride-hailing services, depending on their user rank, at no additional cost, account linking with other Users 2, and the elimination of user rank downgrades. However, the example does not limit User 2 to receiving all of these services; by setting up a subscription plan, User 2 may receive only one or more services selected from these services.

[0235] Furthermore, this explanation uses an example where priority dispatch, ride-hailing reservation, and early dispatch services can be used without limit while a subscription plan is active. However, the example is not limited to this; for example, the number of times priority dispatch, ride-hailing reservation, and early dispatch services can be used, or the period during which they can be used, may be limited on a monthly basis. Additionally, the interval between uses of priority dispatch, ride-hailing reservation, and early dispatch services (the time between the previous use and the current use) may be limited to a certain minimum time. Furthermore, when using the ride-hailing reservation service, the maximum period for which a pick-up time can be set may differ depending on the user rank. For example, user 2 with a low user rank may only be able to set a pick-up time up to 3 days in advance, while user 2 with a high user rank may be able to set a pick-up time up to 1 week in advance. Additionally, the minimum period for which a pick-up time can be set may differ depending on the user rank. For example, user 2 with a low user rank may only be able to set a pick-up time 10 minutes or more in advance, while user 2 with a high user rank may be able to set a pick-up time 5 minutes or more in advance.

[0236] Furthermore, in the embodiments described above, as shown in Figure 18, an example was given in which the priority index, dispatch preferential treatment, driver priority, vehicle priority, and number of locations differ according to the user rank in the loyalty program. Here, if a subscription plan is set, the dispatch unit 172 may add a predetermined value to the priority index and number of locations, and further make the driver priority, vehicle priority, and number of locations more favorable to user 2. Alternatively, instead of adding a predetermined value to the priority index and number of locations, the dispatch unit 172 may multiply them by a predetermined value.

[0237] Furthermore, setting up a subscription plan may make it easier to accumulate ride counts. For example, when user 2, who has set up a subscription plan, rides in vehicle 32, the dispatch management server 50 multiplies the number of rides by 1.2 and adds it to the ride count.

[0238] Furthermore, this document describes a specification in which User 2 can use priority dispatch, reservation, and early dispatch services by setting up a subscription plan, while also preventing a downgrade in the loyalty program user rank. However, the example is not limited to this; User 2 may also be able to prevent a downgrade in the loyalty program user rank, regardless of whether they can use priority dispatch, reservation, or early dispatch services, by paying a predetermined fee or points.

[0239] This subscription plan allows User 2 to use services such as priority dispatch, ride reservation, and early dispatch at no additional cost or at a discounted rate. Therefore, User 2 can use these services as many times as needed without hesitation.

[0240] Furthermore, by setting up a subscription plan, user 2 can be motivated to increase their user rank. In this way, the dispatch management server 50 can reliably provide dispatch services to user 2.

[0241] (Account linking) As mentioned above, User 2, with a higher user rank, receives greater benefits than User 2, with a lower user rank. Therefore, User 2 will increase their frequency of using the ride-hailing service in order to raise their user rank. In addition, User 2 will set up a subscription plan to maintain their user rank while also gaining opportunities for promotion. In this way, User 2 can maintain a high user rank. However, while User 2's user rank is low, they must increase their frequency of using the ride-hailing service while the benefits are still small.

[0242] Therefore, in this embodiment, account linking is employed to link accounts among multiple users 2. When accounts are linked, users 2 with a lower user rank can share the higher user rank of other users 2 and enjoy the benefits available to users with a higher user rank.

[0243] As described above, this embodiment employs a subscription plan to promote the use of services such as priority dispatch and dispatch reservation. Once a subscription plan is set up, User 2 can set up account linking at no additional cost. By setting up account linking through the user application, User 2 can allow User 2, the linked user, to receive the same benefits that User 2, the source user, can receive based on their user rank. Here, User 2, the source user, is sometimes referred to as the "administrator," and User 2, the linked user, is sometimes referred to as the "member."

[0244] However, even if accounts are linked, the benefits of the subscription plan set by the administrator are not shared with members. In other words, administrators can receive priority dispatch services, dispatch reservation services, early dispatch services, etc., through the subscription plan they have set, but members cannot receive priority dispatch services, dispatch reservation services, early dispatch services, etc., depending on the subscription plan set by the administrator. However, members can share the administrator's user account and set their own subscription plan to receive priority dispatch services, dispatch reservation services, early dispatch services, etc., based on the administrator's user rank.

[0245] In this explanation, we have used an example where, even if accounts are linked, the benefits of the subscription plan set by the administrator are not shared with the members. However, members may be able to share the benefits of the subscription plan set by the administrator by linking their accounts with the administrator, not limited to this example. Such sharing of subscription plan benefits may be possible only in the family linking described below, or only in the general linking described below, or in both family linking and general linking. Furthermore, if the subscription plan benefits have limits on the number of uses or time (duration) that can be used, the linked administrator and members may be able to use them independently up to the limit, or the limit may be applied to the combined total of all linked administrators and members.

[0246] In this embodiment, two types of account linking are provided: family linking and general linking. Family linking is intended for use between two users who are family members or relatives. General linking is intended for use between acquaintances, colleagues, or friends, who are different from those in family linking. In either case, as long as the accounts are linked, other members who are linked to the account can receive the same benefits as the administrator's user rank. In general linking, the administrator is required to set up a subscription plan, but in family linking, the administrator is not required to set up a subscription plan, and accounts can be linked at no additional cost.

[0247] However, regardless of a member's user rank, even if a member's user rank becomes higher than or equal to the administrator's user rank, the administrator cannot receive the benefits that a member's user rank would otherwise grant. Here, regardless of whether the administrator or member has a higher user rank, account linking allows the administrator's user rank to be shared as the member's user rank. If a member's user rank is higher than the administrator's user rank, account linking may not occur, or a warning message to that effect may be displayed on the administrator's user terminal 20. Furthermore, the number of rides taken by a linked member is not counted towards the administrator's or other members' ride counts. Similarly, the number of rides taken by a linked administrator is not counted towards the members' ride counts. This is because if the ride counts of multiple people could all be accumulated, the rate at which one person accumulates ride counts would be vastly different from the rate at which multiple people (e.g., four people) accumulate ride counts, resulting in an unbalanced progression of user ranks.

[0248] Furthermore, User 2 of User 1 cannot be the administrator of multiple Family Links. Also, User 2 of User 1 cannot be the administrator of multiple General Links. Note that an administrator of a Family Link can also be the administrator of a General Link of User 1, but cannot be a member of a General Link. Similarly, an administrator of a General Link can also be the administrator of a Family Link of User 1, but cannot be a member of a Family Link. Also, a member of a Family Link cannot become a member of a General Link, and a member of a General Link cannot become a member of a Family Link.

[0249] Figure 20 is an explanatory diagram illustrating the difference between family linking and general linking. As shown in Figure 20, with family linking and general linking, the administrator can invite, view, and delete members. It is also possible for members to unlink their accounts.

[0250] However, while family linking allows for an unlimited number of members to link accounts, general linking is limited to three. This is for the following reasons: Family linking assumes that the administrator pays for all members' usage fees, so if the administrator links accounts with acquaintances, colleagues, or friends, they will have to pay for the usage fees of others as well. Also, as will be explained later using Figure 20, in family linking, information regarding vehicle dispatch is known to the administrator, so others cannot easily link accounts with the administrator. Therefore, it is difficult for acquaintances, colleagues, or friends to link accounts, and as a result, the cases in which family linking is used are limited. On the other hand, as will be explained later, general linking does not have these disadvantages and allows for an unlimited increase in members, which could unintentionally lead to an excessive number of high-ranking users (User 2). Therefore, general linking is limited to three members. Note that the account linking explained using Figure 19 is general linking and is only available to User 2 whose user rank is 1st specific rank (for example, rank 4) or higher, and only User 2 with 1st specific rank or higher can become the administrator of general linking. However, as mentioned above, user 2 at rank 7 has significant benefits, so although they are in the first specific rank, they are not allowed to become an administrator for general integration.

[0251] In Family Link, charges based on rides in vehicles 32 dispatched by members are settled using a payment method with the administrator as the billing address. In other words, in Family Link, the administrator pays for the ride-hailing service charges collectively, regardless of whether the service was used by the administrator or a member. Therefore, members cannot individually set their own payment methods, but the administrator can set them.

[0252] Specifically, in family collaboration, the administrator's user terminal 20 has one or more payment methods set up with the administrator as the billing address. In addition, in family collaboration, the administrator can select the payment method for when a member uses the ride-hailing service from one or more payment methods with the administrator as the billing address. Furthermore, in family collaboration, the administrator can set the payment method for each member when a member uses the ride-hailing service. Here, if there is one payment method with the administrator as the billing address, the member can pay the fare based on riding in the vehicle 32 dispatched by the member using that one payment method with the administrator as the billing address. In this case, the ride-hailing management server 50 may process the payment using that payment method each time the administrator or member uses the ride-hailing service, or it may process the usage charges for a predetermined period (e.g., monthly) using that payment method, or it may process the usage charges for a predetermined period as a lump-sum invoice payment.

[0253] Furthermore, if there are multiple payment methods with the administrator as the billing address (for example, cashless automatic payment via credit card, QR code, points, taxi tickets, etc.), the administrator can individually set one payment method from the pre-configured multiple payment methods for each member's user terminal 20, and members can make payments through their own user terminal 20 using the payment method set by the administrator with the administrator as the billing address. Alternatively, the administrator can set one payment method from the pre-configured multiple payment methods as the payment method when a member uses the ride-hailing service on the administrator's user terminal 20, and members can make payments through their own user terminal 20 using the payment method set by the administrator with the administrator as the billing address. In this case, the administrator may also set a new payment method on the administrator's user terminal 20 that is different from the pre-configured multiple payment methods, and members can make payments through their own user terminal 20 using the payment method set by the administrator with the administrator as the billing address.

[0254] In contrast, with general integration, each member pays their own usage fees, so the administrator cannot set the payment method for members. In general integration, the fee based on riding in vehicle 32 dispatched by a member is settled using a payment method where the member themselves is the billing party. In this way, for example, in general integration, each user 2 can pay the fee for riding in vehicle 32, and since information about dispatch is not shared with the administrator, the privacy of users 2 can be protected. Alternatively, in general integration, the fee based on riding in vehicle 32 dispatched by a member may be settled using a payment method where a different user 2 (which may be an administrator) is the billing party, for example, than the member who used the dispatch service. In this way, for example, in general integration, user 2 can ride in vehicle 32 with another user account as the billing party.

[0255] Family collaboration is envisioned with the head of the household as the administrator, and users 2, who are family members or relatives sharing the same household, such as their children or parents, as members. Therefore, to protect members, the administrator is enabled to monitor various aspects of members' use of the ride-hailing service (information related to ride-hailing). For example, as shown in Figure 20, by sharing information related to members' ride-hailing with the administrator, the administrator can refer to the member's ride history, the ride status when the member uses the ride-hailing service, and the location of the vehicle 32 in which the member is riding. In addition, the administrator may also refer to the member's location (for example, the location of the user terminal 20 owned by the member) instead of, or in addition to, the location of the vehicle 32 in which the member is riding. In this case, the administrator may refer to the member's location for any period from when the member makes a ride request 22 until they get off the vehicle 32 at the drop-off location. Furthermore, the administrator can issue a receipt when a member rides in vehicle 32. This function, which allows the administrator to monitor various aspects of members' use of the ride-hailing service, can promote the use of the app-based ride-hailing service. Furthermore, members can use the ride-hailing service with peace of mind under the supervision of an administrator. In contrast, with general partnerships, administrators cannot track members' usage of the ride-hailing service or issue receipts, due to privacy concerns.

[0256] As described above, in account linking, whether family linking or general linking, other members can receive the same benefits as administrator 1's user rank. Here, the dispatch management server 50 manages the original user rank of user 2 according to the frequency of use of the dispatch service, in parallel with the control that restricts the demotion of user rank due to subscription plans. Therefore, members can enjoy benefits such as preferential dispatch, driver priority, vehicle priority, and number of locations by using an administrator's user rank that is higher than their own original user rank, while also raising their own original user rank. Note that the dispatch management server 50 provides the service that restricts the demotion of user rank due to subscription plan settings to general linked user 2, but not to family linked user 2. However, the dispatch management server 50 may also provide the service that restricts the demotion of user rank to both general linked user 2 and family linked user 2, not limited to this example.

[0257] Furthermore, unlike family partnerships, general partnerships allow for an increased rate of accumulation of the administrator's ride count, as shown in Figure 20. This means that administrators can accumulate more ride counts than they actually do by increasing the number of members, thus enabling them to advance their user rank more quickly.

[0258] Figures 21A and 21B are explanatory diagrams to illustrate the increase in the ride count accumulation rate. If User 2 is not generally linked, that is, if there are 0 members who are generally linked, the number of rides User 2 takes using the ride-hailing service will be accumulated at its original value in the loyalty program. This corresponds to a ride count accumulation rate of 1.0 times.

[0259] Here, assume that User 2 performs general linkage between their own user account and the user account of another User 2, such that User 2 becomes the administrator and the other User 2 becomes the first member. In this case, as shown in FIG. 21A, the addition rate for the administrator's number of rides is obtained by adding a predetermined value, for example, 0.2 times, to 1.0 time, resulting in 1.2 times. Accordingly, the number of rides of the administrator is multiplied by the addition rate and accumulated. For example, if the administrator rides the vehicle 32 five times, this is counted as six rides (5 rides × 1.2 times). This increases the accumulation amount of the administrator's number of rides, making it easier for the user rank to be promoted. Furthermore, since the administrator's user rank is equal to or higher than the first specific rank, the number of in-app vehicle dispatch requests is inherently large, such as 15 or more times per month. Therefore, even if the added addition rate is a decimal, the influence on the number of rides is significant.

[0260] Similarly, assume that User 2 performs general linkage between their own user account and the user accounts of two other Users 2, such that User 2 becomes the administrator and the two other Users 2 become the first member and the second member. In this case, as shown in FIG. 21A, the addition rate for the administrator's number of rides is obtained by adding a predetermined value, for example, 0.4 times (0.2 times × 2 users), to 1.0 time, resulting in 1.4 times. Accordingly, the number of rides of the administrator is multiplied by the addition rate and accumulated. For example, if the administrator rides the vehicle 32 five times, this is counted as seven rides (5 rides × 1.4 times). This increases the accumulation amount of the administrator's number of rides, making it easier for the user rank to be promoted.

[0261] Furthermore, assume that User 2 performs general linkage between their own user account and the user accounts of three other Users 2, such that User 2 becomes the administrator and the three other Users 2 become the first member, the second member, and the third member. In this case, as shown in FIG. 21A, the addition rate for the administrator's number of rides is obtained by adding a predetermined value, for example, 0.6 times (0.2 times × 3 users), to 1.0 time, resulting in 1.6 times. This increases the accumulation amount of the administrator's number of rides, making it even easier for the user rank to be promoted.

[0262] By increasing the number of members, the administrator can accumulate a larger number of rides for the vehicle 32 allocated by the administrator than the actual number of rides, thereby promoting the administrator's user rank to be promoted at an earlier stage. In this way, the administrator will be encouraged to perform account linkage with other users 2 to become a member, thereby promoting the use of application-based vehicle allocation.

[0263] It should be noted that, here, the description has been given by taking an example in which the addition rate of the administrator's number of rides is increased according to the number of members. However, the present invention is not limited to such an example, and in addition to the administrator, the addition rate of the member's number of rides may also be increased.

[0264] For example, assume that a user 2 performs general linkage between their own user account and the user account of another user 2, where the user 2 acts as the administrator and the other user 2 acts as a first member. In this case, as shown in FIG. 21B, the addition rate for the number of rides is obtained by adding a predetermined value, for example, 0.2 times, to 1.0 times, resulting in 1.2 times. As a result, the number of rides of the administrator and the first member is multiplied by the addition rate before being accumulated. For example, if the administrator or the first member rides the vehicle 32 five times, it is counted as six rides (five times × 1.2 times). By this means, the accumulation degree of the number of rides for both the administrator and the first member is increased, making it easier for the user ranks of both users 2 to be promoted.

[0265] Similarly, assume that a user 2 performs general linkage between their own user account and the user accounts of two other users 2, where the user 2 acts as the administrator, and the two other users 2 act as a first member and a second member respectively. In this case, as shown in FIG. 21B, the addition rate for the number of rides is obtained by adding a predetermined value, for example, 0.4 times (0.2 times × 2 people), to 1.0 times, resulting in 1.4 times. As a result, the number of rides of the administrator, the first member, and the second member is multiplied by the addition rate before being accumulated. For example, if the administrator or the first member rides the vehicle 32 five times, it is counted as seven rides (five times × 1.4 times). By this means, the accumulation degree of the number of rides for all of the administrator, the first member, and the second member is increased, making it easier for the user ranks of all users 2 to be promoted.

[0266] Furthermore, suppose User 2 links its user account with the user accounts of the other three Users 2, with User 2 becoming the administrator and the other three Users 2 becoming the 1st, 2nd, and 3rd members. In this case, as shown in Figure 21B, the rate of accumulation of rides becomes 1.6 times, which is calculated by adding a predetermined value, for example, 0.6 times (0.2 times x 3 people), to 1.0 times. In this way, the accumulation rate of rides for the administrator, 1st member, 2nd member, and 3rd member increases, making it easier for all Users 2 to be promoted to higher user ranks.

[0267] In this way, by increasing the rate at which members' ride counts are added, in addition to the administrator's, members can receive greater benefits due to the administrator's high user rank, resulting in safer and more comfortable rides. Consequently, the frequency of use of the ride-hailing service increases, creating a synergistic effect where both the individual user rank and the administrator's user rank, who is the source of the connection, are more likely to be promoted. In this way, the use of the ride-hailing app can be promoted.

[0268] In this explanation, we have used an example where the administrator's ride count increases when two users link their accounts. However, the dispatch unit 172 may count the ride counts of linked members as the administrator's ride count, even if it is not limited to this example. Furthermore, if the system is designed to increase the ride count for members in addition to the administrator, the dispatch unit 172 may count the ride counts of linked administrators as the member's ride count, even if it is not limited to this example. Furthermore, the dispatch unit 172 may count the ride counts of linked members as the ride counts of other members linked to the same account, even if it is not limited to this example.

[0269] Furthermore, this explanation uses an example where the rate of increase for the number of rides increases by adding a predetermined value (e.g., 0.2) to the administrator's rate of increase when two users link their accounts. However, the example is not limited to this; instead of adding a predetermined value, the rate of increase for the number of rides could also be increased by multiplying it by a predetermined value (e.g., 1.2).

[0270] Furthermore, this explanation uses an example where an administrator can be both a general link administrator and a family link administrator, but cannot be both an administrator and a member. However, it is not limited to this case; it may be possible for an administrator to be both a general link administrator and a family link member. It may also be possible for a family link administrator to be both a general link member and a general link member. It may also be possible for a general link member and a family link member to be both a general link member and a family link member. In such cases, administrators and members may increase the ridership rate or have rides counted multiple times across multiple account links.

[0271] Furthermore, this explanation uses an example where the dispatch unit 172 increases the rate at which the administrator's ride count is added and counts members' ride counts as the administrator's ride count in general collaborations, while not providing such preferential treatment for ride counts in family collaborations. However, the dispatch unit 172 may also increase the rate at which the administrator's ride count is added and counts members' ride counts as the administrator's ride count in family collaborations, even if it is not limited to this case. In this case, similar to general collaborations, in family collaborations, the rate at which the administrator's ride count is added may be increased according to the number of members, as well as the rate at which members' ride counts are added in addition to the administrator's.

[0272] Furthermore, this explanation assumes that the dispatch unit 172 independently counts the number of rides taken by administrators and members in account linking (regardless of whether it is general linking or family linking), and provides examples of increasing the rate at which administrators' rides are added or counting members' rides as administrators' rides. However, the dispatch unit 172 may count members' rides in relation to administrators' rides, not limited to these examples. For example, the dispatch unit 172 may count all of members' rides as administrator rides, or it may apportion members' rides and count a predetermined percentage of members' rides (any percentage between 0% and 100%, for example, 30%, 50%, or 70%) as administrator rides. For example, if the predetermined ratio is 50%, the dispatch unit 172 counts the number of times the administrator rides in vehicle 32 as the administrator's ride count, and for the number of times a member rides in vehicle 32, it counts 50% as the administrator's ride count and the remaining 50% as the member's ride count. With this specification, for example, in a family linkage, the administrator can count those rides as their own ride count instead of having to pay the member's usage fee, making it easier for them to advance their user rank.

[0273] Furthermore, in the embodiments described above, as shown in Figure 18, an example was given in which the priority index, dispatch preferential treatment, driver priority, vehicle priority, and number of locations differ according to the user rank in the loyalty program. Here, if account linking is set up, the dispatch unit 172 may add a predetermined value to the priority index and number of locations, and furthermore, the driver priority, vehicle priority, and number of locations may be more favorable to administrators and members. Alternatively, instead of adding a predetermined value, the dispatch unit 172 may multiply the priority index and number of locations by a predetermined value.

[0274] Furthermore, this explanation uses an example where the administrator's ride count increases when two users link their accounts. However, the example is not limited to this; when updating user ranks based on the number of payments, the administrator's payment count may increase when two users link their accounts, or the number of payments made by members may be counted redundantly as the administrator's payment count. In this case, for example, the above ride count can be replaced with the number of payments and applied to this embodiment.

[0275] As mentioned above, the subscription plan allows User 2 to use services such as priority dispatch, ride reservation, and early dispatch at no additional cost or at a discounted rate. Furthermore, by linking with other Users 2, User 2 can increase their accumulated number of rides, and all Users 2 with linked accounts can synergistically raise their user rank. In this way, it becomes possible to promote the use of ride-hailing services among all Users 2 with linked accounts.

[0276] Furthermore, User 2 can increase their motivation to upgrade their user rank by setting up a subscription plan, and further increase their motivation to use the ride-hailing service by integrating with the general public. In this way, the ride-hailing management server 50 can stably provide the ride-hailing service to User 2.

[0277] Furthermore, User 2 attempts to link their account with another User 2 in order to increase their own ride count. This requires the other User 2 to install the user application for account linking, thus encouraging them to use the ride-hailing service. In this way, the use of the ride-hailing app can be promoted.

[0278] In this way, User 2 can more easily advance in user rank through subscription plans and account linking, and as their user rank increases, they can more easily access ride-hailing services, thus achieving a synergistic effect. This section explains how to verify the user rank achieved in this manner.

[0279] Figure 22 is an explanatory diagram illustrating an example of the operation of the user terminal control unit. When user 2 launches a user application through the user terminal 20 and performs an operation to check the user rank, the user terminal control unit 170 displays a rank confirmation screen 310, as shown in Figure 22, on the display device 124.

[0280] As shown in Figure 22, a rank display image 312 indicating the user rank is shown above the rank confirmation screen 310. The rank display image 312 is designed to resemble a credit card. Therefore, the background color of the rank display image 312 varies depending on the user rank. For example, primary colors such as blue or green are used for lower user ranks, and the background changes to copper, silver, and gold as the user rank increases, with metallic colors that have a metallic sheen used for even higher user ranks. In addition, like a credit card, black may be used when the user rank reaches the highest value. Thus, the rank display image 312 also has the function of allowing users to infer their social status or position, for example, like a credit card.

[0281] User 2 can easily check their user rank through the rank display image 312 and be satisfied with their high user rank. Also, since a high user rank allows for earlier dispatch as described above, User 2 may make dispatch requests 22 on behalf of others. In such situations, others have the opportunity to see User 2's user rank, and User 2 may feel a sense of superiority due to their high user rank.

[0282] A usage status button 314 is arranged at the lower right position of the rank display image 312. The user 2 can check the usage status by operating the usage status button 314. The usage status includes the user rank, the monthly number of rides including the current time point, the scheduled user rank for the next month, conditions for promoting the user rank, conditions for demoting the user rank, and the like. Furthermore, as the usage status, when the user rank is to be promoted according to the number of rides, guidance to that effect may be displayed, and when the user rank is to be demoted according to the number of rides, guidance to that effect may be displayed. Furthermore, when a subscription plan is set, guidance to the effect that the user rank will not be demoted may be displayed.

[0283] Furthermore, below the rank display image 312, a first benefit box 316 indicating benefits granted in the current user rank is displayed. In the first benefit box 316, for example, guidance to the effect that vehicle dispatch preferential treatment is provided, guidance to the effect that excellent drivers are preferentially assigned, guidance to the effect that premium vehicles are preferentially assigned, the registerable number of favorite points, and the like are displayed. Here, on the rank confirmation screen 310, which is a top screen for checking the user rank, the benefit contents can be checked at once as a list of benefits for the current user rank.

[0284] Furthermore, if the current user rank is equal to or higher than a first specific rank, below the first benefit box 316, a second benefit box 318 indicating benefits granted when a subscription plan is set for the current user rank is displayed. In the second benefit box 318, for example, guidance to the effect that a priority dispatch service is always available, guidance to the effect that a dispatch reservation service is available all day between 9:00 and 17:00, guidance to the effect that an early dispatch service is always available, guidance to the effect that account linkage is possible, and the like are displayed. Here, on the rank confirmation screen 310, which is a top screen for checking the user rank, the benefit contents can be checked at once as a list of benefits when a subscription plan is set for the current user rank.

[0285] As described above, the dispatch management system 1 in this embodiment comprises a user terminal 20 logged in with a predetermined user account, and a dispatch management device (e.g., a dispatch management server 50) that can communicate with the user terminal 20 via a network 6. The user terminal 20 comprises one or more first processors, and the dispatch management device comprises one or more second processors. The first processor transmits a dispatch request 22 to the dispatch management device, and the second processor assigns a vehicle 32 to the received dispatch request 22. The number of rides taken by the user in the assigned vehicle is associated with the user account, the user rank is updated based on the number of rides (e.g., based on the number of rides per month), different benefits (e.g., priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) are granted to the user account according to the user rank, and when predetermined demotion restriction conditions (e.g., setting up a subscription plan, payment of consideration) are met for the user account, the demotion of the user rank is restricted (e.g., prohibited) regardless of the number of rides. With this configuration, User 2 can only be promoted while preventing a demotion in user rank by meeting the demotion restriction conditions. This creates a synergistic effect where increased frequency of use of the ride-hailing service makes it easier for the user rank to be promoted.

[0286] The dispatch management system 1 in this embodiment comprises a user terminal 20 logged in with a predetermined user account, and a dispatch management device (e.g., a dispatch management server 50) that can communicate with the user terminal 20 via a network 6. The user terminal 20 comprises one or more first processors, and the dispatch management device comprises one or more second processors. The first processor transmits a dispatch request 22 to the dispatch management device, and the second processor assigns a vehicle 32 to the received dispatch request 22. The number of payments made based on the fare for riding the assigned vehicle using a payment method associated with the user account is associated with the user account. The user rank is updated based on the number of payments (e.g., based on the number of payments per month), and different benefits (e.g., priority index, dispatch preferential treatment, driver priority, vehicle priority, number of locations) are granted to the user account according to the user rank. When predetermined demotion restriction conditions (e.g., setting up a subscription plan, payment of consideration) are met for a user account, the user rank is restricted (e.g., prohibited) regardless of the number of payments. With this configuration, User 2 can only be promoted while preventing a demotion in user rank by meeting the demotion restriction conditions. This creates a synergistic effect where increased frequency of use of the ride-hailing service makes it easier for the user rank to be promoted.

[0287] In this embodiment, the dispatch management device (e.g., dispatch management server 50) that can communicate with the user terminal 20 logged in with a predetermined user account via the network 6 comprises one or more processors. The processors assign a vehicle 32 to the dispatch request 22 received from the user terminal 20, associate the number of rides the user has taken in the assigned vehicle with the user account, update the user rank based on the number of rides (e.g., based on the number of rides per month), grant different benefits (e.g., priority index, dispatch preference, driver priority, vehicle type priority, number of locations) to the user account according to the user rank, and restrict (e.g., prohibit) the demotion of the user rank regardless of the number of rides when predetermined demotion restriction conditions (e.g., setting up a subscription plan, payment of fees) are met for the user account. With this configuration, user 2 can only be promoted while preventing demotion of the user rank by meeting the demotion restriction conditions, and consequently obtain a synergistic effect in which the frequency of use of the dispatch service increases, making it easier to be promoted in the user rank.

[0288] The processor can promote a user's rank based on the number of rides, provided that the demotion restriction conditions are met. Once a user's rank is promoted, the processor restricts the demotion of that promoted user rank, regardless of the number of rides. This configuration allows user 2 to avoid being demoted from their promoted user rank while the demotion restriction conditions are met.

[0289] In this embodiment, a dispatch management device (e.g., dispatch management server 50) that can communicate with a user terminal 20 logged in with a predetermined user account via a network 6 comprises one or more processors. The processors assign a vehicle 32 to a dispatch request 22 received from the user terminal 20, associate the number of payments made based on the fare for riding the assigned vehicle using the payment method associated with the user account with the user account, update the user rank based on the number of payments (e.g., based on the number of payments per month), grant different benefits (e.g., priority index, dispatch preference, driver priority, vehicle type priority, number of locations) to the user account according to the user rank, and restrict (e.g., prohibit) the demotion of the user rank regardless of the number of payments when predetermined demotion restriction conditions (e.g., setting up a subscription plan, payment of consideration) are met for the user account. With this configuration, user 2 can only be promoted while preventing demotion of the user rank by meeting the demotion restriction conditions, and consequently obtain a synergistic effect in which the frequency of use of the dispatch service increases, making it easier to be promoted in the user rank.

[0290] The processor can promote a user's rank based on the number of transactions, provided that the demotion restriction conditions are met. Once a user's rank is promoted, the processor restricts the demotion of the promoted user rank, regardless of the number of transactions. With this configuration, user 2 can prevent their promoted user rank from being demoted as long as the demotion restriction conditions are met.

[0291] The demotion restriction condition is the setting of a subscription plan in the user account. When a subscription plan is set, the processor accepts a dispatch request 22 from the user terminal 20 that utilizes the priority dispatch service, which makes it easier to dispatch a vehicle 32, without additional charge. For dispatch requests 22 that utilize the priority dispatch service, the processor ensures that a vehicle is more likely to be assigned compared to when the same user 2 submits a dispatch request 22 that does not utilize the priority dispatch service. With this configuration, user 2, who has become eligible to set a subscription plan by being promoted in user rank, can board vehicle 32 early without worrying about the frequency of using the priority dispatch service and without additional charge by setting a subscription plan. This results in a synergistic effect where the frequency of using the dispatch service increases, making it easier to be promoted in user rank.

[0292] The demotion restriction condition is the setting of a subscription plan in the user account. When a subscription plan is set, the processor accepts a ride request 22 from the user terminal 20, including the pick-up location and pick-up time (for example, using the ride-hailing reservation service), without additional charge, and begins assigning vehicle 32 to the ride request 22 before the pick-up time so that vehicle 32 arrives at the pick-up location at the pick-up time. With this configuration, user 2, who has become eligible to set a subscription plan by being promoted in user rank, can ride in vehicle 32 at their desired pick-up time without worrying about how often they use the ride-hailing reservation service, and consequently, they can obtain a synergistic effect in that their usage of the ride-hailing service will increase, making it easier for them to be promoted in user rank.

[0293] In this embodiment, the dispatch management method involves a computer assigning a vehicle 32 to a dispatch request 22 received from a user terminal 20 logged in with a predetermined user account, associating the number of rides taken by the user in the assigned vehicle with the user account, updating the user rank based on the number of rides (for example, based on the number of rides per month), granting different benefits (for example, priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) to the user account according to the user rank, and restricting (for example, prohibiting) the demotion of the user rank regardless of the number of rides when predetermined demotion restriction conditions (for example, setting up a subscription plan, payment of consideration) are met for the user account. With this configuration, user 2 can only be promoted while preventing demotion of the user rank by meeting the demotion restriction conditions, and consequently, a synergistic effect can be obtained in which the frequency of use of the dispatch service increases, making it easier to be promoted in the user rank.

[0294] In this embodiment, the dispatch management method involves a computer assigning a vehicle 32 to a dispatch request 22 received from a user terminal 20 logged in with a predetermined user account, associating the number of payments made using the payment method associated with the user account for fares based on rides in the assigned vehicle with the user account, updating the user rank based on the number of payments (for example, based on the number of payments per month), granting different benefits (for example, priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) to the user account according to the user rank, and restricting (for example, prohibiting) the demotion of the user rank regardless of the number of payments when predetermined demotion restriction conditions (for example, setting up a subscription plan, payment of consideration) are met for the user account. With this configuration, user 2 can only be promoted while preventing demotion of the user rank by meeting the demotion restriction conditions, and consequently, a synergistic effect can be obtained in which the frequency of use of the dispatch service increases, making it easier to be promoted in the user rank.

[0295] The program in this embodiment causes the computer to assign a vehicle 32 to a ride request 22 received from a user terminal 20 logged in with a predetermined user account, associate the number of rides taken by the user with the user account, update the user rank based on the number of rides (for example, based on the number of rides per month), grant different benefits (for example, priority index, preferential ride treatment, driver priority, vehicle type priority, number of locations) to the user account according to the user rank, and restrict (for example, prohibit) the demotion of the user rank regardless of the number of rides when predetermined demotion restriction conditions (for example, setting up a subscription plan, payment of fees) are met for the user account. With this configuration, user 2 can only be promoted while preventing demotion of the user rank by meeting the demotion restriction conditions, and consequently obtain a synergistic effect in which the frequency of use of the ride-hailing service increases, making it easier to be promoted in the user rank.

[0296] The program in this embodiment causes the computer to assign a vehicle 32 to a ride request 22 received from a user terminal 20 logged in with a predetermined user account, associate the number of payments made using the payment method associated with the user account for fares based on rides in the assigned vehicle with the user account, update the user rank based on the number of payments (for example, based on the number of payments per month), grant different benefits (for example, priority index, ride dispatch preferential treatment, driver priority, vehicle type priority, number of locations) to the user account according to the user rank, and restrict (for example, prohibit) the demotion of the user rank regardless of the number of payments when predetermined demotion restriction conditions (for example, setting up a subscription plan, payment of consideration) are met for the user account. With this configuration, user 2 can only be promoted while preventing demotion of the user rank by meeting the demotion restriction conditions, and consequently obtain a synergistic effect in which the frequency of use of the ride-hailing service increases, making it easier to be promoted in the user rank.

[0297] Furthermore, the dispatch management system 1 in this embodiment includes a user terminal 20 logged in with a first user account (for example, an administrator's user account), and a dispatch management device (for example, a dispatch management server 50) that can communicate with the user terminal 20 via a network 6. The user terminal 20 is equipped with one or more first processors, and the dispatch management device is equipped with one or more second processors. The first processor transmits a dispatch request 22 to the dispatch management device, the second processor assigns a vehicle 32 to the received dispatch request 22, and the user 2 boards the assigned vehicle 32. The number of rides is associated with the first user account, and benefits (e.g., priority index, dispatch preference, driver priority, vehicle priority, number of locations) may be granted to the first user account based on the number of rides. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the rate at which the number of rides corresponding to dispatch requests 22 received from the user terminal 20 is increased (e.g., the rate of increase, the accumulation of rides from dispatch requests 22 of other user terminals 20 that are linked to the account). With this configuration, the rate at which the number of rides from dispatch requests 22 of the linked user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, the linked user 2 will encourage other users 2 to link their accounts, thus promoting the use of the app-based ride-hailing service.

[0298] Furthermore, the dispatch management system 1 in this embodiment comprises a user terminal 20 logged in with a first user account (e.g., an administrator's user account), and a dispatch management device (e.g., a dispatch management server 50) that can communicate with the user terminal 20 via a network 6. The user terminal 20 comprises one or more first processors, and the dispatch management device comprises one or more second processors. The first processor transmits a dispatch request 22 to the dispatch management device, and the second processor assigns a vehicle 32 to the received dispatch request 22 and associates the fare based on the ride in the assigned vehicle 32 with the first user account. The number of payments made using a given payment method is associated with the first user account, and benefits (e.g., priority index, dispatch preference, driver priority, vehicle priority, number of locations) may be granted to the first user account based on the number of payments. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the rate at which the number of payments corresponding to rides in vehicles assigned to dispatch requests 22 received from user terminal 20 is increased (e.g., accumulation rate, overlapping accumulation of payment counts from dispatch requests 22 of other linked user terminals 20). With this configuration, the rate at which the number of payments from dispatch requests 22 of the linked user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, the linked user 2 will encourage other users 2 to link their accounts, thus promoting the use of the app-based ride-hailing service.

[0299] In this embodiment, the dispatch management device, which can communicate via a network with a user terminal logged in with a first user account (e.g., an administrator's user account), comprises one or more processors. The processors assign vehicles to dispatch requests 22 received from the user terminal 20, associate the number of rides (the number of times user 2 has ridden in the assigned vehicle 32) with the first user account, and may grant the first user account benefits (e.g., priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) based on the number of rides. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the degree to which the number of rides corresponding to dispatch requests 22 received from the user terminal 20 is increased (e.g., the accumulation rate, the accumulation of overlapping ride counts due to dispatch requests 22 from other linked user terminals 20). With this configuration, the degree to which the number of rides from dispatch requests 22 of the source user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, user 2, who initiated the linking process, will encourage other users 2 to link their accounts, thereby promoting the use of the ride-hailing app.

[0300] The processor updates the user rank based on the number of rides, grants different benefits to the first user account (e.g., the administrator's user account) according to the user rank, and shares the user rank of the first user account with the second user account (e.g., the member's user account) (for example, other user terminals 20 are also considered to have the same user rank as user terminal 1 20). In this way, the linked user terminal 20 can receive benefits based on the higher user rank of the linked user terminal 20 (e.g., priority index, ride-hailing preference, driver priority, vehicle type priority, number of locations).

[0301] In this embodiment, the dispatch management device, which can communicate via a network with a user terminal logged in with a first user account (e.g., an administrator's user account), comprises one or more processors. The processors assign vehicles to dispatch requests 22 received from the user terminal 20, associate the number of payments made using a payment method associated with the first user account with the first user account, and may grant the first user account benefits (e.g., priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) based on the number of payments. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the degree to which the number of payments corresponding to rides in vehicles assigned to dispatch requests 22 received from the user terminal 20 is increased (e.g., the accumulation rate, the accumulation of duplicate payments from dispatch requests 22 of other linked user terminals 20). With this configuration, the degree to which the number of payments from dispatch requests 22 of the source user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, user 2, who initiated the linking process, will encourage other users 2 to link their accounts, thereby promoting the use of the ride-hailing app.

[0302] The processor updates the user rank based on the number of transactions, grants different benefits to the first user account (e.g., the administrator's user account) according to the user rank, and shares the user rank of the first user account with the second user account (e.g., the member's user account) (for example, other user terminals 20 are also considered to have the same user rank as user terminal 1 20). In this way, the linked user terminal 20 can receive benefits based on the higher user rank of the linked user terminal 20 (e.g., priority index, ride dispatch preference, driver priority, vehicle type priority, number of locations).

[0303] The processor increases the degree of addition (e.g., addition rate, including the number of rides from other user devices) as the number of linked accounts (which is different from the first user account linked to the first user account) increases. This configuration, where the degree of addition increases with the number of linked accounts, encourages users to attempt account linking to increase their number of linked accounts, thereby promoting the use of the ride-hailing app.

[0304] The processor settles the fare for a ride in vehicle 32, which was dispatched based on a second user account (e.g., a member's user account), using a payment method that bills the second user account (e.g., the member themselves). In this way, for example in a general collaboration, each user 2 can pay the fare for a ride in vehicle 32, and since dispatch information is not shared with the administrator, the privacy of the users 2 can be protected.

[0305] The processor settles the fare for riding in vehicle 32, which was dispatched based on a second user account (for example, a member's user account), using a payment method that bills a different user account than the second user account. In this way, for example, in a general collaboration, user 2 can ride in vehicle 32 with another user account billed.

[0306] The processor settles the fare for rides on vehicle 32, which were dispatched based on the second user account, using a payment method that bills the first user account (for example, the administrator's user account). In this way, for example, in a family linkage, it becomes possible to aggregate the fares for rides on vehicle 32 for multiple users 2 and process the payment using the first user account as the billing address.

[0307] The processor shares ride-hailing information from a second user account (e.g., a member's user account) with the first user account (e.g., the administrator's user account). This configuration allows the administrator to monitor various aspects of members' use of the ride-hailing service. Furthermore, members can use the ride-hailing service with peace of mind under the administrator's supervision.

[0308] In the dispatch management method of this embodiment, the computer assigns a vehicle to a dispatch request 22 received from a user terminal 20 logged in with a first user account (e.g., an administrator's user account), associates the number of rides taken by user 2 in the assigned vehicle 32 with the first user account, and may grant the first user account benefits (e.g., priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) based on the number of rides. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the degree to which the number of rides corresponding to the dispatch request 22 received from the user terminal 20 is increased (e.g., the accumulation rate, the accumulation of rides from dispatch requests 22 of other user terminals 20 that are linked). With this configuration, the degree to which the number of rides from dispatch requests 22 of the linked user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, the linked user 2 will encourage other users 2 to link their accounts, thereby promoting the use of the app-based dispatch service.

[0309] In the dispatch management method of this embodiment, the computer assigns a vehicle to a dispatch request 22 received from a user terminal 20 logged in with a first user account (e.g., an administrator's user account), associates the number of payments made using the payment method associated with the first user account for the fare based on the ride in the assigned vehicle 32 with the first user account, and may grant the first user account benefits (e.g., priority index, dispatch preferential treatment, driver priority, vehicle type priority, number of locations) based on the number of payments, and increases the rate at which the number of payments corresponding to rides in vehicles assigned to dispatch requests 22 received from the user terminal 20 is accumulated (e.g., accumulation rate, overlapping accumulation of the number of payments from dispatch requests 22 of other user terminals 20 that are account linked) while the first user account and a second user account different from the first user account (e.g., a member's user account) are linked. With this configuration, the rate at which the number of payments from dispatch requests 22 of the source user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, user 2, who initiated the linking process, will encourage other users 2 to link their accounts, thereby promoting the use of the ride-hailing app.

[0310] In this embodiment, the program may instruct the computer to assign a vehicle to a ride request 22 received from a user terminal 20 logged in with a first user account (e.g., an administrator's user account), associate the number of rides taken by user 2 in the assigned vehicle 32 with the first user account, and grant the first user account benefits (e.g., priority index, preferential treatment for rides, driver priority, vehicle type priority, number of locations) based on the number of rides. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the program increases the rate at which the number of rides corresponding to the ride request 22 received from the user terminal 20 is accumulated (e.g., accumulation rate, overlapping accumulation of rides from ride requests 22 from other linked user terminals 20). With this configuration, the rate at which the number of rides from ride requests 22 from the linked user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, the linked user 2 will encourage other users 2 to link their accounts, thereby promoting the use of the app-based ride-hailing service.

[0311] In this embodiment, the program instructs the computer to assign a vehicle to a ride request 22 received from a user terminal 20 logged in with a first user account (e.g., an administrator's user account), associate the number of payments made using the payment method associated with the first user account for the ride in the assigned vehicle 32 with the first user account, and grant the first user account benefits (e.g., priority index, preferential dispatch, driver priority, vehicle type priority, number of locations) based on the number of payments. While the first user account and a second user account different from the first user account (e.g., a member's user account) are linked, the program increases the rate at which the number of payments corresponding to rides in vehicles assigned to ride requests 22 received from the user terminal 20 is accumulated (e.g., accumulation rate, overlapping accumulation of payment counts from ride requests 22 of other linked user terminals 20). With this configuration, the rate at which the number of payments from ride requests 22 of the linked user terminal 20 is accumulated increases, making it easier for the user rank to be promoted. Therefore, user 2, who initiated the linking process, will encourage other users 2 to link their accounts, thereby promoting the use of the ride-hailing app.

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

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

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

[0315] 1. Dispatch Management System 2 users 3 Drivers 20 User Terminals 30 Crew Terminal 32 vehicles 40. Service Provider Servers 50. Dispatch management server (dispatch management device) 160 Dispatch Request Department 170 User Terminal Control Unit 172 Dispatch Department 174 Crew Terminal Control Unit

Claims

1. The user terminal logged in with the first user account, A dispatch management device that can communicate with the user terminal via a network, A dispatch management system comprising: The user terminal comprises one or more first processors, The vehicle dispatch management device comprises one or more second processors, The first processor, The dispatch request is transmitted to the dispatch management device. The second processor, A vehicle is assigned to the received dispatch request. The number of times a user has ridden in an assigned vehicle is associated with the first user account. Based on the number of rides, the first user account may be granted benefits. While the first user account and a second user account different from the first user account are linked, the rate at which the number of rides corresponding to the dispatch request received from the user terminal is increased. Vehicle dispatch management system.

2. The user terminal logged in with the first user account, A dispatch management device that can communicate with the user terminal via a network, A dispatch management system comprising: The user terminal comprises one or more first processors, The vehicle dispatch management device comprises one or more second processors, The first processor, The dispatch request is transmitted to the dispatch management device. The second processor, A vehicle is assigned to the received dispatch request. The number of payments, which is the number of times the fare based on riding in the assigned vehicle has been paid using the payment method associated with the first user account, is associated with the first user account. The first user account may be granted benefits based on the number of transactions. While the first user account and a second user account different from the first user account are linked, the rate at which the number of payments corresponding to boarding a vehicle assigned to a ride request received from the user terminal is increased. Vehicle dispatch management system.

3. A dispatch management device that can communicate via a network with a user terminal logged in with a first user account, Equipped with one or more processors, The aforementioned processor, A vehicle is assigned to the dispatch request received from the user terminal. The number of times a user has ridden in an assigned vehicle is associated with the first user account. Based on the number of rides, the first user account may be granted benefits. While the first user account and a second user account different from the first user account are linked, the rate at which the number of rides corresponding to the dispatch request received from the user terminal is increased. Vehicle dispatch management system.

4. The aforementioned processor, The user rank is updated based on the number of rides mentioned above. Different benefits are granted to the first user account according to the user rank. The dispatch management device according to claim 3, which shares the user rank of the first user account with the second user account.

5. A dispatch management device that can communicate via a network with a user terminal logged in with a first user account, Equipped with one or more processors, The aforementioned processor, A vehicle is assigned to the dispatch request received from the user terminal. The number of payments, which is the number of times the fare based on riding in the assigned vehicle has been paid using the payment method associated with the first user account, is associated with the first user account. The first user account may be granted benefits based on the number of transactions. While the first user account and a second user account different from the first user account are linked, the rate at which the number of payments corresponding to boarding a vehicle assigned to a ride request received from the user terminal is increased. Vehicle dispatch management system.

6. The aforementioned processor, The user rank will be updated based on the number of transactions, Different benefits are granted to the first user account according to the user rank. The dispatch management device according to claim 5, which shares the user rank of the first user account with the second user account.

7. The dispatch management device according to any one of claims 3 to 6, wherein the processor increases the degree of addition as the number of linked user accounts, which is the number of user accounts different from the first user account that are linked to the first user account, increases.

8. The dispatch management device according to any one of claims 3 to 6, wherein the processor settles the fare based on a ride in a vehicle dispatched based on the second user account using a payment method to which the second user account is the billing address.

9. The dispatch management device according to any one of claims 3 to 6, wherein the processor settles the fare based on a ride in a vehicle dispatched based on the second user account using a payment method to which a user account different from the second user account is the billing address.

10. The dispatch management device according to any one of claims 3 to 6, wherein the processor settles the fare based on a ride in a vehicle dispatched based on the second user account using a payment method to which the first user account is the billing address.

11. The dispatch management device according to any one of claims 3 to 6, wherein the processor causes the dispatch information of the second user account to be shared with the first user account.

12. Computers A vehicle is assigned to a dispatch request received from a user terminal logged in with the first user account. The number of times a user has ridden in an assigned vehicle is associated with the first user account. Based on the number of rides, the first user account may be granted benefits. While the first user account and a second user account different from the first user account are linked, the rate at which the number of rides corresponding to the dispatch request received from the user terminal is increased. Vehicle dispatch management method.

13. Computers A vehicle is assigned to a dispatch request received from a user terminal logged in with the first user account. The number of payments, which is the number of times the fare based on riding in the assigned vehicle has been paid using the payment method associated with the first user account, is associated with the first user account. The first user account may be granted benefits based on the number of transactions. While the first user account and a second user account different from the first user account are linked, the rate at which the number of payments corresponding to boarding a vehicle assigned to a ride request received from the user terminal is increased. Vehicle dispatch management method.

14. On the computer, A vehicle is assigned to a dispatch request received from a user terminal logged in with the first user account. The number of times a user has ridden in an assigned vehicle is associated with the first user account. Based on the number of rides, the first user account may be granted benefits. While the first user account and a second user account different from the first user account are linked, the rate at which the number of rides corresponding to the dispatch request received from the user terminal is increased. A program to perform a task.

15. On the computer, A vehicle is assigned to a dispatch request received from a user terminal logged in with the first user account. The number of payments, which is the number of times the fare based on riding in the assigned vehicle has been paid using the payment method associated with the first user account, is associated with the first user account. The first user account may be granted benefits based on the number of transactions. While the first user account and a second user account different from the first user account are linked, the rate at which the number of payments corresponding to boarding a vehicle assigned to a ride request received from the user terminal is increased. A program to perform a task.

Images