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

Abstract

Even when dispatch requests are made through the website, the dispatch results will be properly tracked. [Solution] A dispatch management device that can communicate with a user terminal 20 via a network comprises one or more processors, which receive dispatch requests and telephone numbers from the user terminal 20 via a website, assign a vehicle to the dispatch request, update the dispatch status which shows the status of vehicle assignment in stages, send link information including a link destination specific to the dispatch request to the user terminal 20 via a message service, and display the updated dispatch status on the user terminal 20 in response to a connection request to the link destination by the user terminal 20.

Description

Technical Field

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

Background Art

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

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] A user can make a vehicle dispatching request by installing an application for vehicle dispatching requests on a user terminal owned by the user and inputting parameters related to the vehicle dispatching request. In addition to the application, attempts have also been made to allow vehicle dispatching requests through a web site. However, unlike an application, if the web site is closed during a vehicle dispatching request, the user has to browse the web site again to know the vehicle dispatching result. Even if the user can browse the web site again, it is difficult to return to the state in which the user made the vehicle dispatching request if the session is different, and ultimately, the user cannot grasp the vehicle dispatching result.

[0005] In view of such problems, an object of the present invention is to provide an information processing device, an information processing method, and a program that can appropriately grasp a vehicle dispatching result even for a vehicle dispatching request through a web site. [Means for solving the problem]

[0006] To solve the above problems, the dispatch management device of the present invention, which can communicate with a user terminal via a network, comprises one or more processors, the processors receiving dispatch requests and telephone numbers from the user terminal via a website, assigning a vehicle to the dispatch request, updating the dispatch status to show the status of the vehicle assignment in stages, transmitting link information including a link destination specific to the dispatch request to the user terminal via a messaging service, and displaying the updated dispatch status on the user terminal in response to a request from the user terminal to connect to the link destination. The processor may transmit the link information in response to the update of the dispatch status, and the link destination included in the link information may remain the same regardless of the update of the dispatch status. The processor may, while a session based on the dispatch request is ongoing, redirect the user terminal to the website if a new request to view the website is received, and display the dispatch status based on the dispatch request on the user terminal. The processor may, after disconnecting the session based on the dispatch request, authenticate the user terminal when it receives a new request to browse the website from the user terminal, and after authentication is complete, redirect the user terminal to the link destination and display the dispatch status based on the dispatch request on the user terminal. The processor may, if an application managed by the dispatch management device is installed on the user terminal, launch the application on the user terminal when a new request to browse the website is received from the user terminal. The processor may also transmit text information indicating the dispatch status to the user terminal via a messaging service, in addition to the link information. The processor may transmit information including the link destination to the user terminal via web push notification, and in response to a connection request from the user terminal to the link destination, display the updated dispatch status on the user terminal. To solve the above problems, the vehicle dispatch management method of the present invention involves a computer receiving a vehicle dispatch request and telephone number from a user terminal via a website, assigning a vehicle to the vehicle dispatch request, updating the vehicle dispatch status to show the status of the assigned vehicle in stages, transmitting link information including a link destination specific to the vehicle dispatch request to the user terminal via a messaging service, and displaying the updated vehicle dispatch status on the user terminal in response to a request from the user terminal to connect to the link destination. To solve the above problems, the program of the present invention causes a computer to receive a dispatch request and telephone number from a user terminal via a website, assign a vehicle to the dispatch request, update the dispatch status to show the status of the vehicle assignment in stages, transmit link information including a link destination specific to the dispatch request to the user terminal via a messaging service, and display the updated dispatch status on the user terminal in response to a request from the user terminal to connect to the link destination. [Effects of the Invention]

[0007] According to the present invention, it becomes possible to appropriately grasp the dispatch results even when dispatch requests are made through a website. [Brief explanation of the drawing]

[0008] [Figure 1] Figure 1 is a block diagram illustrating the general structure of the dispatch management system. [Figure 2] Figure 2 is a block diagram illustrating the configuration of the user terminal. [Figure 3] Figure 3 is a block diagram illustrating the configuration of the vehicle terminal. [Figure 4] Figure 4 is a block diagram illustrating the configuration of the service provider's server. [Figure 5] Figure 5 is a block diagram illustrating the configuration of the dispatch management server. [Figure 6] Figure 6 is a sequence diagram showing the processing flow of the dispatch management method using the dispatch management system. [Figure 7] Figure 7 is a flowchart illustrating the processing performed by the dispatch management server when a web account is registered. [Figure 8] Figure 8A is the first timing chart showing the processing flow of a dispatch request. Figure 8B is the second timing chart showing the processing flow of a dispatch request. [Figure 9] Figure 9A is the first explanatory diagram illustrating the operation of the user terminal control unit. Figure 9B is the second explanatory diagram illustrating the operation of the user terminal control unit. [Figure 10] Figure 10 is a flowchart illustrating how a website is displayed on a user's terminal. [Figure 11] Figure 11 is a flowchart illustrating the process performed by the dispatch management server when an app account is registered. [Modes for carrying out the invention]

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

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

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

[0012] Figure 2 is a block diagram illustrating the configuration of the user terminal 20. The user terminal 20 includes a communication device 120, a processing unit 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 unit 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. User applications for the dispatch management system 1 can be installed on the user terminal 20. By running a program, the processing unit 122 starts the user application and functions as a dispatch request unit 160 that assists in inputting dispatch requests, which are dispatch requests from user 2. Here, dispatch refers to assigning a vehicle 32 to a dispatch request and sending it to the pick-up location. The user terminal 20 also has a web browser installed that allows browsing websites (web pages). The dispatch request unit 160 can also access the website for the dispatch management system 1 via a web browser and assist user 2 in entering dispatch requests by allowing them to view the website. Thus, user 2 can make dispatch requests through a user application managed by the dispatch management company, or through a website managed by the dispatch management company. In the following, when it is necessary to distinguish which method is being used for the dispatch request, a dispatch request made through a user application managed by the dispatch management company will be abbreviated as "app dispatch request," and a dispatch request made through a website managed by the dispatch management company (web guest dispatch) will be abbreviated as "web dispatch request." 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 or website for making a dispatch request. The input device 126 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc., superimposed on the display device 124, and accepts input from user 2, such as information for making a dispatch request.The storage device 128 is composed of storage means such as a HDD (Hard Disk Drive), SD memory, SSD (Solid State Drive), etc.

[0013] The vehicle terminal 30 is an electronic device lent to the driver 3 of the vehicle 32 or an electronic device owned by the driver 3 and is used when performing the operation of the vehicle 32. Therefore, the vehicle terminal 30 is associated with the vehicle 32 together with the driver 3. Note that the vehicle terminal 30 is, as a result, located (exists) within the vehicle 32, and it suffices if it can be operated and referred to by the driver 3, and it is not limited to the mode of being brought into the vehicle at the start of driving, and it may be provided (fixed) in the vehicle 32 in advance. Examples of the vehicle terminal 30 include a smartphone, a personal computer, a tablet PC, etc.

[0014] FIG. 3 is a block diagram for explaining the configuration of the vehicle terminal 30. The vehicle terminal 30 includes a communication device 130, a processing device 132, a display device 134, an input device 136, and a storage device 138. The communication device 130 is communicably connected to the outside, for example, the carrier server 40 and the vehicle dispatch management server 50, through the base station 5 and the network 6. The processing device 132 has a semiconductor integrated circuit including a processor (CPU), a ROM storing programs and the like, a RAM used as a work area, and the like. A vehicle application for the vehicle dispatch management system 1 is installed in the vehicle terminal 30. The processing device 132 functions as a vehicle dispatch response unit 162 that controls the vehicle application and supports response inputs by the driver 3 for vehicle dispatch by operating a program. The display device 134 includes a liquid crystal display and an organic EL display, and displays various information for the driver 3, such as that their vehicle 32 has become the target of a vehicle dispatch request (vehicle dispatch target notification) and information related to the vehicle dispatch request (boarding location, alighting location, user information about the user 2). Hereinafter, the target of the vehicle dispatch request may be referred to as the "vehicle dispatch target", and the vehicle 32 that has become the vehicle dispatch target may be referred to as the "vehicle dispatch target vehicle". Also, the vehicle terminal 30 can be made to function as a fare meter (taximeter) that automatically calculates a fare according to the travel distance and required time from the boarding location to the alighting location. In this case, the display device 134 displays information indicating the automatically calculated fare for the user 2, for example. Such a fare meter realized by the vehicle terminal 30 may be referred to as a "soft meter" to distinguish it from a dedicated meter fixed to a 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 receives inputs from the driver 3, such as acceptance of a vehicle dispatch request. The storage device 138 is composed of storage means such as an HDD, an SD memory, and an SSD. Note that the vehicle terminal 30 can acquire its own position on the map through a position specifying means such as GPS (Global Positioning System).

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

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

[0017] Figure 4 is a block diagram illustrating the configuration of the operator server 40. The operator server 40 is an information processing device (computer) owned by a taxi operator that operates a taxi business. The operator server 40 manages vehicles 32 driven by drivers 3 belonging to the taxi business. The operator server 40 includes a communication device 140, a processing device 142, a display device 144, an input device 146, and a storage device 148. The communication device 140 is connected to the outside world via the network 6, for example, to a vehicle terminal 30 and a dispatch management server 50. The processing device 142 has a semiconductor integrated circuit including a processor (CPU), ROM in which programs are stored, RAM used as a work area, etc. By running a program, the processing device 142 functions as a vehicle management unit 164 that manages vehicles 32 belonging to the taxi business. The display device 144 includes a liquid crystal display and an organic EL display, and displays various information such as information about the driver 3 or the vehicle 32, which is obtained directly from the vehicle 32 or via the dispatch management server 50. The input device 146 includes a keyboard, a touch panel superimposed on the display device 144, a microphone for voice input, etc., and receives input from operators in the taxi company. For example, the operator can communicate with the driver 3 via the operator 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.

[0018] Figure 5 is a block diagram illustrating the configuration of the dispatch management server 50. The dispatch management server (dispatch management device) 50 is an information processing device (computer) that manages vehicles 32 belonging to a taxi company based on a contract between the dispatch management company and the taxi company. The dispatch management server 50 is an example of a dispatch management device having server functionality and is operated by the dispatch management company. The dispatch management server 50 can dispatch a vehicle 32 to user 2 in response to a dispatch request from user terminal 20. The dispatch management server 50 includes a communication device 150, a processing device 152, and a storage device 154. The communication device 150 is connected to the outside world via the network 6, for example, user terminal 20, vehicle terminal 30, and operator server 40. The processing device 152 has a semiconductor integrated circuit including a processor (CPU), ROM in which programs are stored, RAM used as a work area, etc. By running programs, the processing device 152 functions as a user terminal control unit 170, a dispatch unit 172, and a vehicle terminal control unit 174. The user terminal control unit 170 controls the user applications installed on the user terminal 20. The user terminal control unit 170 also controls the websites accessed by the user terminal 20 via a web browser. Here, as an example of the user terminal control unit 170 controlling a website, the dispatch management server 50 directly manages the website. However, the system is not limited to this example; other devices may manage the website, and the user terminal control unit 170 may establish communication with such other devices and substantially control the websites managed by them. The dispatch unit 172 assigns a vehicle 32 to a dispatch request. The vehicle terminal control unit 174 controls the vehicle applications installed on the vehicle terminal. 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.

[0019] In the dispatch management system 1, when assigning a vehicle 32 to a dispatch request (i.e., dispatching a vehicle), for example, by matching multiple dispatch requests with multiple vehicles 32, one vehicle 32 is assigned to one dispatch request from one user 2. Here, matching refers to the process of exclusively associating any dispatch request with any vehicle 32 when multiple dispatch requests and multiple vehicles 32 exist. 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 in one vehicle 32, multiple dispatch requests from multiple users 2 may be combined, and one vehicle 32 may be assigned to that combined dispatch request.

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

[0021] (Vehicle dispatch request processing S1) If User 2 has not installed the user application on User Terminal 20, User 2 first installs the user application and registers a user account. When registering a user account, User 2 enters information that identifies User 2, such as their name, gender, and date of birth; information that identifies User Terminal 20, such as their phone number; and information that identifies their payment method, such as their credit card number. Once the user account is registered in this way, User 2 can request a ride through the app.

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

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

[0024] 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. If multiple Users 2 board at different locations, the pick-up location also includes the combined pick-up range of those locations. The drop-off location indicates the map location where User 2 will alight from the vehicle 32. If multiple Users 2 alight at different locations, the drop-off location also includes the combined drop-off range of those locations. 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 will be 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 a required input, but is optional. On the other hand, if User 2 includes NRS vehicles in the dispatch options, the drop-off location becomes a required input.

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

[0026] The setting item for taxi operators indicates the operator to which driver 3 belongs. User 2 can specify their desired taxi operator by entering information in the setting item for taxi operators. In addition to the taxi operator, user 2 can also specify the branch office. The vehicle attributes indicate the type and equipment of vehicle 32. Examples of vehicle attributes include whether it is a high-class vehicle (so-called hire car), whether it is wheelchair accessible, and whether 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 setting item for vehicle attributes. The toll road information indicates whether or not toll roads, such as expressways, will be used. If the toll road information indicates the use of toll roads, the route from the pick-up location to the drop-off location will actively include toll roads. The ride-sharing permission information indicates whether or not ride-sharing is permitted in vehicle 32, where another user 2 rides along.

[0027] As described above, when making a ride-hailing request via the user application, User 2 first installs the user application and registers a user account. Then, with User 2's user account authenticated, User 2 enters the parameters for the ride-hailing request, and Vehicle 32 is assigned to that request. In contrast, when making a ride-hailing request via the website, User 2 first enters the parameters for the web-based ride-hailing request. This provisionally assigns Vehicle 32 to the web-based ride-hailing request. Once User 2 registers a user account, Vehicle 32 is officially assigned to the web-based ride-hailing request. Thus, with web-based ride-hailing requests, User 2 is shown the provisionally assigned state of Vehicle 32 before registering a user account.

[0028] Specifically, User 2 launches a web browser and accesses a website managed by the dispatch management company. Examples of web browsers include Internet Explorer (IE), Edge, Chrome, Safari, and Firefox. The website's webpage 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.

[0029] Furthermore, User 2 can access the website managed by the ride-hailing service provider without having to search for it and enter the URL (Uniform Resource Locator) of the linked site. This can be done through other applications, such as map apps, taxi ride guidance software, or route search software. Additionally, User 2 can access the website by having User Terminal 20 scan barcodes or QR codes installed in commercial facilities such as hotels.

[0030] If User 2 wishes to ride in Vehicle 32, they enter parameters for the web-based ride request via the website, such as the pick-up location and drop-off location. The dispatch management server 50 then provisionally assigns Vehicle 32 to the ride request. User 2 can then access dispatch information via the website, such as the estimated arrival time and fare, once Vehicle 32 has been dispatched. After reviewing this dispatch information, User 2 registers a simple user account when they actually want to request Vehicle 32. The dispatch management server 50 formally confirms the ride request based on the registered user account. Vehicle 32 then accepts the request and heads to User 2's pick-up location. The reason the dispatch management server 50 provisionally assigns Vehicle 32 to a ride request before User 2 registers a user account is to allow User 2 to experience the convenience of the ride request before they encounter the hassle of registering a user account. In the following, when it is necessary to distinguish between user accounts registered through a user application and user accounts registered through a website, we may abbreviate them as "app accounts" and "web accounts," respectively.

[0031] In the case of app-based ride-hailing requests, registering an app account requires inputting information that identifies user 2 (e.g., name, gender, date of birth), information that identifies user terminal 20 (e.g., phone number), and information that identifies the payment method (e.g., credit card number). In contrast, for web-based ride-hailing requests, a web account can be registered by simply entering the phone number that identifies user terminal 20 owned by user 2. Therefore, when user 2 makes a web-based ride-hailing request, they may recognize that they have registered their phone number as a web account, but they may not recognize it as account registration and may simply have entered their phone number for identity verification. Specifically, user 2 checks the ride-hailing information via the website on user terminal 20 and then enters their phone number in accordance with the input instructions for the phone call. The ride-hailing management server 50 sends an authentication code consisting of multiple alphanumeric characters to this phone number, for example, via SMS (Short Message Service), a messaging service that can send and receive messages to and from phone numbers. User 2 can register a web account by entering an authentication code received via SMS into a designated area on the website. While this example uses the input of an authentication code, the dispatch management server 50 may also authenticate by sending a designated URL via SMS, with User 2 accessing that URL. Therefore, the web account for web-based ride requests will be associated with a phone number as the user identifier. Thus, while web-based ride requests and app-based ride requests are similar in that they both include a phone number as the user identifier, the other information associated with them differs.

[0032] Here, SMS is given as a messaging service for sending and receiving authentication codes and link information described later, but it is not limited to this example. Any messaging service that can send information to the user terminal 20 is sufficient. For example, MMS (Multimedia Messaging Service) using a carrier's email address, iMessage which allows messaging between iOS devices, or IM (Instant Messenger) such as LINE (registered trademark) can be used. For example, IM such as LINE requires a phone number to register an account for the messaging service itself, so it can be applied to the registration of the user account in this embodiment which requires a phone number.

[0033] In this system, a phone number is associated with the web account. Compared to other communication methods such as email, a phone number offers a higher accuracy in identifying user 2, thus preventing fraudulent web-based ride requests. Furthermore, because a phone number is associated with the web account, if driver 3 arrives at the pick-up location and cannot find user 2, they can contact user 2 by phone. Also, even if user 2 contacts driver 3 by phone, driver 3 can recognize that the call is from user 2 thanks to the caller ID function.

[0034] It should be noted that when User 2 attempts to register a web account for the first time, there may be cases where an app account or web account is already registered with the same phone number. For example, this could happen if the same User 2 previously installed a user application but uninstalled it for various reasons, and then subsequently made a web-based ride request. Alternatively, another User 2 may have registered an app account or web account, then canceled the phone number, and then taken over the other User 2's phone number to make a web-based ride request using the same phone number. However, User 2 can only set up one user account, including web and app accounts, for one phone number. Therefore, if there is a duplicate user account registration request, the dispatch management server 50 updates the user account according to the past ride history associated with that phone number.

[0035] Figure 7 is a flowchart illustrating the processing performed by the dispatch management server 50 when a web account is registered. Figure 7 illustrates the processing when a web dispatch request is made using the same phone number, given that there is a history of app accounts or web accounts being registered in the past.

[0036] When User 2 attempts to register a web account in order to make a web-based ride request, the dispatch management server 50 determines whether the same phone number is already registered as an app account for app-based ride requests (S20). If the result is that an app account is already registered (YES in S20), the dispatch management server 50 asks User 2 whether they want to deactivate the app account (S21). If User 2 does not recognize the app account and requests that the app account be deactivated (YES in S21), the dispatch management server 50 deactivates the phone number of the app account and registers a new web account for the web-based ride request (S22). Here, the dispatch management server 50 may completely delete the app account in response to its deactivation, or it may continue to save only the phone number in a deactivated state in order to retain the ride history. On the other hand, if user 2 remembers that they had previously registered an app account and does not request to deactivate the app account (NO in S21), the dispatch management server 50 will move from the current website to the application's store page to prompt the user to reinstall the application (S23).

[0037] In this example, if the same phone number is already registered as an app account (YES in S20), the dispatch management server 50 asks user 2 whether to disable the app account (S21), and if user 2 does not request to disable the app account (NO in S21), the user is redirected from the current website to the application's store page (S23). However, the dispatch management server 50 may, not limited to this case, disable the phone number associated with the app account and register a new web account for the web dispatch request without asking user 2 whether to disable the app account if the same phone number is already registered as an app account (YES in S20). In this case, user 2 can register a web account for the web dispatch request early, regardless of whether the same phone number is already registered as an app account.

[0038] Furthermore, if no app account is registered (NO in S20), the dispatch management server 50 determines whether the same phone number is already registered as a web account for web dispatch requests, that is, whether a web dispatch request has been made through the same phone number (S24). If the result is that it is already registered as a web account (YES in S24), the dispatch management server 50 determines whether the most recent web dispatch request by the same web account was made within a predetermined period (for example, 90 days) (S25). If the result is that the web dispatch request was made within the predetermined period (YES in S25), the dispatch management server 50 considers the current web account to belong to the same user 2 as the existing web account, and accepts the web dispatch request using the already registered web account without registering a new web account (S26). On the other hand, if a web dispatch request was made before the specified period (NO in S25), the dispatch management server 50 deletes and invalidates the existing web account, registers a new web account for the current web dispatch request, and accepts the dispatch request (S27). Here, the 90 days exemplified as the specified period is the standard period for telephone number recycling. Therefore, the same user account within 90 days is considered to be a dispatch request from the same user terminal 20 and the same user 2.

[0039] Furthermore, if a web account is not registered (NO in S24), the dispatch management server 50 registers the web account created by the web dispatch request as a new web account and accepts the dispatch request (S28).

[0040] With this configuration, when User 2 attempts to request a ride via the web, even if they have previously made a ride request via the web or app, or if another User 2 has made a ride request via the web or app using the same phone number, User 2 will still be able to properly register their user account and request a ride.

[0041] (Vehicle dispatch request storage process S2) Returning to the explanation of Figure 6, the user terminal control unit 170 of the dispatch management server 50 controls the user application or website of the user terminal 20 and processes dispatch requests entered through the user application or website. 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 setting items 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 service area identifier and the time the dispatch request was received with the dispatch request, which includes the information of the various setting items mentioned above, received from the user terminal 20, and sequentially stores them in the storage device 154.

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

[0043] (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 said Euclidean distance by a predetermined speed (e.g., the average speed when vehicle 32 is operating). Note that the operating state of vehicle 32 mainly refers to the pick-up state (the state in which the vehicle is traveling toward user 2's pick-up location) and the passenger state (the state in which the vehicle is traveling with user 2 on board), and does not include the stationary state in which the vehicle is waiting for a dispatch request. Furthermore, the dispatching unit 172 may, as an extraction criterion, further limit the number of vehicles 32 to be extracted to a predetermined number (for example, 10 vehicles) based on the distance between the boarding location and the current location of the vehicle 32, or the estimated arrival time to the boarding location, in descending order.

[0044] (Pair generation process S5) The dispatch unit 172 extracts at least one candidate vehicle that satisfies a predetermined pairing condition from the vehicles 32 extracted in the vehicle extraction process S4 for each dispatch request extracted in the dispatch request extraction process S3, and associates the extracted candidate vehicle with the dispatch request. Here, the pairing condition is that the acceptable items of the vehicle 32 match all of the setting items of the dispatch request. For example, if the vehicle attribute included in the setting items of the dispatch request is "compatible with sliding doors," the dispatch unit 172 determines that it "matches" if the attribute included in the acceptable items of the vehicle 32 is a sliding door. If even one of the acceptable items of the vehicle 32 does not match the setting items of the dispatch request, the dispatch unit 172 determines that the vehicle 32 does not satisfy the pairing condition. On the other hand, if the acceptable items of the vehicle 32 match all of the setting items of the dispatch request, the dispatch unit 172 associates the vehicle 32 with the dispatch request as a candidate vehicle that satisfies the pairing condition of the dispatch request.

[0045] Next, the dispatch unit 172 estimates the estimated arrival time of each assigned candidate vehicle at the pick-up location for each dispatch request and associates it with each candidate vehicle. Since the relative positions of user 2 who made the dispatch request and vehicle 32 differ for each dispatch request, the estimated arrival time will differ for each dispatch request, even for the same candidate vehicle.

[0046] Next, the dispatch unit 172 sets a vehicle priority for each pair of candidate vehicles associated with each dispatch request. 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.

[0047] However, depending on the relative positions of user 2 and vehicle 32, the highest priority candidate vehicle may overlap in multiple dispatch requests. In such cases, the dispatch management server 50 will be unable to appropriately assign the candidate vehicle as the vehicle to be dispatched to the dispatch request. Therefore, the dispatch unit 172 performs matching between the dispatch request and the candidate vehicle.

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

[0049] In this way, by matching multiple dispatch requests with multiple vehicles at once, it becomes possible to comprehensively determine the relative locations of User 2 and the vehicles, compared to matching dispatch requests sequentially and individually, enabling more efficient dispatching.

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

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

[0052] If, for any reason, driver 3 is unable to accept the dispatch request, driver 3 will either tap the "Request Rejected" button displayed on the input device 136 of the vehicle terminal 30 to reject the dispatch request, or will not tap the position corresponding to "Request Accepted". The vehicle 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 (acceptance response) from the vehicle terminal 30 during this waiting time, it determines that the driver 3 of the dispatch target vehicle has not accepted the dispatch request. 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 in the matching process S6 as the new dispatch target vehicle. Next, the vehicle terminal control unit 174 notifies the vehicle terminal 30 of the other vehicle 32 that has become a dispatch target vehicle of information indicating that it has become a dispatch target vehicle (dispatch target notification).

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

[0054] Furthermore, the dispatch management server 50 manages dispatch statuses that indicate the status of assigning a vehicle 32 to each dispatch request in stages, even after dispatch is confirmed. For example, the dispatch management server 50 sets the dispatch status to "Searching for a vehicle" until it assigns a vehicle to a dispatch request. When the dispatch management server 50 confirms the dispatch of a vehicle to a dispatch request, it stores the date and time and changes the dispatch status to "Dispatch Confirmed". When the vehicle 32 reaches the pick-up location or its vicinity (for example, within 80m), the dispatch management server 50 stores the date and time and changes the dispatch status to "Arriving Soon". When the dispatch status is "Arriving Soon", and the driver 3 arrives at the pick-up location (arrives in person) and operates the arrival switch via the vehicle terminal 30, the dispatch management server 50 stores the date and time and changes the dispatch status to "Arrived". Furthermore, when the vehicle 32 picks up user 2 at the pick-up location, the dispatch management server 50 stores the date and time and changes the dispatch status to "on board." Also, when the vehicle arrives at the drop-off location and payment is completed, the dispatch management server 50 stores the date and time, changes the dispatch status to "boarding completed," terminates the management of that dispatch status, and saves it as dispatch history.

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

[0056] The dispatch management method using the dispatch management system 1 described above stores information on multiple dispatch requests and multiple vehicles 32 and matches them at once. By shortening the storage time, the frequency of dispatch matching can be increased, enabling efficient dispatch while maintaining convenience for the user 2.

[0057] Here, we will describe in detail the processing flow of the dispatch management method shown in Figure 6. As mentioned above, the dispatch request processing S1 and the dispatch request storage processing S2 are processed asynchronously for each dispatch request, independently of other dispatch requests. However, the dispatch request extraction processing S3, vehicle extraction processing S4, pair generation processing S5, and matching processing S6 are all dispatch requests that arise in the business area and execution timing units, so they must be executed synchronously at once. As a result, for example, there will be no delay in dispatching a dispatch request received immediately before the current execution timing, but there may be a delay of the processing period in dispatching a dispatch request received immediately after the previous execution timing. Therefore, the dispatch management server 50, when it can determine that there is a high probability of accepting the dispatch request, pre-matches the dispatch request with the vehicle 32 without waiting for the dispatch request to be confirmed.

[0058] Figure 8A is a first timing chart showing the processing flow of a ride-hailing request, and Figure 8B is a second timing chart showing the processing flow of a ride-hailing request. Figure 8A shows the processing flow of an app-based ride-hailing request, and Figure 8B shows the processing flow of a web-based ride-hailing request. In the example in Figure 8, four sets of users 2a, 2b, 2c, and 2d each make a ride-hailing request within a designated service area, and four vehicles 32 become confirmed vehicles.

[0059] App-based ride-hailing requests made through a user application have two states: a confirmed state where user 2 has confirmed the app-based ride-hailing request, and an unconfirmed state where the app-based ride-hailing request is not yet confirmed. However, even when an app-based ride-hailing request is in an unconfirmed state, it may be in a matching-possible state where the necessary parameters for the app-based ride-hailing request have been determined and matching is possible. For example, when user 2 sets the necessary parameters for an app-based ride-hailing request through the user application, they perform an operation equivalent to an application via the input device 126 to make the request. However, the content of the application may be incorrect or different from what was intended. Therefore, after the application result is displayed on the display device 124 of the user terminal 20, user 2 can cancel the application after a predetermined time (for example, 5 seconds). In this case, because user 2 has performed an operation equivalent to an application, the app-based ride-hailing request is in a matching-possible state, even though it is in an unconfirmed state, and after a predetermined time has elapsed since that operation, the app-based ride-hailing request becomes confirmed.

[0060] Here, as shown in Figure 8A, the dispatch request unit 160 of the user terminal 20 sends an unconfirmed app dispatch request to the dispatch management server 50 in response to the matching availability. This process corresponds to dispatch request processing S1. Therefore, the unconfirmed app dispatch request also includes the parameters necessary for the app dispatch request. The dispatch management server 50 executes dispatch request storage processing S2 for each unconfirmed app dispatch request. Once the storage of app dispatch requests is complete for each service area and execution timing unit, and it is time for execution, the dispatch unit 172 executes dispatch request extraction processing S3, vehicle extraction processing S4, pair generation processing S5, and matching processing S6 all at once. Then, after a predetermined time has elapsed since the operation corresponding to the application and the app dispatch request is confirmed, as shown in Figure 8A, the dispatch request unit 160 of the user terminal 20 sends the confirmed app dispatch request to the dispatch management server 50 again. The vehicle terminal control unit 174 checks at intervals of several hundred milliseconds whether it has received a confirmed app dispatch request from the user terminal 20. When the app dispatch request changes from an unconfirmed state to a confirmed state, it immediately executes the dispatch target notification process S7. Subsequently, the acceptance response process S8 and the vehicle dispatch completion notification process S9 are executed. After that, the user terminal control unit 170 executes the user dispatch completion notification process S10. Here, the execution of the dispatch target notification process S7 and subsequent processes is brought forward in response to the dispatch request, significantly reducing the waiting time until the dispatch is confirmed for the vehicle 32 and user 2.

[0061] Furthermore, with web-based ride-hailing requests, there are two states: an unconfirmed state where user 2 has only entered the parameters related to the web-based ride-hailing request, and a confirmed state where the web-based ride-hailing request is confirmed by registering a web account. Here, similar to app-based ride-hailing requests, even if a web-based ride-hailing request is in an unconfirmed state, it may be in a matching-enabled state where the necessary parameters for the web-based ride-hailing request have been confirmed and matching is possible.

[0062] Here, as shown in Figure 8B, the dispatch request unit 160 of the user terminal 20 sends an unconfirmed web dispatch request to the dispatch management server 50 in response to the matching availability. This process corresponds to dispatch request processing S1. Therefore, the unconfirmed web dispatch request also includes the parameters necessary for the web dispatch request. The dispatch management server 50 executes dispatch request storage processing S2 for each unconfirmed web dispatch request. When the storage of web dispatch requests is completed for each service area and execution timing unit, and it is time for execution, the dispatch unit 172 executes dispatch request extraction processing S3, vehicle extraction processing S4, pair generation processing S5, and matching processing S6 all at once. At this time, as shown in Figure 8B, the user terminal control unit 170 sends dispatch information, such as estimated arrival time, ride time, and fare, for the vehicle 32 that has been identified as a dispatch target vehicle in matching processing S6 to the user terminal 20. Then, when user 2 checks the dispatch information through user terminal 20, the dispatch management server 50 registers a web account as shown in Figure 8B. The vehicle terminal control unit 174 checks at intervals of several hundred milliseconds whether or not the web account has been registered, and as soon as the web account is registered, it immediately executes the dispatch target notification process S7. After that, the acceptance response process S8 and the vehicle dispatch completion notification process S9 are executed. After that, the user terminal control unit 170 executes the user dispatch completion notification process S10. In this way, similar to app dispatch requests, the execution of the dispatch target notification process S7 and subsequent processes is brought forward for web dispatch requests, and the waiting time from web account registration to dispatch confirmation is significantly reduced. The web dispatch request will be described in detail below.

[0063] (Understanding dispatch requests) Figure 9A is a first explanatory diagram illustrating the operation of the user terminal control unit 170, and Figure 9B is a second explanatory diagram illustrating the operation of the user terminal control unit 170. In response to user 2's operation, the dispatch request unit 160 of the user terminal 20 launches a web browser, accesses the website for the dispatch management system 1, and allows user 2 to view the first web page (TOP page). Then, the user terminal control unit 170 of the dispatch management server 50 displays a map 210 of a predetermined range including the location of the user terminal 20, the location of the user terminal 20 212, and vehicles 214 located near the user terminal 20 on the first web page of the user terminal 20, as shown in Figure 9A. The dispatch unit 172 provisionally assigns a vehicle 32 to the dispatch request in response to the user 2's input of the pick-up location and drop-off location. When vehicle 32 is provisionally assigned, the user terminal control unit 170 displays dispatch information, such as an image 216 showing the pick-up location, drop-off location, estimated arrival time, and fare, on the first web page of the user terminal 20.

[0064] Then, when User 2 confirms the dispatch information and registers a web account through User Terminal 20, the dispatch unit 172 confirms the dispatch request and sends a dispatch notification to the vehicle to be dispatched. In response to the acceptance response from the vehicle to be dispatched, User Terminal Control Unit 170 displays a second web page showing the dispatch status on the display device 124 of User Terminal 20, as shown in Figure 9B. Here, the second web page is a web page that can be accessed from the first web page and is a web page that is different from the first web page and is indicated by a unique URL for each User 2. Then, User Terminal Control Unit 170 displays the message "Dispatch confirmed" indicating the dispatch status "Dispatch confirmed" in the message box 218 that shows the dispatch status on the second web page. In addition, User Terminal Control Unit 170 displays the estimated arrival time in the message box 220. The User Terminal Control Unit 170 may also display vehicle information, such as the taxi company name, driver name, vehicle image, and license plate number, in the message box 220 in addition to the estimated arrival time. The user terminal control unit 170 may also display in the message box 220 the time period during which a cancellation fee will be charged if user 2 cancels the dispatch request (for example, 5 minutes after the dispatch status changes to "arrived").

[0065] The user terminal control unit 170 also changes the message in the message box 218 on the second web page in accordance with the change in the dispatch status. For example, if the dispatch status is "Searching for a vehicle", the user terminal control unit 170 displays the message "Arranging a vehicle" in the message box 218. Also, if the dispatch status is "Dispatch confirmed", the user terminal control unit 170 displays the message "Dispatch confirmed" in the message box 218 as described above. Also, if the dispatch status is "Arriving soon", the user terminal control unit 170 displays the message "Arriving soon" in the message box 218. Also, if the dispatch status is "Arrived", the user terminal control unit 170 displays the message "Arrived" in the message box 218. Also, if the dispatch status is "Boarding", the user terminal control unit 170 displays the message "Boarding now" in the message box 218. Also, if the dispatch status is "Boarding complete", the user terminal control unit 170 displays the message "Thank you for riding with us".

[0066] Furthermore, if the dispatch status is "Arriving Soon," the user terminal control unit 170 displays a meeting number in the message box 220 instead of the time when a cancellation fee will be charged. The meeting number is a common identifier that identifies the web dispatch request between user 2 and the dispatched vehicle, and is represented, for example, by a three-digit number. Also, if the dispatch status is "Arrived," the user terminal control unit 170 displays the boarding deadline in the message box 220 in addition to the meeting number.

[0067] User 2 can check the dispatch status by referring to the second web page on the display device 124 of the user terminal 20. However, unlike app-based dispatch requests, if User 2 closes the website in the middle of a web-based dispatch request (leaves the website), User 2 must revisit the website to find out the results of the dispatch request (pickup location, drop-off location, estimated arrival time, fare, etc.). Furthermore, even if User 2 is able to revisit the website, it is difficult to return to the state in which they made the dispatch request if the session is different, and as a result, they are unable to grasp the dispatch result. Here, a session refers to the period from the start to the end of communication, and is disconnected if User 2 intentionally leaves the website or if the session connection time has elapsed for a predetermined period of time (e.g., 1 hour). In this embodiment, User 2 is made able to revisit the website with simple operations, and is able to properly grasp the dispatch result even with web-based dispatch requests.

[0068] Specifically, the user terminal control unit 170, at a predetermined timing, refers to the phone number of the web account and sends link information (short message) containing a URL that allows access to a link specific to the web dispatch request, such as a second web page, to the user terminal 20 via SMS. User 2 obtains the link via SMS and selects (clicks) the link. In response to the user terminal 20's request to connect to the link, the user terminal control unit 170 displays the second web page on the user terminal 20 and displays the updated dispatch status on the second web page. By viewing the second web page, user 2 can obtain various information regarding the dispatch result, such as the dispatch status and estimated arrival time. Furthermore, since the user terminal control unit 170 sends the link that allows access to the second web page to the user terminal 20, which can be uniquely identified by its phone number, via SMS, there is no risk of the short message or link being viewed by a third party.

[0069] At this time, the user terminal control unit 170 sends the link destination regardless of whether the session to the website (first webpage or second webpage) used when the app-based ride request was made from the user terminal 20 has been disconnected. With this configuration, even if the website session is disconnected, user 2 can easily obtain various information regarding the ride dispatch result by simply accessing the link destination included in the short message.

[0070] Furthermore, the user terminal control unit 170 may send a link in response to updates in the dispatch status. For example, the user terminal control unit 170 sends a link via SMS each time the dispatch status changes from "Searching for a vehicle" → "Dispatch confirmed" → "Arriving soon" → "Arrived" → "Boarding" → "Boarding complete". Note that SMS incurs communication charges. Therefore, the user terminal control unit 170 may only send a link when the dispatch status changes to "Dispatch confirmed" or "Arrived," which are particularly necessary. By referring to the link at the "Dispatch confirmed" timing, user 2 can understand that the dispatch management server 50 has accepted the web dispatch request and that vehicle 32 has been secured. Also, by referring to the link at the "Arrived" timing, user 2 can understand that vehicle 32 is now available for boarding and can identify the vehicle 32 to board. Thus, even if the link is only sent when the vehicle is "dispatch confirmed" or "arrived," User 2 can access the link received at any of these times and understand the detailed dispatch results through the second webpage. In other words, User 2 can understand all changes in the dispatch status, not just "dispatch confirmed" and "arrived," through the second webpage. Therefore, it is possible to appropriately provide User 2 with detailed and up-to-date dispatch results while suppressing SMS communication costs.

[0071] Furthermore, the link destination transmitted by the user terminal control unit 170 is associated with a web-based ride-hailing request specific to user 2, allowing for the unique identification of the first web-based ride-hailing request. Therefore, through this link, user 2 can not only view the second webpage, but also access the ride-hailing results of the web-based ride-hailing request via the second webpage.

[0072] However, the link destination transmitted by the user terminal control unit 170 is configured to identify the web dispatch request itself, but not to identify the changing dispatch status. When the user terminal control unit 170 identifies the web dispatch request via such a link destination, it refers to the dispatch history associated with that web dispatch request and displays the dispatch status on the second web page. In addition, the dispatch request unit 160 of the user terminal 20 polls the dispatch management server 50 at predetermined intervals while the session on the second web page is ongoing, and if the dispatch status has been updated, it displays the updated dispatch status on the second web page. With this configuration, regardless of whether the dispatch status has been updated or not, user 2 can check the dispatch status at that time simply by accessing the link destination 1 that identifies only their web dispatch request. Therefore, once user 2 obtains the link destination via SMS, they can refer to the dispatch results via the second web page using the initially obtained link destination without having to obtain the link destination again via SMS.

[0073] Furthermore, the user terminal control unit 170 may include a short message indicating the dispatch result as text in the short message sent via SMS, in addition to the link associated with the web dispatch request. For example, when the dispatch status changes to "dispatch confirmed," the user terminal control unit 170 includes text information indicating the dispatch status, such as the message "dispatch confirmed," in addition to the link associated with the web dispatch request. With this configuration, user 2 can grasp the minimum dispatch result, such as the change in dispatch status, even if they are in a situation where it is difficult to browse the website.

[0074] Furthermore, the user terminal control unit 170 may include a meeting number as text in the message sent via SMS, in addition to the link associated with the web-based ride-hailing request. With this configuration, even if user 2 is unable to access the website, they can confirm that the vehicle 32 that arrives at the pick-up location is the vehicle confirmed for their web-based ride-hailing request.

[0075] Alternatively, instead of sending a short message containing a link to the user terminal 20 via SMS, or in addition to doing so, the user terminal control unit 170 may also execute a web push notification while the website session is active. User 2 can obtain the link via the web push notification and view the second web page by selecting the link. With this configuration, even if the website session is disconnected, user 2 can easily obtain various information regarding the dispatch result through a simple operation of accessing the link included in the web push notification. Web push notifications often have lower communication costs than SMS. Therefore, web push notifications can send dispatch results more frequently than SMS. For example, the user terminal control unit 170 may send the link not only when the dispatch status becomes "dispatch confirmed" or "arrived," but also when the status becomes "boarding completed," similar to SMS. Alternatively, the user terminal control unit 170 may send a link each time the dispatch status changes from "Searching for a vehicle" → "Dispatch confirmed" → "Arriving soon" → "Arrived" → "Boarding" → "Boarding complete".

[0076] As mentioned above, User 2 can access the second webpage simply by accessing the link sent via SMS or web push notification. Here, we will explain the process by which User 2 attempts to access the first webpage in order to make a web-based ride-hailing request.

[0077] Figure 10 is a flowchart illustrating the display of a website on the user terminal 20. When user 2 attempts to view the first web page to make a web dispatch request, the dispatch management server 50 determines whether a session for the website is already connected or not, in response to the access from the user terminal 20 (S30). If a session for the website is already connected (YES in S30), the dispatch management server 50 proceeds to step S33. If a session is not connected, i.e., the session is disconnected (NO in S30), the dispatch management server 50 requests the input of a web account, i.e., a telephone number (S31). The dispatch management server 50 repeats the process in step S32 until a web account is entered and the web account is authenticated (NO in S32). Once a web account is entered and the web account is authenticated (YES in S32), the server proceeds to step S33. In this web account authentication, the identity of the web account associated with the link destination and the entered web account is confirmed. With this configuration, user 2 can submit a web-based ride request without needing to re-authenticate via their web account as long as the session is connected. Furthermore, if the session is disconnected, user 2 cannot submit a web-based ride request without authentication of the user terminal 20. Therefore, fraudulent ride requests through impersonation can be prevented.

[0078] Next, the dispatch management server 50 determines whether a web-based dispatch request has already been made using the web account (S33). If the result is that a web-based dispatch request has already been made (YES in S33), the dispatch management server 50 redirects the user to the second web page (server redirect) and displays the dispatch results of the web-based dispatch request on the user terminal 20 (S34). The reason for redirecting to the second web page is that there is no need to display the first web page since a web-based dispatch request has already been made, and also to avoid duplicate web-based dispatch requests caused by the user returning to the first web page in the browser. In this way, if a web-based dispatch request has already been made using the web account, the user is automatically redirected to the second web page, allowing the user to easily access the website again.

[0079] Furthermore, if a web dispatch request has not yet been made using the web account (NO in S33), the dispatch management server 50 displays the first web page on the user terminal 20 (S35).

[0080] In this example, the dispatch management server 50 determines whether a web dispatch request has already been made using the web account (S33), and if the request has not yet been made (NO in S33), it displays the first web page on the user terminal 20 (S35). However, the dispatch management server 50 may, without determining whether a web dispatch request has already been made, redirect to the second web page and display the dispatch results of the web dispatch request on the user terminal 20 (S34). In this way, user 2 can perform all operations related to the web dispatch request through the second web page.

[0081] In the embodiment described above, app-based ride-hailing requests and web-based ride-hailing requests were treated with the same priority, and matching was performed with the same conditions. However, the system is not limited to this example; vehicle 32 may be assigned to app-based ride-hailing requests with priority over web-based ride-hailing requests. This encourages user 2 to install the user application. Alternatively, vehicle 32 may be assigned to web-based ride-hailing requests with priority over app-based ride-hailing requests. In this way, user 2, who attempts to make a web-based ride-hailing request, will expect to be assigned vehicle 32 with priority, increasing the frequency of use of web-based ride-hailing requests, and ultimately, as will be described later, will install a user application that is convenient in terms of accessibility and functionality.

[0082] (Transfer of web-based ride-hailing requests) By the way, there are the following differences in the ease of trying out ride-hailing requests between web-based and app-based requests. As mentioned above, with web-based ride-hailing requests, user 2 can make a request simply by accessing the website and entering their phone number. In contrast, with app-based ride-hailing requests, when registering an app account, user 2 must enter information that identifies them (e.g., name, gender, date of birth), information that identifies the user's device 20 (e.g., phone number), and information that identifies the payment method (e.g., credit card number). However, not all information that can be entered during app account registration is required when making an app-based ride-hailing request; for example, user 2 can make an app-based ride-hailing request even if the information that identifies the payment method is not entered. In any case, when trying out app-based ride-hailing requests, it can be cumbersome to make a request, and entering parameters can be time-consuming. Therefore, in addition to app-based ride-hailing requests, web-based ride-hailing requests are also provided as mentioned above. In this way, we can provide users 2, who have not yet installed the user application, with a system that allows them to easily request a ride from the website, allowing them to experience a level of convenience not available when using services like hailing rides on the street or waiting at train stations.

[0083] However, there are differences in convenience between web-based and app-based ride-hailing requests, as follows: With web-based ride-hailing requests, user 2 must specify a website via a web browser each time to make a request. In contrast, with app-based ride-hailing requests, once user 2 has installed the user application, they can make a request simply by selecting its icon. Furthermore, web-based ride-hailing requests are difficult to trace due to the disconnection of the website session, making it difficult to associate them with past web-based ride-hailing requests made by the same user 2. In contrast, app-based ride-hailing requests are uniformly executed from an application installed on user terminal 20, making it relatively easy to associate them with past app-based ride-hailing requests.

[0084] Furthermore, the dispatch management system 1 allows for multiple-vehicle dispatch requests, where multiple vehicles are requested simultaneously, and continuous dispatch requests, where the next dispatch request is made until the current one is completed. The dispatch management system 1 also provides services such as priority passes and AI reservations. A priority pass is a priority dispatch service that allows users to be dispatched a vehicle before other users by paying an additional fee on top of the regular fare. AI reservations are a dispatch reservation service that allows users to reserve a vehicle 32 in advance by specifying their desired pick-up location and time. While these services, such as multiple-vehicle dispatch requests, continuous dispatch requests, priority passes, and AI reservations, are available for app-based dispatch requests, their use is restricted in whole or in part for web-based dispatch requests. Therefore, app-based dispatch requests are more convenient than web-based dispatch requests.

[0085] Furthermore, if app-based ride-hailing requests prove more convenient than web-based requests, getting user 2 to install the user application could potentially increase the frequency of ride-hailing requests. Therefore, user 2, who has not installed the user application or has accessed the website from external route search software, will first try the web-based ride-hailing request, which allows for simplified input, to recognize the usefulness of the ride-hailing management system 1, and then desire to switch to the more convenient app-based ride-hailing request. In this way, the number of users of both web-based and app-based ride-hailing requests can be increased.

[0086] Therefore, in this embodiment, we aim to further differentiate web-based ride-hailing requests and app-based ride-hailing requests in terms of functionality (convenience), making it easier for user 2 to switch to the more convenient app-based ride-hailing request after trying out the web-based request. For example, as mentioned above, web-based ride-hailing requests make it difficult to identify the source of access due to the disconnection of the website session, making it difficult to associate that web-based ride-hailing request with past web-based ride-hailing requests made by the same user 2. As a result, user 2 can board vehicle 32 through a web-based ride-hailing request, but cannot retrospectively check their ride history, such as where they boarded and where they went, or how much the fare was.

[0087] Here, even after making a ride request via the web, users can retrospectively check their ride history simply by installing the user application, thereby promoting the transition from web-based ride requests to app-based ride requests. The ride management server 50 enables retrospective verification of ride history by associating the ride history of web accounts with that of app accounts, as shown below.

[0088] The dispatch management server 50 manages web accounts and app accounts independently. However, each user account is exclusively associated with a phone number. In other words, not only are the same phone numbers not associated with other web accounts or other app accounts, but the same phone numbers are not associated between web accounts and app accounts. Put another way, in both web dispatch requests and app dispatch requests, the user account can be uniquely identified by its phone number.

[0089] To ensure the exclusivity of such user accounts, in this embodiment, if user 2 executes a web-based ride request and then an app-based ride request, if the phone number is the same, the user account is considered to be the same, and the ride history associated with the web account is integrated into the app account. In other words, if a web-based ride request is executed first by the same user account, and then an app-based ride request is executed, the ride management server 50 associates the ride history of the web-based ride request with the app account along with the ride history of the app-based ride request.

[0090] However, as mentioned above, after another user 2 makes a web-based ride request, they may cancel their phone number and then take over the other user 2's phone number, making a web-based ride request using the same phone number. In this case, the ride history of the web-based ride request made by the other user 2 would also be associated with the user's app account. Therefore, the ride management server 50 considers a web-based ride request to have been made by the same user 2 and includes it in the ride history if the request was made within a predetermined period (e.g., 90 days) before the app-based ride request was made. On the other hand, if the request was made earlier than the predetermined period before the app-based ride request was made, the ride management server 50 considers it to have been made by another user 2 and does not include it in the ride history. In this case, the ride management server 50 may retain the web-based ride request in the storage device 154 for a predetermined period and then delete it.

[0091] In this system, if the timing of a web-based ride request is within a predetermined period, it is considered that the same user 2 made the request. Therefore, even if the request is made before the predetermined period following an app-based ride request, it may still be considered a request by the same user 2. For example, this could occur if a web-based ride request was made by the same user account within the predetermined period prior to an app-based ride request, and then another web-based ride request was made by the same user account within the predetermined period prior to that request. The ride management server 50 will also consider any web-based ride requests made by the same user account within the predetermined period prior to that request as having been made by the same user 2 and will include them in the ride history.

[0092] Figure 11 is a flowchart illustrating the processing performed by the dispatch management server 50 when an app account is registered. Figure 11 illustrates the processing when an app-based ride request is made in a situation where there is a history of web-based ride requests being made with the same user account in the past.

[0093] When user 2 attempts to register an app account via an app-based ride-hailing request, the dispatch management server 50 determines whether a web-based ride-hailing request has been made using the same phone number within a predetermined period and whether it has been registered as a web account (S40). If, as a result, a web account has already been registered within the predetermined period (YES in S40), the dispatch management server 50 considers it to be a web-based ride-hailing request by the same user 2, integrates that web-based ride-hailing request into the app account (S41), and repeats the process from step S40. However, in the process of step S40 via step S41, the dispatch management server 50 targets the integrated web-based ride-hailing request and determines whether a web-based ride-hailing request has been made using the same phone number within a predetermined period from the time of the integrated web-based ride-hailing request and whether it has been registered as a web account. In this way, it becomes possible to integrate multiple web-based ride-hailing requests over a long period that are considered to be from the same user 2 into the app account. If a web account has not already been registered within the predetermined period (NO in S40), the dispatch management server 50 terminates the integration process into the app account.

[0094] In this explanation, we described an example where the dispatch management server 50 determines when a web dispatch request is made using the same user account as the web dispatch request held in the storage device 154, and then integrates the web dispatch request into the app account. However, the integration process into the app account can also be achieved by controlling the retention period in the storage device 154, not just in this case. For example, the dispatch management server 50 retains web dispatch requests only for a retention period (e.g., 90 days). If a web dispatch request is made with the same phone number within that retention period, the dispatch management server 50 resets the retention period count and starts counting from 1 again to retain the web dispatch request. On the other hand, if no web dispatch requests are made with the same phone number within that retention period, the dispatch management server 50 deletes all web dispatch requests made with the same phone number, including past requests. If an app dispatch request is made with the same phone number while the retention period is still ongoing, the dispatch management server 50 integrates the series of web dispatch requests into the app account. The retention period after an app-based ride request is made only needs to be longer than the retention period after a web-based ride request is made. For example, it may be set to a finite number of years or to be unlimited.

[0095] While web-based ride-hailing requests have limited services, app-based ride-hailing allows user 2 to access various services not available through web-based requests. For example, user 2 can view their ride history through the user application. This history includes information such as pickup location, drop-off location, and fare. User 2 can also request receipts for each web-based and app-based ride-hailing request and send tips afterward through the user application. Furthermore, user 2 can leave a rating of the driver 3 of the vehicle 32 they requested in their ride history, track their total number of rides, and accumulate ride points through app-based ride-hailing requests through the user application.

[0096] Here, by integrating web-based ride-hailing requests into the app account, user 2 can receive the same services for web-based ride-hailing requests they have made in the past as they do for app-based ride-hailing requests. Therefore, by installing the user application, user 2 can, for example, integrate web-based ride-hailing requests into their app account and have receipts for web-based ride-hailing requests issued retroactively.

[0097] Furthermore, once User 2 installs the user application, even if they subsequently attempt to request a ride via the web browser, the dispatch management server 50 will automatically launch the user application and have User 2 execute the app-based ride request. In other words, while the user application is installed, it is not possible to make a web-based ride request. This is because, with the user application installed, the user application is more functional, making it unnecessary to make a web-based ride request. Therefore, on the user terminal 20, the user application is launched first, and web-based guest ride requests are not executed. This configuration allows User 2 to use the highly convenient user application. However, as mentioned above, User 2 can make web-based ride requests by uninstalling the user application.

[0098] In the above explanation, we described examples where simultaneous requests for multiple vehicles or consecutive requests are restricted in web-based ride-hailing requests. However, due to the characteristics of web-based ride-hailing requests, various services may be restricted beyond these examples. For example, in ride-hailing management system 1, cancellation of a ride-hailing request may be subject to a charge. Such a subject-charge cancellation is an unauthorized cancellation of a ride-hailing request and is executed by driver 3 when, for example, vehicle 32 arrives (the dispatch status changes to "arrived") and user 2 does not appear within a specified time (e.g., 5 minutes). In web-based ride-hailing requests, only a phone number is required to register a web account, making it difficult to identify user 2, and ride-hailing request cancellations tend to be more frequent than in app-based ride-hailing requests. Therefore, if a web-based ride-hailing request is received, but a web-based ride-hailing request has been canceled in the past for the same web account, the ride-hailing management server 50 displays the message "This service is unavailable due to an unpaid cancellation" and does not execute the web-based ride-hailing request (ride-hailing lock). In this case, User 2 can request a ride via the web again by settling any outstanding cancellation fees. However, the dispatch management server 50 prevents the settlement of cancellation fees during web-based ride requests. User 2 can install the user application and settle the cancellation fees through the settlement function of the user application. In this way, it becomes possible to encourage User 2 to install the user application.

[0099] Here, we have given the example of a responsible cancellation where User 2 does not appear within a predetermined time (e.g., 5 minutes) after Vehicle 32 has arrived (the dispatch status has been changed to "arrived"). However, we can adopt various situations in which it can be determined that User 2 does not intend to board Vehicle 32 after the web dispatch request for Vehicle 32 has been executed. For example, User 2 can cancel the web dispatch request until a predetermined time (e.g., 5 minutes) after the dispatch of Vehicle 32 has been confirmed (the dispatch status has been changed to "dispatch confirmed"). This is to allow User 2 to cancel fraudulent dispatch requests made by impersonating their own phone number. Here, the dispatch management server 50 may treat any cancellations after the predetermined time has passed since the dispatch of Vehicle 32 was confirmed as responsible cancellations.

[0100] Furthermore, the dispatch management server 50 may restrict fraudulent web-based ride requests. Here, a fraudulent ride request refers to the fraudulent submission of multiple web-based ride requests from multiple user terminals 20 in a short period of time. For example, if the dispatch management server 50 receives more web-based ride requests than a predetermined upper limit relative to the total number of app-based ride requests and web-based ride requests, or both, it may temporarily restrict the acceptance of web-based ride requests. The dispatch management server 50 may restrict the acceptance of web-based ride requests nationwide, or within a predetermined range including the pick-up location (for example, 1 km). 2 The acceptance of web-based ride-hailing requests may be restricted to within a certain period. The ride-hailing management server 50 may also restrict the acceptance of web-based ride-hailing requests for a predetermined period of time (for example, 5 minutes). In this way, it is possible to prevent situations in which vehicles 32 are unnecessarily dispatched to designated pick-up locations due to fraudulent web-based ride-hailing requests.

[0101] Thus, the dispatch management device (e.g., dispatch management server 50) that can communicate with the user terminal 20 via the network 6 is equipped with one or more processors, and the processors receive dispatch requests and telephone numbers from the user terminal 20 via a website (e.g., a website managed by the dispatch management server 50, or a website managed by another device but substantially controlled by the dispatch management server 50), assign a vehicle 32 to the dispatch request, update the dispatch status which shows the status of assigning a vehicle 32 in stages, send link information (e.g., short message) including a link destination (e.g., URL) specific to the dispatch request to the user terminal 20 via a messaging service (e.g., SMS), and display the updated dispatch status on the user terminal 20 in response to the user terminal 20's request to connect to the link destination. With this configuration, even if the website session is disconnected, user 2 can easily grasp various information regarding the dispatch result by simply accessing the link destination included in the short message.

[0102] The processor sends link information (e.g., a short message) in response to updates to the dispatch status, and the destination of the link (e.g., a URL) included in the link information remains the same regardless of the update to the dispatch status. With this configuration, regardless of whether the dispatch status has been updated or not, user 2 can check the current dispatch status simply by accessing the link destination of 1 that identifies only their own web dispatch request. Therefore, once user 2 obtains the link destination through the messaging service, they can refer to the dispatch results through the second web page using the initially obtained link destination without having to obtain the link destination again through the messaging service.

[0103] While a session based on a ride request is ongoing, the processor redirects the user terminal 20 to the linked website (e.g., URL) if a new request to browse a website is received, and displays the ride status based on the ride request on the user terminal 20. With this configuration, user 2 can make web-based ride requests without needing to re-authenticate with their web account while the session is connected.

[0104] If the user terminal 20 requests to browse a website after the session based on the ride request has been disconnected, the processor authenticates the user terminal 20. Once authentication is complete, it redirects the user terminal 20 to the linked page and displays the ride status based on the ride request on the user terminal 20. If the session has been disconnected, user 2 cannot make a web ride request without authenticating the user terminal 20. Therefore, fraudulent ride requests due to impersonation can be prevented.

[0105] If the user terminal 20 has an application (e.g., a user application) managed by the dispatch management device (e.g., dispatch management server 50) installed on it, the processor will launch the application on the user terminal 20 when the user terminal 20 requests to browse a website. This configuration allows user 2 to use a highly convenient user application.

[0106] The processor sends text information indicating the dispatch status, in addition to link information, to the user terminal 20 via a messaging service (e.g., SMS). This configuration allows user 2 to understand the dispatch status, even if they are unable to access the website, as a minimum requirement.

[0107] The processor sends information containing a link (e.g., a URL) to the user terminal 20 via web push notification, and in response to the user terminal 20's request to connect to the link, displays the updated dispatch status on the user terminal 20. With this configuration, even if the website session is disconnected, user 2 can easily obtain various information about the dispatch result by simply accessing the link included in the web push notification.

[0108] In this embodiment of the dispatch management method, the computer receives dispatch requests and telephone numbers from the user terminal 20 via a website (for example, a website managed by the dispatch management server 50, or a website managed by another device but substantially controlled by the dispatch management server 50), assigns a vehicle 32 to the dispatch request, updates the dispatch status to show the status of vehicle 32 assignment in stages, sends link information including a link destination specific to the dispatch request to the user terminal 20 via a messaging service (for example, SMS), and displays the updated dispatch status on the user terminal 20 in response to a request from the user terminal 20 to connect to the link destination. With this configuration, even if the website session is disconnected, user 2 can easily grasp various information regarding the dispatch result by simply accessing the link destination included in the short message.

[0109] The program of this embodiment causes the computer to receive dispatch requests and telephone numbers from the user terminal 20 via a website (for example, a website managed by the dispatch management server 50, or a website managed by another device but substantially controlled by the dispatch management server 50), assign a vehicle 32 to the dispatch request, update the dispatch status which shows the status of the vehicle 32 assignment in stages, send link information including a link destination specific to the dispatch request to the user terminal 20 via a messaging service (for example, SMS), and display the updated dispatch status on the user terminal 20 in response to a request from the user terminal 20 to connect to the link destination. With this configuration, even if the website session is disconnected, user 2 can easily grasp various information regarding the dispatch result by simply accessing the link destination included in the short message.

[0110] Furthermore, a dispatch management device (e.g., a dispatch management server 50) that can communicate with the user terminal 20 via the network 6 is equipped with one or more processors, and the processors receive web dispatch requests, which are dispatch requests via a website (e.g., a website managed by the dispatch management server 50, or a website managed by another device but substantially controlled by the dispatch management server 50), and user identifiers that can identify the user (e.g., telephone number, web account) from the user terminal 20, assign a vehicle 32 to the web dispatch request, and store the dispatch history, including the result of assigning a vehicle to the web dispatch request, in association with the user identifier. When an application managed by the dispatch management device (e.g., a user application) is installed on the user terminal 20, the dispatch history of web dispatch requests associated with the same user identifier (e.g., telephone number, web account) as the user identifier transmitted through the application is associated with the user identifier transmitted through the application. Therefore, by installing the user application, user 2 can, for example, integrate previously made web ride-hailing requests into their app account, retrospectively check the dates and payment information of past web ride-hailing requests, and retrospectively issue receipts for past web ride-hailing requests.

[0111] After the application is installed on the user terminal 20, the processor launches the application on the user terminal 20 when a new request to browse a website is received from the user terminal 20. This configuration allows user 2 to use a highly convenient user application.

[0112] The services provided through the application are greater than those provided through the website. This configuration allows user 2 to use a highly convenient user application.

[0113] Certain services provided through the application (e.g., checking past ride request history, requesting multiple rides, requesting consecutive rides, priority passes, AI reservations, etc.) are not available through the website. This configuration allows user 2 to use a highly convenient user application.

[0114] The processor sends link information (e.g., a short message) containing a link (e.g., a URL) specific to the web dispatch request in response to updates to the dispatch status, which progressively indicates the status of assigning vehicle 32. The link destination included in the link information remains the same regardless of updates to the dispatch status. With this configuration, regardless of whether the dispatch status has been updated or not, user 2 can check the dispatch status at that time simply by accessing link 1, which identifies only their web dispatch request. Therefore, once user 2 obtains the link destination via a messaging service (e.g., SMS), they can refer to the dispatch results via a second web page using the initially obtained link destination without having to obtain another link destination via the messaging service.

[0115] In this embodiment, the dispatch management method involves a computer receiving a web dispatch request, which is a dispatch request via a website (for example, a website managed by the dispatch management server 50, or a website managed by another device but substantially controlled by the dispatch management server 50), and a user identifier (for example, a telephone number, a web account) that can identify the user, from a user terminal 20. The computer assigns a vehicle 32 to the web dispatch request and stores the dispatch history, including the result of assigning a vehicle to the web dispatch request, in association with the user identifier. When an application managed by the dispatch management device (for example, a user application) is installed on the user terminal 20, the dispatch history of web dispatch requests associated with the same user identifier (for example, a telephone number, a web account) as the user identifier (for example, a telephone number, an app account) transmitted through the application is associated with the user identifier transmitted through the application. Therefore, by installing the user application, user 2 can, for example, integrate previously executed web dispatch requests into an app account, retrospectively check the date and payment information of past web dispatch requests, or retrospectively issue receipts for past web dispatch requests.

[0116] The program of this embodiment causes the computer to receive web dispatch requests, which are dispatch requests via a website (for example, a website managed by the dispatch management server 50, or a website managed by another device but substantially controlled by the dispatch management server 50), and a user identifier that can identify the user (for example, a telephone number, a web account) from the user terminal 20, assign a vehicle 32 to the web dispatch request, and store the dispatch history, including the result of assigning a vehicle to the web dispatch request, in association with the user identifier. When an application managed by the dispatch management device (for example, a user application) is installed on the user terminal 20, the computer is instructed to associate the dispatch history of web dispatch requests associated with the same user identifier (for example, a telephone number, a web account) as the user identifier transmitted through the application.Therefore, by installing the user application, user 2 can, for example, integrate previously executed web dispatch requests into an app account, retrospectively check the date and payment information of past web dispatch requests, or retrospectively issue receipts for past web dispatch requests.

[0117] In the above example, a telephone number that only User 2 can possess and that uniquely identifies User 2 (more precisely, the user terminal 20 owned by User 2) was used as the user identifier. However, other options are also available, such as My Number, health insurance card number, driver's license number, or email address.

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

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

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

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

Claims

1. A dispatch management device that can communicate with a user terminal via a network, Equipped with one or more processors, The aforementioned processor, The user terminal receives dispatch requests and phone numbers via the website. A vehicle is assigned to the aforementioned dispatch request. The dispatch status is updated to show the status of assigning the aforementioned vehicle in stages. Link information, including the destination of the link specific to the dispatch request, is transmitted to the user terminal via the messaging service. In response to a connection request from the user terminal to the linked destination, the updated dispatch status is displayed on the user terminal. Vehicle dispatch management system.

2. The processor transmits the link information in response to the update of the dispatch status. The dispatch management device according to claim 1, wherein the destination of the link included in the link information remains the same regardless of the update of the dispatch status.

3. The dispatch management device according to claim 1, wherein the processor, while a session based on the dispatch request is ongoing, redirects the user terminal to the link destination when a new request to view the website is received, and displays the dispatch status based on the dispatch request on the user terminal.

4. The aforementioned processor, After the session based on the aforementioned dispatch request is disconnected, if a new request to access the aforementioned website is received from the user terminal, the user terminal will be authenticated. The dispatch management device according to claim 3, wherein, upon completion of the authentication, the user is redirected to the linked destination and the dispatch status based on the dispatch request is displayed on the user terminal.

5. The dispatch management device according to claim 1, wherein the processor, if an application managed by the dispatch management device is installed on the user terminal, launches the application on the user terminal when a new request to browse the website is received from the user terminal.

6. The dispatch management device according to claim 1, wherein the processor transmits, in addition to the link information, text information indicating the dispatch status to the user terminal via a message service.

7. The aforementioned processor, The information containing the aforementioned link is sent to the user's terminal via web push notification. The dispatch management device according to claim 1, which displays the updated dispatch status on the user terminal in response to a request from the user terminal to connect to the linked destination.

8. Computers The website receives dispatch requests and phone numbers from the user's terminal. A vehicle is assigned to the aforementioned dispatch request. The dispatch status is updated to show the status of assigning the aforementioned vehicle in stages. Link information, including the destination of the link specific to the dispatch request, is transmitted to the user terminal via the messaging service. In response to a connection request from the user terminal to the linked destination, the updated dispatch status is displayed on the user terminal. Vehicle dispatch management method.

9. On the computer, The website receives dispatch requests and phone numbers from the user's terminal. A vehicle is assigned to the aforementioned dispatch request. The dispatch status is updated to show the status of assigning the aforementioned vehicle in stages. Link information, including the destination of the link specific to the dispatch request, is transmitted to the user terminal via the messaging service. In response to a connection request from the user terminal to the linked destination, the updated dispatch status is displayed on the user terminal. A program to perform a task.

Images