JP6535713B2 - System, method, and program for managing allocation of vehicle - Google Patents

Description

  The present invention relates to a system, method, and program for managing vehicle allocation.

  Conventionally, a system for managing the allocation of vehicles such as taxis has been proposed (see, for example, Patent Document 1 below). In such a system, the user can request allocation of a vehicle via a smartphone or the like. For example, among a plurality of vehicles managed in the system, a vehicle in an empty state closest to the riding position input by the user Will be dispatched.

JP, 2016-218883, A

  However, even if the vehicle closest to the boarding position is dispatched, if the waiting time until the vehicle arrives at the boarding position is longer than the user's assumption, the degree of satisfaction of the user is reduced. For example, when presenting the estimated waiting time to the user after the vehicle to be allocated is determined, there is also a possibility that the allocation request itself may be canceled if the waiting time is longer than the user's assumption.

  An object of the embodiment of the present invention is to suppress that the waiting time until the allocated vehicle arrives becomes longer than the user's assumption. Other objects of embodiments of the present invention will become apparent by reference to the present specification as a whole.

  A system according to an embodiment of the present invention includes one or more computer processors and is a system for managing allocation of a vehicle, wherein the one or more computer processors are responsive to execution of readable instructions. Processing for receiving from the user a dispatch request accompanied by the specification of the riding position, and assigning a vehicle from among a plurality of vehicles in response to the received dispatch request and Performing the process of requesting the request and the process of requesting the get-off, predicting the waiting time until the assigned vehicle arrives at the specified boarding position, and the predicted waiting time is included in a predetermined range If it is determined that the estimated waiting time is the predetermined range, the requested waiting time may be requested to the allocated vehicle without the predetermined confirmation for the user. If not included in involves requesting geisha to the assigned vehicle through the predetermined confirmation for the user.

  A method according to an embodiment of the present invention is a method for managing allocation of a vehicle, which is executed by one or a plurality of computers, comprising: receiving from the user an allocation request accompanied by specification of a boarding position; Assigning a vehicle from among a plurality of vehicles for the allocation request, and requesting the allocated vehicle to take a ride to a specified boarding position, wherein the step of requesting the reception is the assignment Waiting time until the identified vehicle arrives at the specified boarding position, and if the predicted waiting time falls within a predetermined range, the allocated vehicle is not determined via a predetermined confirmation for the user. Against a request for a car, but if the predicted waiting time is not included in the predetermined range, the division may be performed via the predetermined confirmation for the user. Including to ask a geisha with respect to the vehicle, which was applied.

  A program according to an embodiment of the present invention is a program for managing allocation of a vehicle, and according to the execution on one or more computers, the one or more computers identify the boarding position. A process of receiving from the user an accompanying allocation request, and a process of allocating a vehicle from among a plurality of vehicles in response to the received allocation request, and requesting the allocated vehicle to take a ride to the identified boarding position The process of executing and requesting the take-off predicts a waiting time until the assigned vehicle arrives at the identified boarding position, and the predicted waiting time falls within a predetermined range. Request to the assigned vehicle for taking off the vehicle without a predetermined confirmation for the user, and if the predicted waiting time is not included in the predetermined range, Through said predetermined confirmation for comprising requesting geisha to the assigned vehicle.

  Various embodiments of the present invention prevent the waiting time until the dispatched vehicle arrives from becoming longer than the user's assumption.

BRIEF DESCRIPTION OF THE DRAWINGS The block diagram which shows roughly the structure of the network containing the vehicle allocation management server 10 which concerns on one Embodiment of this invention. FIG. 2 is a block diagram schematically showing the function of a dispatch management server 10. The figure which illustrates the information managed in the allocation request information table. The figure which illustrates the information managed in a vehicle information table. The figure which illustrates the top screen 50. FIG. The flowchart which illustrates the processing which server 10 performs in order to set up the standard of waiting time. The figure which illustrates the boarding position specification screen 60. The figure which illustrates the allocation request screen 70. FIG. The figure which illustrates screen 80 during dispatch. The flowchart which illustrates the processing which server 10 performs according to progress of the period which can cancel a dispatch request. The figure which illustrates the dispatch screen 80 at the time of confirming with a user the decision | availability of a ride request. The figure which illustrates the getting-off request confirmation screen 100. FIG. The figure which illustrates the waiting for waiting screen 90. The figure which illustrates the screen 110 in getting-in-vehicle. The figure which illustrates the arrival report screen 120. The figure which illustrates the boarding report screen 130. The figure which illustrates the getting-off cancellation screen 140. FIG.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram schematically showing the configuration of a network including a vehicle allocation management server 10 according to an embodiment of the present invention. As illustrated, the server 10 is communicably connected to the user terminal 32 and the driver terminal 34 via a network 20 such as the Internet. Although only one user terminal 32 and one driver terminal 34 are illustrated in FIG. 1, the server 10 is communicably connected to a plurality of user terminals 32 and driver terminals 34. The server 10 has a function for managing allocation of a vehicle such as a taxi. The allocation management server 10 is an example of an apparatus that implements all or part of the system of the present invention.

  The allocation management server 10 is configured as a general computer, and as shown in FIG. 1, a CPU (computer processor) 11, a main memory 12, a user I / F 13, a communication I / F 14, and a storage ( Storage device 15 and these components are electrically connected via a bus or the like (not shown).

  The CPU 11 reads various programs stored in the storage 15 or the like into the main memory 12 and executes various instructions included in the programs. The main memory 12 is configured by, for example, a DRAM or the like.

  The user I / F 13 is various input / output devices for exchanging information with the user. The user I / F 13 includes, for example, an information input device such as a keyboard and a pointing device (for example, a mouse and a touch panel), an audio input device such as a microphone, and an image input device such as a camera. The user I / F 13 also includes an image output device (display device) such as a display, and an audio output device such as a speaker.

  The communication I / F 14 is implemented as hardware such as a network adapter, various communication software, and a combination thereof, and is configured to be able to realize wired or wireless communication via the network 20 or the like.

  The storage 15 is configured by, for example, a magnetic disk or a flash memory. The storage 15 stores various programs including an operating system and various data.

  In the present embodiment, the server 10 may be configured using a plurality of computers each having the hardware configuration described above. For example, the server 10 may be configured by a plurality of server devices.

  The user terminal 32 and the driver terminal 34 have a configuration as a general computer, and are configured as, for example, a smartphone, a tablet terminal, a personal computer, and a wearable device. The user terminal 32 is operated by a user who uses a vehicle such as a taxi. Further, the driver terminal 34 is operated by the driver of the vehicle to be allocated.

  In the present embodiment, the vehicle allocation management server 10 is configured to have a function as a web server and an application server, and in response to a request from a web browser or other application that the user terminal 32 or the driver terminal 34 has, The processing is executed, and screen data (for example, HTML data) and control data according to the result of the processing are transmitted. The user terminal 32 and the driver terminal 34 display a web page or other screen based on the received data.

  Next, functions of the vehicle allocation management server 10 according to the present embodiment will be described. FIG. 2 is a block diagram schematically showing the functions of the server 10. As illustrated, the server 10 includes an information storage management unit 40 that stores and manages information, a dispatch request management unit 42 that manages dispatch requests from users, and a dispatch management unit 44 that manages dispatch of vehicles. . These functions are realized by the cooperation of hardware such as the CPU 11 and the main memory 12 and various programs and data stored in the storage 15 etc. This is realized by the CPU 11 executing an instruction included in the program. Further, part or all of the functions shown in FIG. 2 may be realized by cooperation between the vehicle allocation management server 10 and the user terminal 32 or the driver terminal 34, or may be realized by the user terminal 32 or the driver terminal 34. .

  The information storage management unit 40 is constituted by the storage 15 and the like, and stores and manages various information. The allocation request management unit 42 executes various processes related to management of the allocation request. In the present embodiment, the allocation request management unit 42 is configured to receive from the user an allocation request that involves specification of a boarding position. For example, the allocation request management unit 42 receives, from the user, an allocation request accompanied by input of information such as a boarding position via the user terminal 32.

  The allocation management unit 44 executes various processes related to management of allocation. In the present embodiment, the allocation management unit 44 is configured to allocate a vehicle from among a plurality of vehicles in response to the received allocation request, and to request the allocated vehicle to receive a pickup at the identified boarding position. It is done. For example, the dispatch management unit 44 requests the driver to take a ride via the driver terminal 34 of the driver who drives the assigned vehicle.

  In addition, the dispatch management unit 44 predicts a waiting time until the assigned vehicle arrives at the boarding position when requesting a ride, and if the predicted waiting time is included in a predetermined range, The present invention is configured to request a request for taking off the vehicle via a predetermined confirmation for the user if the expected waiting time is not included in the predetermined range, while requesting the vehicle to take off without the confirmation of. The predetermined confirmation for the user is performed, for example, via a screen displayed on the user terminal 32. The predetermined confirmation can also be referred to as confirmation of whether or not the vehicle can be requested to receive the vehicle.

  As described above, the dispatch management server 10 according to the present embodiment predicts the waiting time corresponding to the vehicle allocated to the received dispatch request, and when the predicted waiting time is not included in the predetermined range, Since the vehicle is requested to start the vehicle through the predetermined confirmation, the request of the vehicle for the vehicle requiring the waiting time not included in the predetermined range is prevented from being made without the user confirmation. As a result, it is suppressed that the waiting time until the allocated vehicle arrives becomes longer than the user's assumption.

  In the present embodiment, the predetermined range may be set by applying various rules. For example, when receiving the allocation request, the allocation request management unit 42 can set the range of the waiting time based on the identified boarding position, and can present the user to the set range of the waiting time. In this case, the predetermined range may be configured to be based on the set range of waiting time. For example, the predetermined range is set as a range equal to or less than the maximum value (longest wait time) in the range of the waiting time (or equal to or less than the maximum value × 0.9 or the like). In this case, the dispatch management unit 44 If the waiting time is equal to or less than the maximum value in the waiting time range presented to the user when receiving the vehicle allocation request, a request for a pickup vehicle is made without user confirmation, while the predicted waiting time exceeds the maximum value In that case, you will be asked to get a ride via user confirmation. While this configuration makes it possible to present the user with the range of waiting time when receiving the allocation request, a request for a ride-off vehicle for a vehicle requiring waiting time not included in the range of the waiting time presented to the user is To prevent it from being performed without user confirmation.

  Further, the predetermined range in the present embodiment is not limited to the range based on the range of the waiting time presented to the user as described above, for example, the range preset by the user (the waiting time tolerance. Within 15 minutes etc.).

  In the present embodiment, the range of the waiting time presented to the user when receiving the allocation request may be set by applying various rules. For example, the allocation request management unit 42 identifies a predetermined number of vehicles from the plurality of vehicles based on the identified boarding position, and predicts and predicts the waiting time corresponding to each of the identified predetermined number of vehicles. The range of waiting time is configured to be set based on the waiting time corresponding to each of the predetermined number of vehicles. For example, the allocation request management unit 42 identifies a predetermined number of vehicles in the order of close distance to the boarding position, predicts the waiting time corresponding to each of the identified predetermined number of vehicles, and minimizes the predicted waiting time. The range of the waiting time is set based on the value and the maximum value (for example, the range from the minimum value to the maximum value is set as the waiting time range). For example, the current position of each of the plurality of vehicles is acquired from the driver terminal 34 of the driver of each of the plurality of vehicles, and managed in the storage 15 or the like. Such a configuration makes it possible to set the range of the waiting time based on the predicted value of the waiting time corresponding to each of the predetermined number of vehicles.

  Further, when setting the range of the waiting time presented to the user, the width (length) of the waiting time range may be limited. That is, the allocation request management unit 42 can be configured to set the range of the waiting time so as to be within the predetermined width (for example, 10 minutes) or less. For example, based on the minimum value and the maximum value within the range of a predetermined width from the minimum value, among the waiting times corresponding to each of the predicted predetermined number of vehicles, the allocation request management unit 42 (that is, It is configured to set the range of waiting time excluding the value outside the range of the predetermined width from the minimum value. Such a configuration suppresses that the width of the latency range becomes excessively large (as a result, the presented latency range is not useful for the user).

  In the present embodiment, the cancellation of the allocation request by the user may be on standby before the vehicle is allocated for the allocation request. That is, the dispatch management unit 44 waits for the first time after receiving the dispatch request, and allocates the vehicle to the received dispatch request when the dispatch request is not canceled by the user within the first time. It can be configured. Such a configuration prevents the cancellation of the allocation request after the allocation of the vehicle for the allocation request (and the subsequent request for the departure).

  In addition, the dispatch management unit 44 waits for the second time when the predicted waiting time is not included in the predetermined range, and allocates the vehicle to the received dispatch request again (re-assigns the vehicle). Can be configured. In this case, it is also possible to limit the number of reassignment of such vehicles. Such an arrangement facilitates the assignment of vehicles whose expected waiting time falls within a predetermined range.

  In the present embodiment, allocation of vehicles can be performed by applying various rules. For example, the dispatch management unit 44 specifies a vehicle to be assigned to the received dispatch request from among the plurality of vehicles based on the identified boarding position and the current position of each of the plurality of vehicles (for example, boarding) Assign the closest vehicle from the location).

  In addition, the allocation management unit 44 may be configured to enable predetermined communication between the user and the driver of the allocated vehicle, in response to a request for a ride of the allocated vehicle. The predetermined communication includes, for example, text chat. Such an arrangement enables communication between the user and the driver, which in turn facilitates the user to get on the assigned vehicle smoothly.

  In addition, the dispatch management unit 44 can be configured to receive from the driver of the vehicle that has requested to take off the vehicle a report that it has arrived at the identified boarding position and a report that the user has boarded, in this case When the dispatch management unit 44 receives a report that the user has arrived at the identified boarding position, if the driver does not receive a report that the user has boarded within the third time, the driver is prompted to cancel the pickup. (E.g., display on the driver terminal 34). Such a configuration prevents the driver from excessively waiting for the user to cancel the allocation request without contacting.

  Next, a specific example of the vehicle allocation management server 10 of the present embodiment having such a function will be described. In this specific example, the allocation management server 10 provides a taxi allocation service to the user operating the user terminal 32. In addition, the driver of each of the plurality of vehicles targeted for allocation in the service holds the driver terminal 34.

  FIGS. 3-4 illustrate the information managed in each table that the storage 15 of the server 10 has in this example. FIG. 3 exemplifies information managed in the allocation request information table. The allocation request information table manages information on allocation requests from users, and as shown in the figure, identifies users who have made allocation requests in association with “request IDs” that identify individual allocation requests from users. It manages information such as "user ID", "ride position", "destination", "payment method", "maximum value of waiting time", and "vehicle ID" for identifying an allocated vehicle. Although the maximum value of the waiting time will be described in detail later, it is the maximum value of the waiting time in the range of the waiting time presented to the user when receiving the allocation request.

  FIG. 4 illustrates the information managed in the vehicle information table. The vehicle information table manages information on each of a plurality of vehicles used in a taxi dispatch service, and as shown in the figure, in association with a "vehicle ID" identifying individual vehicles, "vehicle basic information", "vehicle basic information" Manage information such as taxi company information, current position, vehicle allocation status, etc. The vehicle basic information includes an image (photograph or diagram) corresponding to the appearance of the vehicle, a number, and the like. Further, as the allocation state, values corresponding to each state including “rent”, “starting car”, and “empty car” are set.

  FIG. 5 illustrates the top screen 50 of the taxi dispatch service displayed on the user terminal 32. The top screen 50 has a map display area 52 and an information display area 54 located at the lower end of the area 52, as illustrated.

  The map display area 52 displays a map of a predetermined range based on the current position of the user (user terminal 32), and a user object UO corresponding to the user is arranged overlapping the map. In the map display area 52, when there is a vehicle managed by the taxi allocation service (that is, a vehicle managed in the vehicle information table) within the range of the displayed map, the vehicle corresponding to the vehicle An object VO is arranged so as to overlap the map. The display positions of the user object UO and the vehicle object VO change (move) as the user or the vehicle moves.

  The information display area 54 displays an indication ("5 to 8 minutes" in the example of FIG. 5) of the waiting time at the current time (display time of the top screen 50) when the user makes a dispatch request. A button 542 indicating "call" is disposed.

  FIG. 6 is a flow diagram illustrating processing executed by the server 10 in order to set an indication of the waiting time displayed in the information display area 54. First, as illustrated, the server 10 specifies three vehicles in order of proximity from the position of the user (step S100). Specifically, based on the current position of the user transmitted from the user terminal 32 and the current position of the vehicle information table and the allocation condition, the server 10 selects, from among the empty vehicles, in order of proximity from the user position. Identify 3 vehicles.

  Next, the server 10 calculates an estimated value of waiting time corresponding to each of the three identified vehicles (step S110). Specifically, the server 10 calculates a predicted value of the waiting time (traveling required time) until each vehicle arrives at the position of the user based on the position of the user and the position of each vehicle. The calculation of the prediction value of the waiting time can be performed by applying various logic / algorithm, and can be performed using, for example, a machine-learned learned model.

  Then, the server 10 sets the range of the waiting time based on the calculated predicted value of the waiting time corresponding to each vehicle (step S120). Specifically, the range from the minimum value to the maximum value of the estimated values of the waiting time corresponding to each of the three vehicles is set as the range of the waiting time. Also, in this example, the range of the waiting time is set such that the width is 10 minutes or less. For example, when the predicted values of the waiting time corresponding to each of the three vehicles are 3 minutes, 8 minutes, and 15 minutes, the range from the minimum value to the maximum value is "3 to 15 minutes", and the width is Since it becomes 10 minutes or more (12 minutes), the predicted value "15 minutes" is excluded, and "3 to 8 minutes" is set as the waiting time range. That is, in this example, the range from the minimum value of the predicted values of the waiting time to the maximum value of the predicted values within 10 minutes from the minimum value is set as the waiting time range.

  Returning to FIG. 5, when the button 542 of the top screen 50 is selected by the user, the input of information necessary for a dispatch request is started, and first, the boarding position specification screen 60 illustrated in FIG. Ru. The boarding position specification screen 60 has a map display area 62 and an information display area 64 located at the lower end of the area 62, as illustrated.

  The map display area 62 displays a map in the same manner as the map display area 52 of the top screen 50. In addition, in the map display area 62, a boarding position designation object PO1 displayed as "get on from here" is arranged. The boarding position designation object PO1 is initially disposed at the position of the user object UO, and its position is changed by the drag operation on the touch panel of the user terminal 32 by the user. The user can set a desired boarding position by changing the position of the boarding position designation object PO1.

  The information display area 64 displays an address corresponding to the position of the boarding position specification object PO1. Further, in the information display area 64, a button 642 displayed as "determine the boarding position" is arranged.

  When the button 642 is selected by the user, a vehicle allocation request screen 70 illustrated in FIG. 8 is displayed on the user terminal 32. The allocation request screen 70 has a map display area 72 and an information display area 74 located at the lower end of the area, as illustrated.

  The map display area 72 displays a map in the same manner as the map display area 62 of the boarding position specification screen 60. The information display area 74 displays an indication ("7 to 12 minutes" in the example of FIG. 8) of the waiting time at the current time (at the display time of the dispatch request screen 70) when the user makes a dispatch request. Further, in the information display area 74, a first button 742 for setting a user's destination (the alighting position), a second button 744 for setting a payment method, and a "request" is displayed. Three buttons 746 are arranged.

  The standard of the waiting time displayed by the information display area 74 is the same as the standard of the waiting time displayed in the information display area 54 of the top screen 50 described above, by executing each process in the flow chart illustrated in FIG. It is set. Specifically, server 10 identifies three vehicles in order of proximity from the boarding position designated via boarding position designation screen 60 (step S100), and waits for each of the three identified vehicles. The predicted value of is calculated (step S110), and the range of the waiting time is set based on the calculated predicted value of the waiting time corresponding to each vehicle (step S120). Here, the standard of the waiting time (the range of waiting time) displayed in the information display area 74 of the dispatch request screen 70 is set at the time of displaying the screen 70, and each vehicle starts from the timing when the top screen 50 is displayed. The value of the indication of the waiting time in the dispatch request screen 70 may change from the value of the indication of the waiting time in the top screen 50, because

  When the first button 742 of the information display area 74 is selected by the user, a screen for setting a destination is displayed, and the user can set the destination via the screen. The user can omit the setting of the destination.

  When the second button 744 is selected by the user, a screen for selecting a payment method is displayed, and the user can set the payment method via the screen. In this example, the payment method is either in-vehicle payment or Internet payment, and in-vehicle payment is set in the initial state.

  The third button 746 is a button for the user to make a dispatch request. When the third button 746 is selected by the user, a during-delivery screen 80 illustrated in FIG. 9 is displayed. The in-delivery screen 80 has a map display area 82 and an information display area 84 located at the lower end of the area, as illustrated. The map display area 82 displays a map in the same manner as the map display area 72 of the dispatch request screen 70. Further, in the map display area 82, a character string "arranging a taxi" is displayed superimposed on the map.

  The information display area 84 displays an indication ("6 to 10 minutes" in the example of FIG. 9) of the waiting time at the present time (the display time point of the in-vehicle display screen 80). Further, in the information display area 84, a button 842 in which “can be canceled in 5 seconds” is displayed.

  The standard of the waiting time displayed by the information display area 84 is the same as the standard of the waiting time displayed in the information display area 54 of the top screen 50 and the information display area 74 of the dispatch request screen 70, and the flowchart of FIG. It is set by executing each process in. Here, the standard of the waiting time (the range of waiting time) displayed in the information display area 84 of the in-delivery screen 80 is set at the time of displaying the screen 80, and each time from the timing when the dispatch request screen 70 is displayed Since the condition (position and vehicle condition) of the vehicle is changing, the value of the indication of the waiting time on the in-delivery screen 80 may change from the value of the indication of the waiting time on the assignment request screen 70.

  The button 842 is a button for the user to cancel the allocation request. In this example, the cancelable period via the button 842 is limited to 5 seconds, and the text “Can be canceled in another 5 seconds” displayed on the button 842 changes according to the remaining time that can be canceled. Do it (the countdown is displayed). The button 842 disappears after 5 seconds which is a cancelable period.

  FIG. 10 is a flowchart illustrating processing executed by the server 10 in accordance with the elapse of a cancelable period of the allocation request. The server 10 first registers the allocation request (step S200). Specifically, the server 10 sets information other than the vehicle ID of the allocation request information table. As the maximum value of the waiting time in the allocation request information table, the maximum value in the indication of the waiting time displayed in the information display area 84 of the in-delivery screen 80 is set.

  Next, the server 10 specifies a vehicle to be allocated for the allocation request (step S205). Specifically, based on the boarding position designated via boarding position designation screen 60 and the current position of the vehicle information table and the allocation state, server 10 is closest to the boarding position among the vehicles in the empty state. Identify the vehicle.

  Next, the server 10 calculates a predicted value of waiting time until the identified vehicle arrives at the boarding position (step S210). The latency estimates can be calculated by applying various logic / algorithms, as described above, and can be calculated using, for example, a machine-learned learned model.

  Then, if the calculated predicted value of the waiting time is equal to or less than the above-described maximum value of the waiting time (NO in step S220), the vehicle request for the vehicle is assigned (step S260). On the other hand, in the case where the calculated predicted value of the waiting time is larger than the maximum value of the waiting time (YES in step S220) and the allocation of the vehicle is the first time (NO in step S230), 3 seconds waited Above (step S240), the process returns to the identification of the vehicle to be allocated (step S200) (the vehicle is reassigned). After 3 seconds, the status (position and vehicle status) of each vehicle changes, so the vehicle allocated in step S205 and / or the predicted waiting time value calculated in step S210 may also change. . Then, when the predicted value of the calculated waiting time becomes equal to or less than the maximum value of the waiting time range due to the first reassignment of the vehicle (NO in step S220), for the allocated vehicle. A request for a get-off is made (step S260).

  On the other hand, even if the first reassignment of the vehicle is performed, if the calculated predicted value of the waiting time remains larger than the maximum value of the waiting time, the process returns to specifying the vehicle to be assigned again (step S200). Even if the second reassignment is performed, if the calculated predicted value of the waiting time remains larger than the maximum value of the waiting time (YES in step S220 and S230) (Step S250). The confirmation of the availability of the request for departure is performed via the dispatching screen 80.

  FIG. 11 exemplifies the in-vehicle display screen 80 at the time of confirming with the user whether or not the request for a request for departure is made. As shown in the figure, in the information display area 84, the character string “The waiting time will be about 13 minutes, but is it OK to continue the arrangement?” A first button 844 displayed and “Yes” is displayed, and a second button 846 displayed “No”. The user refers to the estimated value of the waiting time displayed in the information display area 84, selects the first button 844 to continue the taxi arrangement, and does not continue the taxi arrangement. 2 button 846 is selected. When the second button 846 is selected by the user, the allocation request is cancelled. On the other hand, when the first button 844 is selected by the user, the server 10 requests the vehicle that has been assigned to take a ride (step S260 in the flow chart of FIG. 10). Thus, in this example, when waiting time exceeding the maximum value of waiting time presented to the user is predicted, the waiting time until the dispatched vehicle arrives since the vehicle is requested to receive the vehicle via user confirmation. Is prevented from becoming longer than the user's assumption.

  FIG. 12 exemplifies the get-off request confirmation screen 100 displayed on the driver terminal 34 of the driver of the vehicle that has received the request for the get-off. As shown in the figure, on the incoming request confirmation screen 100, a first button 102 displayed as "OK" and a second button 104 displayed as "Cancel" are vertically arranged. The first button 102 is configured as an object of a large size (approximately 4 times the length in the vertical direction) as compared to the second button 104, and as a result, the selection operation by the driver is easy. The driver selects the first button 102 when accepting a request for a ride, and selects the second button 104 when not accepting (rejecting) a request for a ride. It should be noted that even when a request for a get-off is received (for example, when displaying the get-up request confirmation screen 100), a notification (voice guidance or ringing tone, etc.) may be made by voice at the driver terminal 34. good.

  In addition, when the 1st button 102 is not selected within 10 seconds after the display, the 2nd button 104 is automatically selected (that is, it rejects the request for a get-off) after the display. It is done. At the lower end of the first button 102, a circular object 1021 for counting down and displaying the 10 seconds is disposed. Thus, instead of selecting the second button 104, the driver can reject the request for a get-off by leaving it for 10 seconds. When the driver rejects the request for a pickup, the server 10 starts specifying the vehicle to be allocated again (step S205 in FIG. 10).

  When the first button 102 of the incoming request request confirmation screen 100 is selected by the driver, the allocation of the vehicle for the allocation request is determined, and the server 10 sets the corresponding vehicle ID in the allocation request information table and The vehicle allocation state in the vehicle information table is changed to "starting", and information on the vehicle is transmitted to the user terminal 32 of the corresponding user. FIG. 13 exemplifies a wait for waiting vehicle display screen 90 displayed on the user terminal 32 in response to the determination of the assignment of the vehicle (the acceptance of the request for the request for a ride by the driver). As shown in the figure, the waiting for departure screen 90 has a map display area 92 and an information display area 94 located at the lower end of the area. The map display area 92 displays a map in the same manner as the map display area 82 of the in-vehicle display screen 80.

  The information display area 94 is an estimated value of the waiting time until the vehicle arrives (in the example of FIG. 13, the character string “I will arrive in about 11 minutes”), an image of the assigned vehicle (photograph or And other information on the vehicle (eg, taxi company name, vehicle number, etc.). Further, in the information display area 94, a first button 942 displayed as "destination setting" and a second button 944 displayed as "message" are arranged. The estimated value of the waiting time displayed in the information display area 94 is updated at a predetermined frequency (for example, every 10 seconds).

  The first button 942 is a button for the user to set / change the destination. The second button 944 is a button for chatting with the driver of the assigned vehicle. In response to the selection of the second button 944, a chat screen is displayed. Thus, in this example, text chat between the user and the driver becomes possible in response to the determination of the assignment of the vehicle (the acceptance of the request for the get-off by the driver).

  FIG. 14 exemplifies the mid-ride screen 110 displayed on the driver terminal 34 in response to the determination of the allocation of the vehicle (the acceptance of the request for the taxi from the driver). As shown in the figure, the in-ride screen 110 has a map display area 112, a first button 114 displayed as "arrival", and a second button 116 displayed as "message".

  The map display area 112 displays a map including the range from the driver's vehicle to the boarding position. Further, in the map display area 112, a driver vehicle object DO corresponding to the driver's vehicle and a boarding position object PO2 corresponding to the boarding position are arranged on the map in an overlapping manner. In the map display area 112, the scale of the map (the range of the displayed map) changes as the vehicle approaches the boarding position. In the upper right corner of the map display area 112, a navigation start button 1122 displayed as "navi" is disposed. When the button 1122 is selected by the driver, a general navigation function whose destination is the riding position is started. Note that the address corresponding to the riding position may be displayed as a character string on the getting-in-progress screen 110.

  The first button 114 is a button for the driver to report arrival at the riding position. The second button 116 is a button for chatting with the user. In response to the selection of the second button 116, a chat screen is displayed. In addition, the fixed message selected from a plurality of fixed messages such as "I'll be delayed for about 5 minutes", "I'll be delayed for about 10 minutes", "I'll be delayed due to road congestion" etc. May be configured to be able to transmit.

  When the first button 114 is selected by the driver, an arrival report screen 120 illustrated in FIG. 15 is displayed. The arrival report screen 120 may be displayed automatically (without selection of the first button 114) when the position of the driver's vehicle falls within a predetermined range from the riding position.

  On the arrival report screen 120, as shown in the figure, a first button 122 displayed as "arrival place arrival" and a second button 124 displayed as "cancel" are vertically arranged. The first button 122 is configured as an object of a large size as compared to the second button 124. When the first button 122 is selected by the driver, the arrival at the start point (riding position) is reported to the server 10. In response to the report of arrival at the boarding position, the server 10 transmits a predetermined message to the user terminal 32. The user can know the arrival of the vehicle via the predetermined message. In addition, the driver can also perform communication necessary for the user to get in after getting to the riding position through the text chat described above.

  FIG. 16 illustrates the boarding report screen 130 displayed on the driver terminal 34 in response to the selection of the first button 122. On the boarding report screen 130, as shown in the figure, a first button 132 displayed as "boarding completed" and a second button 134 displayed as "canceled" are vertically arranged. The first button 132 is configured as an object of a large size as compared to the second button 134. When the first button 132 is selected by the driver, the user's boarding is reported to the server 10. When the report is received, the server 10 changes the vehicle allocation state in the vehicle information table of the corresponding vehicle to "rent".

  FIG. 17 exemplifies a cancel signal display screen 140 displayed on the driver terminal 34 when the boarding of the user is not reported even after 10 minutes after the report of the arrival to the start point. As shown in the drawing, the first button 142 displayed as "canceled departure" and the second button 144 displayed as "maintained" are arranged in the vertical direction on the departure cancellation screen 140. The first button 142 is configured as an object of a large size as compared to the second button 144. When the first button 142 is selected by the driver, cancellation of the get-off is reported to the server 10. When the report is received, the server 10 changes the vehicle allocation state in the vehicle information table of the corresponding vehicle to "empty". Also, a predetermined message is sent to the user in response to the cancellation of the pickup.

  The dispatch management server 10 according to the present embodiment described above predicts the waiting time corresponding to the vehicle allocated to the received dispatching request, and the predicted waiting time is in a predetermined range (for example, the waiting time presented to the user) If the request is not included in the maximum value of), the request for the vehicle to take a waiting time not included in the predetermined range is requested without the user confirmation because the vehicle is requested to take the vehicle through the predetermined confirmation for the user. Prevent it from being done. As a result, it is suppressed that the waiting time until the allocated vehicle arrives becomes longer than the user's assumption.

  In the embodiment described above, the allocation management unit 44 of the allocation management server 10 is configured to manage allocation of a vehicle, but in another embodiment of the present invention, one of the functions of the allocation management unit 44 The unit (for example, the function of managing the position and the state of the vehicle, etc.) may be performed by, for example, a taxi center dispatch center. In this case, the vehicle allocation management server 10 is configured to make a request for allocation of a vehicle or start of a vehicle via the vehicle allocation center.

  The processes and procedures described herein may be implemented by software, hardware, or any combination thereof other than those explicitly described. For example, the processes and procedures described herein may be implemented by implementing logic corresponding to the processes and procedures on a medium such as an integrated circuit, volatile memory, non-volatile memory, or magnetic disk. In addition, the processes and procedures described in the present specification can be implemented as computer programs corresponding to the processes and procedures, and can be executed by various computers.

  Even though it is described that the processes and procedures described herein are performed by a single device, software, component, module, such processes or procedures may be performed on multiple devices, multiple software, multiple , And / or modules. Also, the software and hardware elements described herein may be implemented by integrating them into fewer components or breaking them down into more components.

  In the present specification, when a component of the invention is described as one or more or one or more without limitation, it is necessary to be understood in context. Except for the above, the component may be either singular or plural.

10 Vehicle Allocation Management Server 20 Network 32 User Terminals 34 Driver Terminal 40 Information Storage Management Unit 42 Vehicle Allocation Request Management Unit 44 Vehicle Allocation Management Unit 50 Top Screen 60 Ride Position Specification Screen 70 Vehicle Allocation Request Screen 80 Vehicle Distribution Screen 90 Waiting Car Waiting Screen 100 Screen 110 Away Screen 120 Arrival Report Screen 130 Ride Report Screen 140 Away Cancel Screen

Claims (10)

A system for managing vehicle allocation comprising one or more computer processors, the system comprising:
The one or more computer processors are responsive to execution of the readable instructions.
A process of receiving from the user a dispatch request involving specification of a riding position;
Execute a process of allocating a vehicle from among a plurality of vehicles to the received allocation request, and requesting the allocated vehicle to take a ride to the identified boarding position;
The process of receiving the allocation request includes setting a range of waiting time estimated based on the identified boarding position, and presenting the set range of waiting time to the user.
The process of requesting the get-back estimates a waiting time until the assigned vehicle arrives at the specified boarding position, and the predicted waiting time is included in a predetermined range based on the set waiting time range. In this case, the requested vehicle is requested to take a ride without the predetermined confirmation from the user, while the predetermined period for the user is not received if the predicted waiting time is not included in the predetermined range. look including to ask the geisha to the assigned vehicle through the confirmation,
The predetermined range is a range equal to or less than a value based on the maximum value of the set waiting time range.
system. The process of receiving the allocation request identifies a predetermined number of vehicles from the plurality of vehicles based on the identified boarding position, and predicts a waiting time corresponding to each of the identified predetermined number of vehicles. Setting the range of the waiting time based on the waiting time corresponding to each of the predetermined number of vehicles predicted;
The system of claim 1. The process of receiving the allocation request includes setting the range of the waiting time to be within the range of a predetermined width or less.
The system of claim 1 or 2. In the process of requesting the get-off vehicle, the process waits for a first time after receiving the allocation request, and allocates a vehicle to the received allocation request when the allocation request is not canceled by the user within the first time. Including
A system according to any one of claims 1 to 3. The process of requesting the vehicle includes waiting for a second time when the predicted waiting time is not included in the predetermined range, and allocating a vehicle to the received allocation request again.
The system according to any one of claims 1 to 4. The process of requesting the get-off specifies a vehicle to be assigned to the received allocation request from among the plurality of vehicles based on the identified boarding position and the current position of each of the plurality of vehicles. Including
The system according to any one of claims 1 to 5. The one or more computer processors further execute processing that enables predetermined communication between the user and a driver of the assigned vehicle, in response to a request for a get-off for the assigned vehicle.
The system according to any one of claims 1 to 6. The one or more computer processors further receive a report from the driver of the vehicle that has requested to take up the vehicle, that the user has arrived at the identified boarding position, and a report that the user has boarded, and the identification Displaying a screen prompting the driver to cancel the departure when the report on arrival by the user within the third time period is not received after receiving the report on arrival at the taken position, and Run,
The system according to any one of claims 1 to 7. A method executed by one or more computers for managing the allocation of a vehicle, comprising:
Receiving from the user a dispatch request accompanied by the specification of the riding position;
Assigning a vehicle from among a plurality of vehicles to the received allocation request, and requesting the allocated vehicle to take a ride to the identified boarding position;
The step of receiving the allocation request includes setting a predicted waiting time range based on the identified boarding position, and presenting the set waiting time range to the user.
The step of requesting the takeoff predicts a waiting time until the assigned vehicle arrives at the specified boarding position, and the predicted waiting time is included in a predetermined range based on the set waiting time range. In this case, the requested vehicle is requested to take a ride without the predetermined confirmation from the user, while the predetermined period for the user is not received if the predicted waiting time is not included in the predetermined range. look including to ask the geisha to the assigned vehicle through the confirmation,
The predetermined range is a range equal to or less than a value based on the maximum value of the set waiting time range.
Method. A program for managing the allocation of vehicles,
Said one or more computers depending on their execution on one or more computers,
A process of receiving from the user a dispatch request involving specification of a riding position;
Assign a vehicle from among a plurality of vehicles to the received allocation request, and execute a process of requesting the allocated vehicle to get in to the identified boarding position;
The process of receiving the allocation request includes setting a range of waiting time estimated based on the identified boarding position, and presenting the set range of waiting time to the user.
The process of requesting the get-back estimates a waiting time until the assigned vehicle arrives at the specified boarding position, and the predicted waiting time is included in a predetermined range based on the set waiting time range. In this case, the requested vehicle is requested to take a ride without the predetermined confirmation from the user, while the predetermined period for the user is not received if the predicted waiting time is not included in the predetermined range. look including to ask the geisha to the assigned vehicle through the confirmation,
The predetermined range is a range equal to or less than a value based on the maximum value of the set waiting time range.
program.

Images