JP7165518B2 - Systems, methods, and programs for managing vehicle dispatch - Google Patents

Description

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

Conventionally, a system for managing dispatch of vehicles such as taxis has been proposed (see, for example, Patent Literature 1 below). In such a system, when a user makes a dispatch request along with specifying a boarding position (pickup position), an empty vehicle traveling in an area near the designated boarding position is searched and dispatched.

Japanese Patent Application Laid-Open No. 2018-49408

However, in the conventional system, there may be a case where the user who made the dispatch request cannot easily find the vehicle that has arrived at the boarding position. For example, when the vicinity of a road having lanes in both directions is specified as the boarding position, the user can choose which sidewalk to wait on from sidewalks on both sides of the road (in other words, which direction the vehicle will come from). There were times when it was difficult to decide whether to come. As described above, in the conventional system for managing vehicle allocation, there is room for improvement in terms of user convenience when requesting vehicle allocation.

One object of the embodiments of the present invention is to improve the convenience of the user when requesting a dispatch. Other objects of embodiments of the present invention will become apparent upon review of the specification as a whole.

A system according to one embodiment of the present invention is a system for managing dispatch of vehicles, comprising a storage device for storing at least vehicle information of each of a plurality of vehicles, and one or more computer processors. , the one or more computer processors perform, in response to execution of readable instructions, a process of accepting a dispatch request from a user, a process of setting the boarding position of the user, the set boarding position of the user, a process of selecting a vehicle to be assigned to the user from among the plurality of vehicles based at least on the vehicle information of each of the plurality of vehicles; and a process of requesting pick-up, and the boarding position of the user is presented to the user along with the traveling direction of the vehicle at the boarding position of the user.

A method according to an embodiment of the present invention is a method for managing dispatch of vehicles, executed by one or more computers having access to a storage device storing at least vehicle information for each of a plurality of vehicles, the method comprising: , based on at least a step of receiving a vehicle allocation request from a user, a step of setting a boarding position of the user, the set boarding position of the user, and the vehicle information of each of the plurality of vehicles, selecting a vehicle to be assigned to the user from vehicles; and requesting the selected vehicle to be assigned to the user to pick up the user at the user's boarding position, wherein the user's boarding position is the user's boarding position. It is configured to be presented to the user along with the traveling direction of the vehicle at the user's boarding position.

A program according to one embodiment of the present invention is a program for managing dispatch of vehicles, and is executed on one or more computers that can access a storage device that stores at least vehicle information for each of a plurality of vehicles. According to the execution, the one or more computers receive a request for dispatching a vehicle from a user, set a boarding position of the user, set the boarding position of the user, and each of the plurality of vehicles. a process of selecting a vehicle to be assigned to the user from among the plurality of vehicles based at least on vehicle information; and a process of requesting the selected vehicle to be assigned to the user to pick up the user at the boarding position of the user. , and the user's boarding position is presented to the user along with the traveling direction of the vehicle at the user's boarding position.

Various embodiments of the present invention enhance user convenience when requesting a ride.

1 is a configuration diagram schematically showing the configuration of a network including a vehicle allocation management server 10 according to one embodiment of the present invention; FIG. FIG. 2 is a block diagram schematically showing functions of a dispatch management server 10; FIG. 4 is a diagram exemplifying information managed in a user information table 411; FIG. 4 is a diagram exemplifying information managed in a vehicle information table 412; FIG. FIG. 4 is a diagram exemplifying information managed in a dispatch request information table 413; FIG. FIG. 5 is a view exemplifying a top screen 501; FIG. FIG. 4 is a flowchart illustrating processing executed by the dispatch management server 10; The figure which illustrates the screen 502 during arrangement. FIG. 10 is a view exemplifying a pick-up request confirmation screen 100; FIG. The figure which illustrates the pick-up waiting screen 503. FIG. The figure which illustrates the pick-up screen 110. FIG. The figure which illustrates the arrival report screen 120. FIG. The figure which illustrates the boarding report screen 130. FIG. The figure which illustrates the pick-up waiting screen 503. FIG. FIG. 11 is a diagram for explaining how the orientation of a traveling direction display object 5211 changes according to a change in the position of a boarding position specifying object 521 on the map; The figure which illustrates the pick-up waiting screen 503. FIG. FIG. 5 is a diagram for explaining how a vehicle is assigned to a user with an early waiting start time; FIG. 5 is a view exemplifying a condition specifying screen 504; FIG. FIG. 4 is a flowchart illustrating processing executed by the dispatch management server 10; FIG. 10 is a diagram for explaining how vehicles are preferentially allocated to users who have selected a priority vehicle allocation option;

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

FIG. 1 is a configuration diagram schematically showing the configuration of a network including a vehicle allocation management server 10 according to one embodiment of the present invention. As illustrated, the server 10 is communicably connected to a user terminal 32 and a driver terminal 34 via a communication network 20 such as the Internet. Although only one user terminal 32 and one driver terminal 34 are shown in FIG. 1, the server 10 is communicably connected to a plurality of user terminals 32 and driver terminals 34, respectively. The server 10 provides a dispatch management service for managing dispatch of vehicles such as taxis. The dispatch management server 10 is an example of a device implementing all or part of the system of the present invention.

The dispatch management server 10 is configured as a general computer, and as shown in FIG. /F 14 and a storage (storage device) 15, and these constituent elements are electrically connected via a bus or the like (not shown).

The computer processor 11 loads 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 composed of, for example, a DRAM.

The input/output I/F 13 is various input/output devices for exchanging information with a user or the like. The input/output I/F 13 includes, for example, information input devices such as keyboards and pointing devices (for example, mice, touch panels, etc.), voice input devices such as microphones, and image input devices such as cameras. The input/output I/F 13 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 types of communication software, or a combination thereof, and is configured to enable wired or wireless communication via the communication network 20 or the like.

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

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

The user terminal 32 and the driver terminal 34 have configurations as general computers, and are configured as smart phones, tablet terminals, personal computers, wearable devices, and the like, for example. The user terminal 32 is operated by a user who uses a vehicle such as a taxi. Also, the driver terminal 34 is operated by the driver of the vehicle.

In this embodiment, the dispatch management server 10 can be configured to have functions as a web server and an application server. In this case, a web browser or other application (for example, It executes various processes in response to a request from an application for dispatch management service), and transmits screen data (for example, HTML data) and control data according to the results of the processes. A web page or other screen based on the received data is displayed at the user terminal 32 and the driver terminal 34 .

Next, functions of the dispatch management server 10 of this embodiment will be described. FIG. 2 is a block diagram schematically showing functions of the server 10. As shown in FIG. As illustrated, the server 10 includes an information storage management unit 41 for storing and managing information, a basic function control unit 42 for controlling basic functions of the vehicle allocation management service, and a vehicle allocation request management unit for managing vehicle allocation requests from users. 43 and a pick-up request management unit 44 for managing pick-up requests for vehicles. These functions are realized by the cooperative operation of hardware such as the computer processor 11 and the main memory 12, and various programs and data stored in the storage 15 and the like. It is implemented by the computer processor 11 executing instructions included in the loaded program. Also, some or all of the functions shown in FIG. 2 may be realized through cooperation between the dispatch 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 41 of the server 10 is configured by the storage 15 and the like, and stores and manages various information. For example, as shown in FIG. 2, the information storage management unit 41 includes a user information table 411 that manages information on users of the vehicle allocation management service, and a vehicle information table that manages information on vehicles to be allocated in the vehicle allocation management service. 412 , a vehicle allocation request information table 413 for managing information on vehicle allocation requests from users, and road map data 415 .

The basic function control unit 42 of the server 10 executes various processes related to control of the basic functions of the dispatch management service. For example, the basic function control unit 42 transmits HTML data or control data of various screens related to the basic functions to the user terminal 32 or the driver terminal 34, and the user terminal 32 or the driver terminal 34 displays the screen to the user. Alternatively, it executes various processes in response to operation inputs by the driver, and transmits HTML data or control data according to the results of the processes to the user terminal 32 or the driver terminal 34 . Basic functions controlled by the basic function control unit 42 include, for example, login processing (user authentication), payment processing, user management (for example, updating the user information table 411), and vehicle management (for example, vehicle update of the information table 412, etc.).

The vehicle allocation request management unit 43 of the server 10 executes various processes related to management of vehicle allocation requests from users. In this embodiment, the vehicle allocation request management unit 43 is configured to receive a vehicle allocation request from a user and set the boarding position (pickup position) of the user. For example, the vehicle allocation request management unit 43 is configured to receive a vehicle allocation request made by the user via a screen displayed on the user terminal 32, and uses the position specified by the user via the screen as the boarding position. Alternatively, the boarding position is automatically set based on the user's current position (position information of the user terminal 32, etc.).

Further, the vehicle allocation request management unit 43 selects a vehicle to be allocated to the user from among the plurality of vehicles based on at least the set boarding position and the vehicle information of each of the plurality of vehicles to be allocated. is configured to Vehicle information of each vehicle includes, for example, the current position of the vehicle, and can be managed in the vehicle information table 412 .

The pick-up request management unit 44 of the server 10 executes various processes related to pick-up requests for vehicles. In this embodiment, the pick-up request management unit 44 is configured to request the vehicle selected as the vehicle to be assigned to the user to pick up the user at the boarding position. For example, the pick-up request management unit 44 is configured to transmit information for requesting pick-up to the driver terminal 34 of the driver corresponding to the selected vehicle, and the information includes at least the user's boarding position. . The correspondence between the vehicle and the driver terminal 34 (driver) is managed in the vehicle information table 412, for example.

In this embodiment, the user's boarding position is configured to be presented to the user along with the traveling direction of the vehicle at the boarding position. For example, the dispatch request management unit 43 is configured to present the user's boarding position and the traveling direction of the vehicle at the boarding position to the user via a screen displayed on the user terminal 32 .

As described above, the vehicle allocation management server 10 in this embodiment sets the boarding position of the user and presents the set boarding position to the user along with the traveling direction of the vehicle at the boarding position. Even if a boarding position is set near a road with lanes in both directions, which sidewalk on both sides of the road should one wait on (in other words, which direction the vehicle is coming from? ) can be determined accurately. In other words, the vehicle allocation management server 10 in this embodiment improves the user's convenience when making a vehicle allocation request.

In this embodiment, when setting the boarding position via a screen for setting the user's boarding position, the traveling direction of the vehicle may be displayed on the screen. For example, the dispatch request management unit 43 can be configured to set a position on a map designated by the user through a predetermined screen as the boarding position of the user. It may be configured to display the direction of travel of the vehicle corresponding to the location on the map specified by the user. For example, the dispatch request management unit 43 is configured to identify the lane closest to the position on the map specified by the user, and display the traveling direction of the vehicle in the identified lane. Information about such lanes (including the traveling direction of the vehicle) can be managed in road map data 415 . Such a configuration assists the user in understanding the traveling direction of the vehicle at the boarding position when setting the boarding position.

In this embodiment, the vehicle allocation request management unit 43 can be configured to set the user's exit position in addition to the user's boarding position. The drop-off position is specified by the user via a screen displayed on the user terminal 32, for example. For example, the user's drop-off position can be configured to be presented to the user along with the traveling direction of the vehicle at the drop-off position, similar to the boarding position. For example, the vehicle allocation request management unit 43 is configured to present the user's drop-off position and the traveling direction of the vehicle at the drop-off position to the user via a screen displayed on the user terminal 32 . Such a configuration assists the user in understanding the traveling direction of the vehicle at the drop-off position.

In addition, the dispatch request management unit 43 determines whether an allocatable vehicle that can be allocated to the user (for example, an empty vehicle whose expected waiting time until arrival at the user's boarding position (or the distance to the boarding position) is within a predetermined range. , etc.), wait for the occurrence of an allocatable vehicle (either automatically or via confirmation by the user). For example, when there is no allocatable vehicle, the vehicle allocation request management unit 43 waits for an allocatable vehicle for a predetermined period of time, and when an allocatable vehicle is generated, selects the vehicle as a vehicle to be allocated to the user. , when the predetermined time elapses without any allocatable vehicle being generated, the vehicle allocation request from the user is cancelled. With such a configuration, even if there is no allocatable vehicle, it is possible to wait for an allocatable vehicle to be generated before canceling the dispatch request, thereby improving the user's convenience.

In the present embodiment, the waiting order of waiting users waiting for an allocatable vehicle is managed, and when a specific allocatable vehicle that can be allocated to a plurality of waiting users occurs, the specific allocatable vehicle A vehicle may be assigned to the user whose waiting order is the most advanced (earliest) among the plurality of waiting users. In other words, when a specific allocatable vehicle that can be allocated to a specific standby user is generated, the vehicle allocation request management unit 43 determines whether the specific allocatable vehicle is available to other standby users who can be allocated to the specific standby user. It may be configured to select the specific allocatable vehicle as a vehicle to be assigned to the specific waiting user when there is no other waiting user whose waiting order precedes the user. Information that can specify the waiting order of waiting users (for example, the time at which they started waiting) is managed in, for example, the dispatch request information table 413 . Such a configuration prevents the user's waiting time from becoming excessively long.

Next, a specific example of the dispatch management server 10 of this embodiment having such functions will be described. In this specific example, the dispatch management server 10 provides a dispatch management service for taxis of a plurality of taxi companies. In the present embodiment, vehicles subject to dispatch management are not limited to taxis of taxi companies, and may include private cars of ordinary people.

FIG. 3 illustrates information managed in the user information table 411 in this example. The user information table 411 manages information related to users of the vehicle allocation management service, and as shown in the figure, stores information such as "basic user information" and "wheelchair use flag" in association with "user accounts" that identify individual users. Manage information. User basic information includes, for example, name, contact information, payment information (credit card information, etc.), and the like. Further, the wheelchair use flag indicates whether or not the wheelchair is used.

FIG. 4 illustrates information managed in the vehicle information table 412 in this example. The vehicle information table 412 manages information about each of a plurality of vehicles that are targets of the vehicle allocation management service. It manages information such as "taxi company information", "UD taxi flag", "facility X entrance permission flag", "current position", "dispatch status", and "driver account" for identifying the corresponding driver. The vehicle basic information includes the type of vehicle, the number of people that can ride in the vehicle, an image (photograph or drawing) corresponding to the appearance of the vehicle, the number, and the like. The UD taxi flag indicates whether or not the taxi is a UD (universal design) taxi designed for use by wheelchair users and elderly people. The facility X entry permission flag indicates whether or not admission to a specific facility X is permitted. Facilities X include, for example, various factories and military facilities. For the current position, position information transmitted from an information terminal or driver terminal 34 mounted on the vehicle is set. A value corresponding to each state including "rental", "pickup", and "empty" is set for the dispatch state.

FIG. 5 illustrates information managed in the dispatch request information table 413 in this example. The vehicle allocation request information table 413 manages information related to vehicle allocation requests from users. "User account", "Boarding position", "Getting off position", "Payment method", "Vehicle ID" that identifies the allocated vehicle, Start waiting when there is no vehicle that can be allocated to the user who made the dispatch request It manages information such as "standby start time" that indicates the time when the

FIG. 6 exemplifies a top screen 501 displayed on the user terminal 32 of the user who uses the dispatch management service of this example. The top screen 501 has a map display area 52 and an information display area 54 positioned below the area 52 as shown.

In the initial state, the map display area 52 displays a map of a predetermined range centered on the current position of the user (user terminal 32) at a predetermined scale, and a user object UO corresponding to the user is arranged on the map. there is In addition, if a vehicle subject to the dispatch management service (that is, a vehicle managed in the vehicle information table 412) exists within the range of the displayed map, the map display area 52 displays the vehicle corresponding to the vehicle. An object VO is placed on the map. The display positions of the user object UO and vehicle object VO change (move) as the user or the vehicle moves.

The map display area 52 is configured such that the range of the displayed map can be slid by a user's slide operation or the like. The display positions of the user object UO and the vehicle object VO also change as the range of the displayed map slides.

The information display area 54 displays an indication of the current waiting time ("5 to 8 minutes" in the example of FIG. 6) when the user makes a dispatch request, and also displays "call a taxi with one tap". and a second button 62 displaying "specify conditions and call a taxi". The estimated waiting time is calculated, for example, based on the distance between the user and each of a predetermined number (eg, three) of unoccupied vehicles in order from the user's current position.

The first button 61 is a button for making a dispatch request without specifying conditions (with one tap), and the second button 62 is a button for making a dispatch request with specified conditions. First, the case of making a dispatch request without specifying conditions will be described.

FIG. 7 is a flowchart illustrating processing executed by the dispatch management server 10 in response to selection of the first button 61 by the user. First, as illustrated, the server 10 automatically sets the user's boarding position (pick-up position) based on the user's current position (step S100). The set boarding position is registered in the dispatch request table 413 .

The setting of the boarding position based on the user's current position can be realized by applying various rules. In this example, if there is a recommended boarding area where the vehicle can stop and is recommended as a boarding position within a predetermined distance from the user's current position, a position within the recommended boarding area (for example, , the position closest to the user's current position within the area) is set as the user's boarding position. Such a recommended boarding area is set in advance by, for example, an operator of the dispatch management service and registered in the road map data 415 . For example, in the dispatch management service, the operator can set, as the recommended boarding area, an area that includes positions that have been individually designated as boarding positions by many users in the past. Such a recommended boarding area can also be said to be a virtual taxi stand provided in the dispatch management service of this example.

Further, in this example, if the recommended boarding area does not exist within a predetermined distance from the user's current position, the nearest stop position from the user's current position is determined as a stop position where the vehicle can stop. , is set as the user's boarding position. At this time, the boarding position is set so as to avoid non-recommended boarding areas that are not suitable as boarding positions.

Here, the non-recommended boarding area in this example includes the non-recommended boarding area common to a plurality of vehicles set by the operator of the dispatch management service, and the non-recommended boarding area for each taxi company individually set by each taxi company. and a boarding area. When setting the user's boarding position in step S100, among these non-recommended boarding areas, the non-recommended boarding areas common to a plurality of vehicles are avoided, and the non-recommended boarding areas for each taxi company are not considered (avoided). not).

These non-recommended boarding areas are registered in the road map data 415 . For example, roads with guardrails and taxi stands are set as non-recommended boarding areas. Also, in another example of the present embodiment, for example, the non-recommended boarding area common to a plurality of vehicles is automatically set based on information obtained from an external system or the like. For example, the non-recommended boarding area can be automatically set based on road construction schedules and traffic regulation information acquired from an external system or the like.

After setting the user's boarding position, the server 10 next selects a vehicle to be assigned to the user based on the user's boarding position, the wheelchair use flag, and the vehicle information of each vehicle (step S110).

In this example, basically, an unoccupied vehicle with an estimated waiting time to arrive at the user's boarding position within a predetermined range (for example, within 15 minutes) is an allocatable vehicle that can be allocated to the user, If there are multiple allocatable vehicles, the vehicle with the shortest expected waiting time (for example, closest to the user's boarding position) is allocated to the user. In addition, allocable vehicles are further restricted in the following cases. First, if the user is a wheelchair user (identified by referring to the wheelchair use flag of the user information table 411), the allocatable vehicle is a UD taxi vehicle (referring to the UD taxi flag of the vehicle information table 412). (specified by Also, if the user's boarding position is within the premises of facility X, the allocatable vehicle is a vehicle that is permitted to enter the facility X (specified by referring to the facility X entrance permission flag in the vehicle information table 412). is limited to Furthermore, when the user's boarding position is included in the non-recommended boarding area of a specific taxi company, the allocatable vehicle is a vehicle other than the vehicle of the specific taxi company (by referring to the taxi company information in the vehicle information table 412). specified).

Here, if there is no allocatable vehicle that has permission to enter facility X, the user's boarding position is changed outside facility X (automatically or through user confirmation), and Other vehicles that do not have entry permits may be assigned. It should be noted that the suggestion to change the user's boarding position may be made only when there is another allocatable vehicle. The post-change boarding position is preset for the facility X. For example, a specific entrance/exit of the facility X is preset as the post-change boarding position on the outside. In this case, for example, the reason why the user's boarding position cannot be set within the premises of the facility X (reason for refusal to dispatch a vehicle, for example, "We cannot arrange a vehicle that can handle this area") is displayed in the map display area 52. It is preferable to visually display the area (specifically, the premises of the facility X) where the position cannot be set (for example, as a translucent specific color (eg, red) area).

Then, if there is an allocatable vehicle (YES in step S115), then server 10 requests the selected vehicle to pick up the vehicle (step S120). FIG. 8 exemplifies a waiting screen 502 displayed on the user terminal 32 in response to a pick-up request for the selected vehicle. The on-handling screen 502 has a map display area 52 and an information display area 54 in the same manner as the top screen 501 . As shown in the figure, in the map display area 52 of the dispatching screen 502, a character string "I am arranging a taxi" is displayed superimposed on the map, and a pin-shaped display "Take here" is displayed. A boarding position specifying object 521 is arranged on the map. The boarding position designation object 521 is arranged at a position on the map corresponding to the set boarding position, and an arrow-shaped traveling direction display object indicating the traveling direction of the vehicle at the set boarding position is placed at the lower end thereof. 5211. The traveling direction display object 5211 is arranged so as to face the traveling direction of the nearest lane from the position of the boarding position specifying object 521 on the map. The object 5211 allows the user to know the traveling direction of the vehicle at the boarding position.

In addition, the information display area 54 of the arrangement screen 502 displays an estimate of the current waiting time and has a cancel button 63 for canceling the pick-up request. The user selects the cancel button 63 when, for example, the selection operation for the first button 61 on the top screen 501 is mistakenly performed. In response to the selection of the button 63, the server 10 performs predetermined cancellation processing for canceling the pick-up request.

FIG. 9 illustrates a pick-up request confirmation screen 100 displayed on the driver terminal 34 of the driver corresponding to the vehicle that has received the pick-up request. The driver corresponding to the vehicle is identified by the driver account in vehicle information table 412 . On the pick-up request confirmation screen 100, as shown, a first button 102 displaying "OK" and a second button 104 displaying "Cancel" are arranged vertically. The driver selects the first button 102 when accepting the request for picking up the vehicle, and selects the second button 104 when not accepting (rejecting) the request for picking up the vehicle.

The pick-up request confirmation screen 100 is configured such that if the first button 102 is not selected within 10 seconds after its display, the second button 104 is automatically selected (that is, the pick-up request is rejected). It is A circular object 1021 that counts down the 10 seconds is arranged at the lower end of the first button 102 . Thus, instead of selecting the second button 104, the driver can refuse the request to pick up the vehicle by leaving it for 10 seconds.

When the driver selects the first button 102 of the pick-up request confirmation screen 100 and accepts the pick-up request (YES in step S130), the allocation of the vehicle to the user is confirmed (step S140). Upon confirmation of the vehicle allocation, the server 10 registers the corresponding vehicle ID in the vehicle allocation request information table 413 and changes the vehicle allocation status of the corresponding vehicle in the vehicle information table 412 to "pickup". On the other hand, when the driver selects the second button 104 of the pick-up request confirmation screen 100 and the pick-up request is rejected (NO in step S130), the server 10 selects a vehicle to be allocated again (step S110). In addition, when there are a plurality of allocatable vehicles, it is also possible to make an inquiry (provisional request) for picking up vehicles for these allocatable vehicles. In this case, the allocation of the first accepted vehicle among the plurality of vehicles that have been asked to pick up the vehicle is determined.

FIG. 10 illustrates a pick-up waiting screen 503 displayed on the user terminal 32 in response to confirmation of vehicle allocation (acceptance of pick-up request by the driver). The pick-up waiting screen 503 has a map display area 52 and an information display area 54 in the same way as the top screen 501 and the ordering screen 502 . As shown in the figure, the information display area 54 of the pick-up waiting screen 503 displays an estimate of the waiting time at the present time, as well as information on the assigned vehicle (image of the vehicle (photograph or diagram), and information on the vehicle Other information (for example, taxi company name, vehicle number, etc.) are displayed, and a first button 64 labeled "set destination" and a second button 65 labeled "message" are displayed. have

The first button 64 is a button for the user to set/change the destination (drop-off position). A screen for setting/changing the destination is displayed according to the selection of the first button 64 . The second button 65 is for the user to chat with the assigned vehicle driver. A chat screen is displayed according to the selection of the second button 65 . Thus, in this example, text chat between the user and the driver is possible upon confirmation of the vehicle allocation.

FIG. 11 exemplifies a pick-up screen 110 displayed on the driver terminal 34 in response to confirmation of vehicle allocation. As shown, the pick-up screen 110 has a map display area 112, a first button 114 displaying "arrival", and a second button 116 displaying "message".

The map display area 112 displays a map whose scale is adjusted to include the range from the driver's vehicle to the boarding position. In the map display area 112, a driver vehicle object DO corresponding to the vehicle of the driver and a boarding position object PO corresponding to the boarding position are arranged on the map. In the map display area 112, the scale of the map (range of the map displayed) changes (enlarges) as the vehicle approaches the boarding position. A navigation start button 1122 labeled “navigation” is arranged in the upper right corner of the map display area 112 . When the button 1122 is selected by the driver, a general navigation function with the boarding position as the destination is initiated.

A first button 114 is for the driver to report arrival at the boarding position. A second button 116 is a button for the driver to chat with the user. A chat screen is displayed according to the selection of the second button 116 .

When the first button 114 is selected by the driver, the arrival report screen 120 illustrated in FIG. 12 is displayed on the driver terminal 34 . The arrival report screen 120 may be automatically displayed (without selecting the arrival button 114) when the driver's vehicle position is within a predetermined range from the boarding position.

As shown in the figure, the arrival report screen 120 has a first button 122 labeled "arrive at pick-up point" and a second button 124 labeled "cancel" arranged side by side in the vertical direction. When the first button 122 is selected by the driver, arrival at the pick-up point (boarding position) is reported to the server 10 . The server 10 transmits a predetermined message to the user terminal 32 in response to the report of arrival at the boarding position. The user can know the arrival of the vehicle through the predetermined message. In addition, the driver can communicate with the user through the above-described text chat from the arrival at the boarding position to the boarding of the user.

FIG. 13 exemplifies a boarding report screen 130 displayed on the driver terminal 34 in response to selection of the first button 122 . As shown in the figure, the boarding report screen 130 has a first button 132 displaying "Complete boarding" and a second button 134 displaying "Cancel" arranged side by side in the vertical direction. When the first button 132 is selected by the driver, the user's ride is reported to the server 10 . Upon receiving the report, the server 10 changes the dispatch status of the corresponding vehicle in the vehicle information table 412 to "rental".

Here, in this example, the user can change the set boarding position after selecting the first button 61 on the top screen 501 to make a dispatch request. Specifically, by changing the position of the boarding position specifying object 521 on the map via the map display area 52 of the arranging screen 502 illustrated in FIG. 8 or the pick-up waiting screen 503 illustrated in FIG. You can change the position. For example, a slide operation on the boarding position specifying object 521 changes the position of the object 521 .

FIG. 14 exemplifies the pick-up waiting screen 503 when the position of the boarding position specifying object 521 on the map is changed. As shown in the figure, a confirmation object 56 for confirming whether or not the boarding position needs to be changed is superimposed on the map display area 52 in accordance with the change of the position of the boarding position specifying object 521 on the map. The confirmation object 56 has a first button 561 labeled "Yes" and a second button 562 labeled "No". When the first button 561 is selected, the change of the boarding position is confirmed, the changed boarding position is transmitted to the corresponding driver terminal 34, and the boarding position of the dispatch request information table 413 is updated. Note that if the position of the vehicle heading for the boarding position before the change is within a predetermined distance range from the boarding position, the boarding position may be prohibited (impossible) to be changed. . Also, an upper limit may be set for the changeable range of the boarding position (the distance between the boarding position before change and the boarding position after change).

Also, in this example, when the position of the boarding position specifying object 521 on the map is changed, the orientation of the traveling direction display object 5211 indicating the traveling direction of the vehicle at the boarding position may change. FIG. 15 is a diagram for explaining how the orientation of the traveling direction display object 5211 changes according to the change in the position of the boarding position specifying object 521 on the map. As shown in the upper part of FIG. 15 , on a road having two lanes LN1 and LN2 in both directions separated by the central zone CZ, when the boarding position specifying object 521 is positioned near the sidewalk on the lane LN1 side, , the orientation of the traveling direction display object 5211 is the traveling direction of the vehicle in the lane LN1 (lower right direction in FIG. 15). Then, as shown in the lower part of FIG. 15, when the position of the boarding position specifying object 521 is changed to a position near the sidewalk on the lane LN2 side, the orientation of the traveling direction display object 5211 changes to the traveling direction of the vehicle on the lane LN2. (upper left direction in FIG. 15). In this way, the user can set (change) the boarding position while confirming the orientation of the traveling direction display object 5211 (that is, the traveling direction of the vehicle).

Also, in this example, the boarding position specifying object 521 is configured so as not to be arranged in the above-described non-recommended boarding area in the map display area 52 . FIG. 16 exemplifies the pick-up waiting screen 503 in a state where the change (for example, slide operation) of the position of the boarding position specifying object 521 has started. As shown in the figure, in the map display area 52, an area A1 corresponding to the non-recommended boarding area is visibly displayed (for example, a translucent specific (displayed as areas of color (eg, red)). The non-recommended boarding area here includes the non-recommended boarding area of the taxi company for the assigned vehicle in addition to the non-recommended boarding area common to a plurality of vehicles. The user can know the existence of the non-recommended boarding area from the area A1. In addition, in the area A1, the reason why it is set as the non-recommended boarding area (for example, "cannot be dispatched because it is near a taxi stand") may be displayed. In addition to the area A1 corresponding to the non-recommended boarding area, the area corresponding to the recommended boarding area is visibly displayed (for example, translucent However, the non-recommended boarding area may be displayed as a specific color (for example, blue) area) to guide the user to another recommended boarding area.

Returning to the flowchart of FIG. 7, when there is no allocatable vehicle when selecting a vehicle in step S110 (NO in step S115), the server 10 waits for a predetermined time T1 (for example, 5 minutes) to elapse. (NO in step S150). Specifically, the time when waiting starts is set as the waiting start time of the vehicle allocation request information table 413, and vehicle selection (step S110) is repeatedly tried until a predetermined time T1 elapses from the waiting start time. . Then, when an allocatable vehicle is generated, the vehicle is selected as a vehicle to be allocated to the user. Cancel the request (step S160). Cancellation of the vehicle allocation request, for example, involves execution of a predetermined cancellation process for canceling the vehicle allocation request. Thus, in this example, even if there is no allocatable vehicle, the user can wait for an allocatable vehicle for the predetermined time T1 before canceling the dispatch request.

Further, in this example, when a specific vehicle can be applied as an allocatable vehicle for a plurality of waiting users, the specific vehicle is used for a user with an early waiting start time (a user whose waiting order precedes). assigned. For example, as illustrated in FIG. 17, the empty vehicle 200 reaches the boarding positions of user A (waiting start time is 9:04) and user B (waiting start time is 9:06). If the estimated waiting time is within a predetermined range and the vehicle 200 can be applied as an allocatable vehicle, the vehicle 200 is allocated to user A whose waiting start time is early.

In this way, in this example, the user can make a taxi dispatch request by a simple one-tap operation of selecting the first button 61 on the top screen 501. ), and during the period of waiting for pick-up, the boarding position can be changed, the destination (drop-off position) can be set, and the like. In addition, even if there is no allocatable vehicle, the user can wait for an allocatable vehicle to appear for the predetermined time T1. It should be noted that the start and/or end of the standby (setting of the predetermined time T1) when there is no allocatable vehicle may be performed in accordance with an instruction from the user. In this way, the user can wait for dispatch (occurrence of an allocatable vehicle) according to the available spare time, and saves the trouble of repeating the dispatch request operation until the vehicle is allocated. As a result, user convenience can be improved.

Note that when repeatedly trying to select a vehicle (step S110) while waiting for the generation of an allocatable vehicle, setting the boarding position (step S100) based on the user's current position is also repeatedly performed (in other words, the user's latest Allocable vehicles are repeatedly selected based on the current position of the .). In this way, for example, a user who waits for an allocatable vehicle while moving toward a destination on foot ), and (to facilitate the generation of allocatable vehicles), it is possible to deal with users who wait for the generation of allocatable vehicles while moving on their own to roads/areas with heavy traffic. Even if the user moves, the waiting start time is not changed (the waiting order is secured), so moving does not disadvantage the user.

The case where a vehicle allocation request is made without specifying conditions has been described above. Next, a description will be given of a case where a vehicle allocation request is made by designating conditions. FIG. 18 exemplifies a condition designation screen 504 displayed on the user terminal 32 in response to selection of the second button 62 on the top screen 501 . The condition specifying screen 504 has a map display area 52 and an information display area 54 , like the top screen 501 , the on-arrangement screen 502 , and the pick-up waiting screen 503 .

A boarding position specifying object 521 is arranged in the map display area 52 of the condition specifying screen 504 . The user can individually specify the boarding position by changing the position of the object 521 . In addition, the boarding position designation object 521 has a traveling direction display object 5211 at its lower end, and the arrow-shaped object 5211 is the nearest lane from the position of the boarding position designation object 521 on the map, as described above. It is arranged so as to face the direction of travel. As with the map display area 52 of the arranging screen 502 and the pick-up waiting screen 503 described above, the map display area 52 of the condition designation screen 504 changes the non-recommended The area corresponding to the area (here, since it is before allocating vehicles, only the non-recommended boarding area common to multiple vehicles is targeted, and the non-recommended boarding area for each taxi company is not targeted) is visible. The object 521 is configured so that it cannot be placed in the non-recommended boarding area. Further, as described above, in addition to the non-recommended boarding area, the area corresponding to the recommended boarding area may be visibly displayed.

In the information display area 54 of the condition specifying screen 504, an estimate of the waiting time at the present time is displayed, as well as a first button 66 for setting the destination, a second button 67 for selecting the payment method, and a vehicle type. and a fourth button 69 displaying "request".

When the first button 66 is selected by the user, a screen for setting the destination (drop-off position) is displayed, and the user can set the destination in advance via the screen. Note that the user can also omit the setting of the destination.

When the second button 67 is selected by the user, a screen for selecting a payment method is displayed, through which the user can preset the payment method. In this example, the payment method is either in-vehicle payment or Internet payment (including credit card payment), and in-vehicle payment is set in the initial state.

When the third button 68 is selected by the user, a screen for selecting the vehicle type, etc. of the vehicle to be arranged is displayed, and the user can set the vehicle type, etc. via the screen. It should be noted that, on this screen, in addition to the type of vehicle, it is also possible to specify whether or not it is a UD taxi, and whether or not admission to the facility X is permitted.

A fourth button 69 is a button for the user to make a dispatch request. FIG. 19 is a flowchart illustrating processing executed by the dispatch management server 10 in response to the user's selection of the fourth button 69 . The server 10 first sets the user's boarding position (pick-up position) based on the designation by the user, as shown in the figure (step S200). Specifically, the position on the map of the boarding position designation object 521 in the map display area 52 of the condition designation screen 504 is set as the boarding position of the user.

After the user's boarding position is set in this way, the server 10 next selects a vehicle to be assigned to the user based on the user's boarding position, user's designation (type of vehicle, etc.), and vehicle information of each vehicle (step S210). Basically, it is possible to allocate a vacant vehicle that has an expected waiting time to arrive at the user's boarding position within a predetermined range (for example, within 15 minutes) and that conforms to the vehicle type specified by the user. If there are a plurality of allocatable vehicles, the vehicle with the shortest expected waiting time (for example, closest to the user's boarding position) is allocated to the user. Also, as in the case of making a dispatch request without specifying any conditions, if the user's boarding position is within the premises of the facility X, the allocatable vehicles are limited to vehicles that have permission to enter the facility X. If the boarding position falls within the non-recommended boarding area of a particular taxi company, the allocatable vehicles are restricted to vehicles other than those of that particular taxi company.

If the destination (drop-off position) is set by the user and the destination is within the premises of facility X, the allocatable vehicles are , limited to vehicles with permission to enter the facility X.

Also, as described above, if there is no allocatable vehicle that has permission to enter facility X, the user's boarding position is changed (automatically or through user confirmation) to outside facility X. , vehicles that do not have permission to enter the facility X may be assigned.

Then, if there is an allocatable vehicle (YES in step S215), server 10 requests the selected vehicle to pick up the vehicle (step S220). Subsequent processing is the same as the flowchart illustrated in FIG. That is, when the corresponding driver accepts the pick-up request (YES in step S230), the assignment of the vehicle to the user is confirmed (step S240), while when the corresponding driver rejects the pick-up request (NO in step S230). , the server 10 again selects a vehicle to be allocated (step S210). If there is no allocatable vehicle (NO in step S215), the system waits for a predetermined time T1 (for example, 5 minutes) to elapse (NO in step S250), and repeats vehicle selection (step S210). try. When an allocatable vehicle is generated, the vehicle is selected as a vehicle to be allocated to the user. Cancel the request (step S260). Thus, in this example, by selecting the second button 62 on the top screen 501, the user can individually specify conditions and make a dispatch request. When it does not exist, it is possible to wait for the occurrence of an allocatable vehicle for a predetermined time T1.

As in the case of making a dispatch request without specifying the conditions described above, when repeatedly trying to select a vehicle (step S210) while waiting for the generation of an allocatable vehicle, based on the latest current position of the user, You may make it select the allocatable vehicle. For example, when the distance from the boarding position set based on the designation by the user (step S200) to the latest current position of the user is greater than or equal to a predetermined value, there is a request to change to the boarding position based on the latest current position. A screen is displayed for confirming whether or not the vehicle can be assigned based on the boarding position after the change (the boarding position based on the latest current position) when the user requests a change of the boarding position via the screen. may be selected.

In the above example, when the destination (drop-off position) is set, the traveling direction of the vehicle at the destination may be displayed in the same manner as the boarding position. For example, the position on the map of the object corresponding to the boarding position designation object 521 is set as the drop-off position, and the traveling direction of the vehicle at the drop-off position corresponds to the traveling direction display object 5211 arranged at the lower end of the object. indicated by the orientation of the object.

In the above example, the non-recommended boarding area to be avoided when setting the boarding position is registered in the road map data 415. Also good. The non-recommended drop-off areas include a non-recommended drop-off area common to a plurality of vehicles set by the operator of the dispatch management service, and a non-recommended drop-off area for each taxi company set by each taxi company. When a vehicle dispatch request is made without specifying conditions, when setting/changing the destination via the first button 64 of the vehicle waiting screen 503, the non-recommended boarding area common to a plurality of vehicles and The non-recommended boarding area of the taxi company of the assigned vehicle is avoided (controlled so that the destination cannot be set within the area). In addition, in the case of making a dispatch request by specifying conditions, when setting the destination via the first button 66 of the condition specifying screen 504, the non-recommended get-off area common to a plurality of vehicles is avoided and the set If the selected destination is within the non-recommended drop-off area of a specific taxi company, in step S210, the vehicles to be allocated are limited to vehicles other than those of the specific taxi company.

In the above example, when the set boarding/dropping positions are specific facilities such as hospitals and nursing care facilities, UD taxi vehicles may be allocated. In this case, facilities to which UD taxi vehicles should be assigned when set as pick-up/drop-off locations can be registered in road map data 415 .

In the above example, when there is no allocatable vehicle, the allocatable vehicle waits for the predetermined time T1. can. In order to accommodate such users, the user may be allowed to select a "Priority Dispatch" option in which vehicles are preferentially allocated. The priority dispatch is configured as a paid option that requires compensation such as an additional fee, and is selected by the user, for example, when requesting dispatch (and/or when starting waiting). When priority vehicle allocation is selected, specifically, the vehicle search range (for example, the expected waiting time until arrival at the user's boarding position (or the distance to the boarding position ) is within a predetermined range) is expanded. For example, if priority vehicle allocation is not selected, a vehicle that has an estimated waiting time of 15 minutes or less to arrive at the user's boarding position is an allocatable vehicle. A vehicle that has an estimated waiting time of 20 minutes or less before arriving at the boarding position of 1 is regarded as an allocatable vehicle.

In addition, a user who selects priority vehicle allocation is prioritized for vehicle allocation over general users who are on standby. FIG. 20 is a diagram for explaining how a vehicle is preferentially allocated to a user who has selected a priority vehicle allocation option. As shown in the figure, for example, at 9:08, when user C selects the option for priority vehicle allocation and requests vehicle allocation, and the vehicle 200 becomes empty, the vehicle of user C who has selected priority vehicle allocation becomes available. The search range (dashed line) is expanded from the vehicle search range (solid line) when priority dispatch is not selected, and the vehicle 200 is included in the expanded vehicle search range (broken line). In this case, user A (waiting start time is 9:04) and user B (waiting start time is 9:06), who are waiting in advance, are put aside, and the vehicle is sent to user C who has selected priority dispatch. 200 are assigned. Note that even if the user C selects the priority vehicle allocation option and requests the vehicle allocation after the vehicle 200 is allocated to either the user A or the user B who is waiting in advance, the user C If the dispatch request is made before the allocation of the vehicle 200 is confirmed (that is, before the pick-up request is accepted), the vehicle 200 may be allocated preferentially to the user C.

In this way, by selecting the option of priority dispatch, allocation vehicles are selected for a wider range of vehicles than usual, and priority is given to general users waiting, so that the number of vehicles is increased. Allocation is facilitated early and reliably. Such priority vehicle allocation options improve convenience for users who want to request early and reliable vehicle allocation even if they have to pay a fee.

It should be noted that, when the option of priority vehicle allocation is selected, the driver of the vehicle requesting the pick-up may be notified that the option of priority vehicle allocation has been selected. Since priority dispatch is advantageous for the driver as well, such as additional charges, such a notification improves the probability that the pick-up request will be accepted, and as a result, the user's convenience can be improved.

Further, when the elapsed time from the start of standby reaches a predetermined time T2 (<T1), the vehicle search range may be expanded as described above regardless of whether the priority vehicle allocation option is selected or not. good. By doing so, the standby time is prevented from becoming excessively long, and as a result, the user's convenience can be improved.

The vehicle allocation management server 10 according to the present embodiment described above sets the user's boarding position, and presents the set boarding position to the user along with the traveling direction of the vehicle at the boarding position. Even in the case of setting the boarding position near the road having lanes in both directions, it is possible to accurately determine which sidewalk to wait on, out of the sidewalks on both sides of the road. In other words, the vehicle allocation management server 10 in this embodiment improves the user's convenience when making a vehicle allocation request.

In addition, the vehicle allocation management server 10 according to the present embodiment selects a vehicle in response to a vehicle allocation request from a user (steps S110 and S210), even if there are no allocatable vehicles, During T1, it is possible to wait for the occurrence of allocatable vehicles. In this way, once the user makes a vehicle allocation request, the user can repeatedly try to select a vehicle for the predetermined time T1, thereby saving the trouble of repeating the vehicle allocation request operation until the vehicle is allocated. . As a result, user convenience can be improved.

The processes and procedures described herein, other than those explicitly described, may be implemented in software, hardware, or any combination thereof. For example, the processes and procedures described herein are implemented by implementing logic corresponding to the processes and procedures in media such as integrated circuits, volatile memory, non-volatile memory, magnetic disks, and the like. Moreover, the processes and procedures described in this specification can be implemented as computer programs corresponding to the processes and procedures, and can be executed by various computers.

Although the processes and procedures described herein are described as being performed by a single device, software, component or module, such processes or procedures may be performed by multiple devices, software, components or modules. and/or by multiple modules. Also, the software and hardware elements described herein can be implemented by aggregating them into fewer components or by decomposing them into more components.

In this specification, even if the components of the invention are described as either singular or plural, or are described without being limited to either singular or plural, when the context requires otherwise , the component may be singular or plural.

10 Vehicle allocation management server 11 Computer processor 20 Communication network 32 User terminal 34 Driver terminal 41 Information storage management unit 42 Basic function control unit 43 Vehicle allocation request management unit 44 Vehicle pick-up request management unit 100 Pick-up request confirmation screen 110 Pick-up screen 120 Arrival report screen 130 Boarding report screen 501 Top screen 502 Arranging screen 503 Pick-up waiting screen 504 Condition specifying screen 521 Boarding position specifying object 5211 Traveling direction display object

Claims (6)

A system for managing dispatch of vehicles, comprising:
A storage device for storing at least vehicle information for each of a plurality of vehicles, and one or more computer processors,
The one or more computer processors, in response to executing readable instructions,
a process of accepting a vehicle dispatch request from a user;
a process of setting the boarding position of the user;
a process of selecting a vehicle to be assigned to the user from among the plurality of vehicles based at least on the set boarding position of the user and the vehicle information of each of the plurality of vehicles;
requesting the selected vehicle to be assigned to the user to pick up the vehicle at the boarding position of the user;
The process of setting the boarding position of the user includes:
setting a position on the map specified by the user as the boarding position of the user; and
identifying the lane closest to the location on the map specified by the user and displaying the direction of travel of the vehicle in the identified lane;
system. The one or more computer processors further perform a process of setting the user's exit position,
The user's drop-off position is configured to be presented to the user along with the traveling direction of the vehicle assigned to the user at the user's drop-off position.
The system of Claim 1 . The process of selecting the vehicle includes waiting for an allocatable vehicle to occur if there is no allocatable vehicle that can be allocated to the user.
3. The system of claim 1 or 2 . The storage device further stores information capable of specifying the waiting order of waiting users waiting for the generation of allocatable vehicles,
In the process of selecting the vehicle, when a specific allocatable vehicle that can be allocated to a plurality of waiting users occurs, the specific allocatable vehicle is selected as a vehicle to be allocated to the waiting user whose waiting order is the highest. including
4. The system of claim 3 . A method for managing dispatch of vehicles, executed by one or more computers accessible to a storage device storing at least vehicle information for each of a plurality of vehicles, comprising:
receiving a request for dispatching a vehicle from a user;
setting the riding position of the user;
a step of selecting a vehicle to be assigned to the user from among the plurality of vehicles based at least on the set boarding position of the user and the vehicle information of each of the plurality of vehicles;
requesting the selected vehicle to be assigned to the user to pick up the vehicle at the boarding position of the user;
The step of setting the riding position of the user includes:
setting a position on the map specified by the user as the boarding position of the user; and
identifying the closest lane from a location on the map specified by the user and displaying the direction of travel of the vehicle in the identified lane;
Method. A program for managing vehicle dispatch, comprising:
Upon execution on one or more computers accessible to a storage device storing at least vehicle information for each of a plurality of vehicles, the one or more computers,
a process of accepting a vehicle dispatch request from a user;
a process of setting the boarding position of the user;
a process of selecting a vehicle to be assigned to the user from among the plurality of vehicles based at least on the set boarding position of the user and the vehicle information of each of the plurality of vehicles;
requesting the selected vehicle to be assigned to the user to pick up the vehicle at the user's boarding position;
The process of setting the boarding position of the user includes:
setting a position on the map specified by the user as the boarding position of the user; and
identifying the closest lane from a location on the map specified by the user and displaying the direction of travel of the vehicle in the identified lane;
program.

Images