JP6811746B2 - Systems, methods, and programs for managing vehicle allocation - Google Patents

Description

The present invention relates to systems, methods, and programs 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, when a user makes a vehicle allocation request with a designation of a boarding position (pick-up position), an empty vehicle traveling in an area in the vicinity of the designated boarding position is searched for and dispatched. In addition, typically, the user can also specify conditions related to the vehicle (for example, vehicle type) to search for a vehicle to be dispatched.

JP-A-2018-49408

However, in the conventional system, it is necessary to specify the boarding position and the conditions related to the vehicle when requesting the vehicle allocation, and some users may find this annoying. As described above, in the conventional system for managing vehicle allocation, there is room for improvement in user convenience when requesting vehicle allocation.

One of the objects of the embodiment of the present invention is to improve the convenience of the user when requesting vehicle allocation. Other objects of the embodiments of the present invention will become apparent by reference to the entire specification.

The system according to an embodiment of the present invention is a system for managing vehicle allocation, and stores at least vehicle information including a current position and a predetermined attribute, which is vehicle information of each of a plurality of vehicles. A storage device and one or more computer processors are provided, and the one or more computer processors set a process of receiving a vehicle allocation request by a user and a boarding position of the user in response to execution of a readable instruction. A process of selecting a vehicle to be assigned to the user from the plurality of vehicles based on at least the set riding position and the vehicle information of each of the plurality of vehicles, and the selected vehicle. The process of requesting a vehicle to pick up at the set boarding position and the process of selecting the vehicle are such that a vehicle having a value of the predetermined attribute specified at least based on the set boarding position is described. Includes selecting as the vehicle to assign to the user.

The method according to an embodiment of the present invention is executed by one or a plurality of computers having access to a storage device that stores at least vehicle information including a current position and a predetermined attribute, which is vehicle information of each of a plurality of vehicles. It is a method for managing the vehicle allocation, which is a step of accepting a vehicle allocation request by a user, a step of setting the user's boarding position, the set boarding position, and each vehicle of the plurality of vehicles. A step of selecting a vehicle to be assigned to the user from the plurality of vehicles based on at least the information, and a step of requesting the selected vehicle to pick up the vehicle at the set boarding position are provided. The step of selecting a vehicle includes selecting a vehicle having a value of the predetermined attribute specified at least based on the set boarding position as a vehicle to be assigned to the user.

The program according to the embodiment of the present invention is a program for managing vehicle allocation, and stores at least vehicle information including a current position and a predetermined attribute, which is vehicle information of each of a plurality of vehicles. A process of receiving a vehicle allocation request by a user, a process of setting a boarding position of the user, and a process of setting the user's boarding position, according to execution on one or a plurality of computers accessible to the storage device. A process of selecting a vehicle to be assigned to the user from the plurality of vehicles based on at least the boarding position and the vehicle information of each of the plurality of vehicles, and to the boarding position set for the selected vehicle. The process of requesting the pick-up of the vehicle and the process of selecting the vehicle select the vehicle having the value of the predetermined attribute specified at least based on the set boarding position as the vehicle to be assigned to the user. Including that.

Various embodiments of the present invention improve user convenience when requesting vehicle allocation.

FIG. 6 is a configuration diagram schematically showing a configuration of a network including a vehicle allocation management server 10 according to an embodiment of the present invention. A block diagram schematically showing the functions of the vehicle allocation management server 10. The figure which illustrates the information managed in the user information table 411. The figure which illustrates the information managed in the vehicle information table 412. The figure which illustrates the information managed in the vehicle allocation request information table 413. The figure which illustrates the top screen 501. The flow chart which illustrates the process executed by the vehicle allocation management server 10. The figure which illustrates the arranging screen 502. The figure which illustrates the pick-up request confirmation screen 100. The figure which illustrates the pick-up waiting screen 503. The figure which illustrates the screen 110 during the pick-up. The figure which illustrates the arrival report screen 120. The figure which illustrates the boarding report screen 130. The figure which illustrates the pick-up waiting screen 503. The figure which illustrates the pick-up waiting screen 503. The figure which illustrates the condition designation screen 504. The flow chart which illustrates the process executed by the vehicle allocation management server 10.

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

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

The vehicle allocation management server 10 is configured as a general computer, and as shown in FIG. 1, a computer processor 11 configured as a CPU, a GPU, or the like, a main memory 12, an input / output I / F13, and a communication I A / F14 and a storage (storage device) 15 are provided, and each of these components is electrically connected via a bus or the like (not shown).

The computer processor 11 reads various programs stored in the storage 15 and 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 or the like.

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, an information input device such as a keyboard and a pointing device (for example, a mouse, a touch panel, etc.), a voice input device such as a microphone, and an image input device such as a camera. Further, 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 communication software, and a combination thereof, and is configured to realize wired or wireless communication via the communication network 20 or the like.

The storage 15 is composed of, for example, a magnetic disk, a flash memory, or the like. 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 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, a wearable device, and the like. 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.

In the present embodiment, the vehicle allocation management server 10 can be configured to have functions as a web server and an application server, in which case a web browser or other application (for example, the user terminal 32 or the driver terminal 34 has). Various processes are executed in response to a request from the vehicle allocation management service application), and screen data (for example, HTML data), control data, and the like corresponding to the results of the processes are transmitted. The user terminal 32 and the driver terminal 34 display a web page or other screen based on the received data.

Next, the function of the vehicle allocation management server 10 of the present embodiment will be described. FIG. 2 is a block diagram schematically showing the functions of the server 10. As shown in the figure, the server 10 has an information storage management unit 41 that stores and manages information, a basic function control unit 42 that controls the basic functions of the vehicle allocation management service, and a vehicle allocation request management unit that manages vehicle allocation requests from users. It has a vehicle pick-up request management unit 44 that manages a vehicle pick-up request for a vehicle. These functions are realized by the 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 operating in cooperation with each other. For example, the main memory 12 has such a function. This is realized by the computer processor 11 executing the instructions included in the read program. Further, a part or all of the functions shown in FIG. 2 may be realized by the cooperation of 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 41 of the server 10 is composed of a storage 15 and the like, and stores and manages various information. For example, as shown in FIG. 2, the information storage management unit 41 has a user information table 411 that manages information about users of the vehicle allocation management service and a vehicle information table that manages information about vehicles that are the target of vehicle allocation in the vehicle allocation management service. It may have 412, a vehicle allocation request information table 413 that manages information regarding a vehicle allocation request from a user, and road map data 415.

The basic function control unit 42 of the server 10 executes various processes related to the control of the basic functions of the vehicle allocation management service. For example, the basic function control unit 42 transmits HTML data or control data of various screens related to the basic function to the user terminal 32 or the driver terminal 34, and the user via the screen displayed on the user terminal 32 or the driver terminal 34. Alternatively, various processes are executed in response to the operation input by the driver, and HTML data or control data according to the result of the processes is transmitted to the user terminal 32 or the driver terminal 34. Basic functions The basic functions controlled by the control unit 42 include, for example, login processing (user authentication), payment processing, user management (for example, updating the user information table 411, etc.), and vehicle management (for example, vehicle). (Update of information table 412, etc.) and the like are included.

The vehicle allocation request management unit 43 of the server 10 executes various processes related to the management of the vehicle allocation request from the user. In the present embodiment, the vehicle allocation request management unit 43 is configured to receive a vehicle allocation request from a user and set the boarding position (vehicle pick-up 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 the screen displayed on the user terminal 32, and the position designated by the user via the screen is set as the boarding position. It is configured to be set or to automatically set the boarding position based on the user's current position (position information of the user terminal 32, etc.) and the like.

Further, the vehicle allocation request management unit 43 selects a vehicle to be assigned to the user from 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. It is configured in. The vehicle information of each vehicle includes a current position and a predetermined attribute, and is managed in, for example, the vehicle information table 412.

In the present embodiment, the vehicle allocation request management unit 43 is configured to select a vehicle having a predetermined attribute value specified at least based on the set boarding position as a vehicle to be assigned to the user. For example, the vehicle allocation request management unit 43 is specified above when the distance from the set boarding position is within a predetermined range (or the predicted waiting time until reaching the boarding position is within a predetermined range). Among the vehicles having the attribute value, the vehicle having the closest distance from the boarding position is selected.

The pick-up request management unit 44 of the server 10 executes various processes related to the pick-up request for the vehicle. In the present embodiment, the vehicle 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 vehicle at the set 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 boarding position of the user. .. The correspondence between the vehicle and the driver terminal 34 (driver) is managed in, for example, the vehicle information table 412.

As described above, the vehicle allocation management server 10 in the present embodiment sets the boarding position of the user and assigns the vehicle having a predetermined attribute value specified based on the set boarding position to the user, and is therefore suitable for the boarding position. While enabling the allocation of vehicles, the increase in the burden on the user for specifying the vehicle conditions at the time of requesting vehicle allocation is suppressed. That is, the vehicle allocation management server 10 in the present embodiment improves the convenience of the user when requesting vehicle allocation.

In the present embodiment, the vehicle allocation request management unit 43 sets the user's disembarkation position in addition to the user's boarding position, and the user obtains a vehicle having a predetermined attribute value specified at least based on the set disembarkation position. Can be configured to be selected as the vehicle to be assigned to. For example, the vehicle allocation request management unit 43 is configured to set a position designated by the user as a disembarkation position via a screen for receiving a vehicle allocation request. Such a configuration enables allocation of vehicles suitable for the disembarkation position, and suppresses an increase in the burden on the user for specifying vehicle conditions at the time of requesting vehicle allocation.

In addition, when the set boarding / alighting position is included in a specific restricted area where a vehicle having an admission permit can enter and a vehicle without an admission permit cannot enter, the vehicle allocation request management unit 43 determines the specific restricted area. Vehicles with admission to the user may be configured to be selected as the vehicle to be assigned to the user. That is, the predetermined attribute includes the presence / absence of admission to a specific restricted area. The presence or absence of admission to a specific restricted area is managed, for example, in the vehicle information table 412. Further, the specific restricted area can be managed by the road map data 415, and includes, for example, various factories, military facilities, and the like. Such a configuration facilitates proper vehicle allocation when the boarding position or disembarking position is included in a specific restricted area.

Further, the vehicle allocation request management unit 43 specifies the boarding / alighting position when the set boarding / alighting position is included in the specific restricted area and the vehicle having the admission permission for the specific restricted area cannot be selected. It can be configured to suggest changes to the outside of the restricted area to the user. For example, when the distance from the set boarding position is within a predetermined range and there is no vehicle having the above admission permission, the vehicle allocation request management unit 43 changes the boarding / alighting position via the user terminal 32. It is configured to propose to. The proposal is made with the specification of the boarding / alighting position after the change, or is made without specifying the boarding / alighting position after the change. Such a configuration assists in changing the boarding / alighting position when a vehicle with admission is not assigned.

Further, the vehicle allocation request management unit 43 may be configured to set the user's boarding / alighting position so as to be outside the non-recommended boarding / alighting area which is not recommended as the boarding / disembarking position. The non-recommended boarding area includes, for example, a road with a guardrail, a taxi stand (because troubles such as erroneous boarding by another user may occur), and the like. Deprecated drop-off areas include, for example, roads with guardrails. These deprecated boarding / alighting areas can be managed in the road map data 415. Such a configuration suppresses that an inappropriate position as the boarding / alighting position of the user is set as the boarding / alighting position.

In the present embodiment, at least a part of the plurality of vehicles is associated with any of the plurality of taxi operators, and at least a part of the non-recommended boarding / alighting area is set as an area for each taxi operator. , At least part of it may be configured to be set as a common area for multiple vehicles. In this case, the vehicle allocation request management unit 43 determines that when the set boarding / alighting position is included in the non-recommended boarding / alighting area of a specific taxi operator, the vehicle other than the vehicle associated with the specific taxi operator. Can be configured to be selected as the vehicle to assign to the user. The taxi operator associated with the vehicle is managed, for example, in the vehicle information table 412. Such a configuration encourages the allocation of taxi operator vehicles suitable for the set boarding / alighting positions.

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 vehicle allocation management server 10 provides a vehicle allocation management service for taxis of a plurality of taxi companies. In the present embodiment, the vehicle subject to vehicle allocation management is not limited to the taxi of a taxi company, and may include a private vehicle of a general public.

FIG. 3 illustrates the information managed in the user information table 411 in this example. The user information table 411 manages information about users of the vehicle allocation management service, and as shown in the figure, associates with a "user account" that identifies an individual user, such as "user basic information", "wheelchair use flag", and the like. Manage information. The user basic information includes, for example, a name, contact information, payment information (credit card information, etc.) and the like. In addition, the wheelchair use flag indicates whether or not a wheelchair is used.

FIG. 4 illustrates the 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 subject to the vehicle allocation management service, and as shown in the figure, associates the "vehicle ID" that identifies the individual vehicle with the "vehicle basic information", It manages information such as "taxi company information", "UD taxi flag", "facility X admission flag", "current position", "vehicle allocation status", and "driver account" that identifies the corresponding driver. The basic vehicle information includes a vehicle type, the number of passengers, an image (photograph or figure) corresponding to the appearance of the vehicle, a 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 the elderly. The facility X admission flag indicates whether or not admission to a specific facility X is permitted. Facility X includes, for example, various factories, military facilities, and the like. For the current position, the position information transmitted from the information terminal or the driver terminal 34 mounted on the vehicle is set. The vehicle allocation status is set to a value corresponding to each status including "rental", "pick-up", and "empty vehicle".

FIG. 5 illustrates the information managed in the vehicle allocation request information table 413 in this example. The vehicle allocation request information table 413 manages information related to the vehicle allocation request from the user, and as shown in the figure, identifies the user who made the vehicle allocation request in association with the "vehicle allocation request ID" that identifies the individual vehicle allocation request. It manages information such as "user account", "boarding position", "getting off position", "payment method", and "vehicle ID" that identifies the assigned vehicle.

FIG. 6 illustrates a top screen 501 displayed on the user terminal 32 of the user who uses the vehicle allocation management service of this example. As shown in the figure, the top screen 501 has a map display area 52 and an information display area 54 located below the area 52.

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

The map display area 52 is configured so that the range of the displayed map is 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 with the sliding of the displayed map range.

The information display area 54 displays a guideline for the current waiting time (“5 to 8 minutes” in the example of FIG. 6) when the user makes a vehicle allocation request, and also displays “Call a taxi with one tap”. It has a first button 61 and a second button 62 displaying "Call a taxi by designating conditions". The guideline of the waiting time is calculated based on, for example, the distance between each of a predetermined number (for example, three) of vacant vehicles and the user in order from the user's current position.

The first button 61 is a button for making a vehicle allocation request without specifying a condition (with one tap), and the second button 62 is a button for making a vehicle allocation request by specifying a condition. First, a case where a vehicle allocation request is made without specifying conditions will be described.

FIG. 7 is a flow chart illustrating a process executed by the vehicle allocation management server 10 in response to the user's selection of the first button 61. First, as shown in the figure, 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 vehicle allocation request table 413.

Setting the boarding position based on the user's current position can be realized by applying various rules. In this example, if the vehicle can be stopped and there is a recommended riding area recommended as the boarding position within a predetermined distance from the user's current position, the position within the recommended boarding area (for example, , The position closest to the user's current position in the area) is set as the user's boarding position. Such a recommended boarding area is set in advance by the operator of the vehicle allocation management service, for example, and is registered in the road map data 415. For example, in the vehicle allocation management service, the operator can set an area including a position individually designated as a boarding position by many users in the past as a recommended boarding area. Such a recommended boarding area can also be said to be a taxi stand virtually provided in the vehicle allocation 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 vehicle can be stopped at the stop position closest to the user's current position. Is set as the boarding position of the user. At this time, the boarding position is set so as to avoid a non-recommended boarding area that is not appropriate as the boarding position.

Here, the deprecated boarding area in this example is a deprecated boarding area common to a plurality of vehicles set by the operator of the vehicle allocation management service and a deprecated boarding area set individually by each taxi company for each taxi company. Includes boarding area. When setting the boarding position of the user in step S100, the non-recommended boarding area common to a plurality of vehicles is avoided among these non-recommended boarding areas, and the non-recommended boarding area for each taxi company is not considered (avoidance). Not done).

These deprecated boarding areas are registered in the road map data 415. For example, a road with a guardrail, a taxi stand, etc. are set as non-recommended boarding areas. Further, in another example of the present embodiment, for example, a deprecated riding area common to a plurality of vehicles is automatically set based on information acquired from an external system or the like. For example, the non-recommended boarding area can be automatically set based on information on road construction schedules and traffic regulations acquired from an external system or the like.

After setting the boarding position of the user in this way, the server 10 then selects the vehicle to be assigned to the user based on the boarding position of the user, the wheelchair use flag, and the vehicle information of each vehicle (step S110).

In this example, basically, the empty vehicle closest to the user's boarding position is assigned to the user, but in the following cases, the vehicle to be assigned is limited. First, when the user is a user who uses a wheelchair (identified by referring to the wheelchair use flag in the user information table 411), the vehicle to be assigned is a UD taxi vehicle (UD taxi in the vehicle information table 412). (Identified by referencing the flag). Further, when the boarding position of the user is within the premises of the facility X (within a specific restricted area), the vehicle to be assigned is a vehicle having an admission permission for the facility X (facility X admission permission for the vehicle information table 412). (Identified by reference to the flag). Further, when the user's boarding position is included in the non-recommended boarding area of a specific taxi company, the vehicle to be allocated is a vehicle other than the vehicle of the specific taxi company (refer to the taxi company information in the vehicle information table 412). Identified by doing).

Here, when the vehicle to be allocated is limited, the target vehicle (for example, a vehicle of a UD taxi, a vehicle having an admission permission for facility X, a vehicle other than a vehicle of a specific taxi company, etc.) , When the vehicle is not within a predetermined distance from the user's boarding position, the user may be managed as a waiting state (automatically or through confirmation by the user). When the user is in the waiting state for dispatch, the server 10 waits for the target vehicle, and when the target vehicle enters within a predetermined distance from the user's boarding position, the server 10 allocates the target vehicle.

Further, when there is no vehicle having an admission permission for the facility X within a predetermined distance from the user's boarding position, the user's boarding position is set outside the facility X (automatically or the user's confirmation is confirmed. It may be modified (via) to assign other vehicles that do not have admission to Facility X. It should be noted that such a proposal for changing the boarding position of the user may be limited to the case where there are other vehicles to which the vehicle can be assigned. The boarding position after the change is preset with respect to the facility X. For example, a specific entrance / exit of the facility X is preset as the boarding position on the outside after the change. In this case, for example, the reason why the user's boarding position cannot be set in the premises of the facility X (reason for NG dispatch, for example, "cannot arrange a vehicle that can handle this area") is displayed, and the user boarding in the map display area 52. It is preferable to visually display the area where the position cannot be set (specifically, the site of the facility X) (for example, display as an area of a specific translucent color (for example, red)).

When the vehicle to be assigned to the user is selected in this way, the server 10 then requests the selected vehicle to pick up the vehicle (step S120). FIG. 8 illustrates an arranging screen 502 displayed on the user terminal 32 in response to a request for pick-up of the selected vehicle. The arranging screen 502 has a map display area 52 and an information display area 54, similarly to the top screen 501. As shown in the figure, in the map display area 52 of the arranging screen 502, the character string "arranging a taxi" is superimposed on the map, and the pin shape "ride here" is displayed. The boarding position designation 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. In addition, in the boarding position designation object 521, the traveling direction of the vehicle at the boarding position may be displayed by an arrow or the like.

In addition, the information display area 54 of the arranging screen 502 displays a guideline for the waiting time at the present time, and has a cancel button 63 for canceling the pick-up request. The user selects the cancel button 63, for example, when the selection operation for the first button 61 on the top screen 501 is mistakenly performed. Depending on the selection of the button 63, the server 10 performs a predetermined cancellation process 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 the vehicle information table 412. On the pick-up request confirmation screen 100, as shown in the figure, the first button 102 displayed as "OK" and the second button 104 displayed as "Cancel" are arranged side by side in the vertical direction. The driver selects the first button 102 when accepting the pick-up request, and selects the second button 104 when not accepting (rejecting) the pick-up request.

Further, the pick-up request confirmation screen 100 is configured so that if the first button 102 is not selected within 10 seconds after the display, the second button 104 is automatically selected (that is, the pick-up request is rejected). Has been done. At the lower end of the first button 102, a circular object 1021 that counts down the 10 seconds is displayed. In this way, the driver can reject the request for pick-up by leaving the button 104 for 10 seconds instead of selecting the second button 104.

When the first button 102 of the vehicle pick-up request confirmation screen 100 is selected by the driver and the pick-up request is accepted (YES in step S130), the allocation of the vehicle to the user is confirmed (step S140). Upon confirming the allocation of the vehicle, the server 10 registers the corresponding vehicle ID in the vehicle allocation request information table 413 and changes the vehicle allocation state in the vehicle information table 412 of the corresponding vehicle to "pick-up". On the other hand, when the second button 104 of the pick-up request confirmation screen 100 is selected by the driver and the pick-up request is rejected (NO in step S130), the server 10 selects the vehicle to be assigned again (step S110). In addition, a plurality of vehicles (for example, a plurality of vehicles that can arrive at the boarding position within a predetermined time) are selected as vehicle candidates to be assigned to the user, and a consultation (provisional request) is made to the selected vehicles. You may do it. In this case, among the plurality of vehicles that have been consulted for pick-up, the allocation of the first accepted vehicle is confirmed.

FIG. 10 illustrates a vehicle pick-up waiting screen 503 displayed on the user terminal 32 in response to confirmation of vehicle allocation (acceptance of a vehicle pick-up request by the driver). The pick-up waiting screen 503 has a map display area 52 and an information display area 54, similarly to the top screen 501 and the arranging screen 502. As shown in the figure, the information display area 54 of the pick-up waiting screen 503 displays a guideline for the waiting time at the present time, and also displays information about the assigned vehicle (vehicle image (photograph or figure), and the vehicle. The first button 64, which displays other information (for example, the taxi company name and the vehicle number, etc.) and displays "destination setting", and the second button 65, which displays "message". Has.

The first button 64 is a button for the user to set / change the destination (getting 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 a button for the user to have a chat with the driver of the assigned vehicle. The 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 depending on the confirmation of the vehicle allocation.

FIG. 11 illustrates a pick-up screen 110 displayed on the driver terminal 34 in response to confirmation of vehicle allocation. As shown in the figure, the pick-up 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 whose scale has been adjusted so as to include 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 PO corresponding to the boarding position are arranged on the map. In the map display area 112, the scale of the map (the range of the displayed map) changes (enlarges) as the vehicle approaches the boarding position. Further, in the upper right corner of the map display area 112, a navigation start button 1122 displayed as "navigation" is arranged. When the button 1122 is selected by the driver, a general navigation function with the boarding position as the destination is started.

The first button 114 is a button for the driver to report arrival at the boarding position. The second button 116 is a button for the driver to chat with the user. The 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 position of the driver's vehicle falls within a predetermined range from the boarding position.

On the arrival report screen 120, as shown in the figure, the first button 122 displayed as "arrival at the pick-up place" and the second button 124 displayed as "cancel" are arranged side by side in the vertical direction. When the first button 122 is selected by the driver, the arrival at the pick-up location (boarding 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 through the predetermined message. In addition, the driver can also perform necessary communication from the arrival at the boarding position to the boarding by the user via the text chat described above.

FIG. 13 illustrates a boarding report screen 130 displayed on the driver terminal 34 according to the selection of the first button 122. On the boarding report screen 130, as shown in the figure, the first button 132 displayed as "boarding completed" and the second button 134 displayed as "cancel" are arranged side by side in the vertical direction. When the first button 132 is selected by the driver, the user's boarding is reported to the server 10. Upon receiving the report, the server 10 changes the vehicle allocation status in the vehicle information table 412 of the corresponding vehicle to "rental".

Here, in this example, the user can change the determined boarding position after selecting the first button 61 on the top screen 501 and making a vehicle allocation request. Specifically, the boarding is performed by changing the position of the boarding position designating 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. The position can be changed. For example, the position of the object 521 is changed by a slide operation on the boarding position designation object 521.

FIG. 14 illustrates a pick-up waiting screen 503 when the position of the boarding position designation object 521 on the map is changed. As shown in the figure, the confirmation object 56 for confirming the necessity of changing the boarding position is displayed on the map display area 52 in response to the change in the position of the boarding position designating object 521 on the map. The confirmation object 56 has a first button 561 displayed as "Yes" and a second button 562 displayed as "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 vehicle allocation request information table 413 is updated. If the position of the vehicle heading to the boarding position before the change is within a predetermined distance from the boarding position, the change of the boarding position may be prohibited (disabled). .. Further, an upper limit may be set for the changeable range of the boarding position (distance between the boarding position before the change and the boarding position after the change).

Further, in this example, the boarding position designation object 521 is configured so as not to be arranged in the above-mentioned non-recommended boarding area in the map display area 52. FIG. 15 illustrates a vehicle pick-up waiting screen 503 in a state in which the position change (for example, slide operation) of the boarding position designating object 521 is started. As shown in the figure, in the map display area 52, the area A1 corresponding to the deprecated boarding area is visibly displayed (for example, a semi-transparent specific area) in response to the start of changing the position of the boarding position designating object 521. It is configured to be displayed as an area of color (eg, red). The deprecated boarding area here includes the non-recommended boarding area common to a plurality of vehicles, as well as the non-recommended boarding area of the taxi company of the assigned vehicle. The user can know the existence of the non-recommended boarding area by the area A1. In addition, in the area A1, the reason why it is set as a non-recommended boarding area (for example, "cannot be dispatched because it is around the taxi stand") may be displayed. In addition to the area A1 corresponding to the non-recommended boarding area, the area corresponding to the above-mentioned recommended boarding area is visually displayed (for example, semi-transparent) in response to the start of changing the position of the boarding position designating object 521. (Displayed as an area of a specific color (for example, blue) different from the non-recommended boarding area) may be used to guide the user to another recommended boarding area.

As described above, in this example, the user can make a taxi dispatch request by a simple one-tap operation of selecting the first button 61 of the top screen 501, and then is arranging (waiting for acceptance of the pick-up request). ), And during the waiting period, the boarding position can be changed and the destination (getting off position) can be set.

The case where the vehicle allocation request is made without specifying the conditions has been described above. Next, a case where a vehicle allocation request is made by specifying conditions will be described. FIG. 16 illustrates a condition specification screen 504 displayed on the user terminal 32 according to the selection of the second button 62 on the top screen 501. The condition designation screen 504 has a map display area 52 and an information display area 54, similarly to the top screen 501, the arranging screen 502, and the pick-up waiting screen 503.

A boarding position designation object 521 is arranged in the map display area 52 of the condition designation screen 504. The user can individually specify the boarding position by changing the position of the object 521. Similar to 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 specification screen 504 is not recommended for boarding according to the start of changing the position of the boarding position designating object 521. The area corresponding to the area (here, since it is before allocating the vehicle, 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) can be visually recognized. Displayed, 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 riding area, the area corresponding to the recommended riding area may be visually displayed.

The information display area 54 of the condition specification screen 504 displays a guideline for the waiting time at the present time, a first button 66 for setting a destination, a second button 67 for selecting a payment method, and a vehicle type. It has a third button 68 for designating the button and a fourth button 69 for displaying "request".

When the first button 66 is selected by the user, a screen for setting the destination (getting off position) is displayed, and the user can set the destination in advance via the screen. 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, and the user can set the payment method in advance via the screen. 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 a vehicle type or the like of the vehicle to be arranged is displayed, and the user can set the vehicle type or the like via the screen. In addition to the vehicle type, it is also possible to specify whether or not the taxi is a UD taxi and whether or not to allow admission to the facility X on the screen.

The fourth button 69 is a button for the user to make a vehicle allocation request. FIG. 17 is a flow chart illustrating a process executed by the vehicle allocation management server 10 in response to the user's selection of the fourth button 69. First, as shown in the figure, the server 10 sets the user's boarding position (pick-up position) based on the user's designation (step S200). Specifically, the position on the map of the boarding position designating object 521 in the map display area 52 of the condition designation screen 504 is set as the boarding position of the user.

After setting the boarding position of the user in this way, the server 10 then selects the vehicle to be assigned to the user based on the boarding position of the user, the designation by the user (vehicle type, etc.), and the vehicle information of each vehicle (step). S210). Basically, a vehicle that is the closest empty vehicle to the user's boarding position and that matches the vehicle type or the like specified by the user is assigned to the user. Further, as in the case of making a vehicle allocation request without specifying the conditions, when the user's boarding position is within the premises of the facility X, the vehicles to be allocated are limited to the vehicles having the admission permission of the facility X. When the user's boarding position is included in the non-recommended boarding area of a specific taxi company, the vehicles to be allocated are limited to vehicles other than the vehicle of the specific taxi company.

In addition, when the destination (getting off position) is set by the user and the destination is within the premises of facility X, the allocation target is the same as when the boarding position of the user is within the premises of facility X. Vehicles are limited to vehicles that have an admission to the facility X.

Further, as described above, the target vehicle (for example, a specific vehicle type, a UD taxi vehicle, a vehicle having an admission permission for facility X, or a vehicle other than a vehicle of a specific taxi company) is the user's boarding position. The user may be managed as a waiting state for dispatch (automatically or through confirmation by the user) when the vehicle is not within a predetermined distance from the vehicle. Further, when there is no vehicle having an admission permission for the facility X within a predetermined distance from the user's boarding position, the user's boarding position is set outside the facility X (automatically or the user's confirmation is confirmed. It may be modified (via) to assign vehicles that do not have admission to Facility X.

Then, the server 10 requests the selected vehicle to pick up the vehicle (step S220). Subsequent processing is the same as the flow diagram illustrated in FIG. 7 executed in response to the selection of the first button 61 on the top screen 501, and when the pick-up is accepted by the corresponding driver, the vehicle is assigned to the user. Is confirmed (step S240), while the pick-up request is rejected by the corresponding driver (NO in step S230), the server 10 again selects the vehicle to be assigned (step S210). As described above, in this example, the user can also individually specify the conditions and make a vehicle allocation request by selecting the second button 62 on the top screen 501.

In the above example, the deprecated boarding area to be avoided when setting the boarding position is registered in the road map data 415, but similarly, the deprecated boarding area to be avoided when setting the boarding position is registered. Is also good. The non-recommended disembarkation area includes a non-recommended disembarkation area common to a plurality of vehicles set by the operator of the vehicle allocation management service and a non-recommended disembarkation area for each taxi company set by each taxi company. Then, in the case of making a vehicle allocation request without specifying the conditions, when setting / changing the destination via the first button 64 of the pick-up waiting screen 503, the deprecated boarding area common to a plurality of vehicles and the non-recommended boarding area common to a plurality of vehicles are used. The deprecated boarding area of the taxi company of the assigned vehicle is avoided (controlled so that no destination can be set within that area). Further, when the vehicle allocation request is made by designating the conditions, when the destination is set via the first button 66 of the condition designation screen 504, the non-recommended disembarkation area common to a plurality of vehicles is avoided and set. If the destination is within the non-recommended disembarkation area of a specific taxi company, in step S210, the vehicle to be allocated is limited to vehicles other than the vehicle of the specific taxi company.

In the above example, when the set boarding / alighting position is a specific facility such as a hospital or a long-term care facility, a UD taxi vehicle may be assigned. In this case, the facility to which the UD taxi vehicle should be assigned when set as the boarding / alighting position can be registered in the road map data 415.

The vehicle allocation management server 10 according to the present embodiment described above sets the boarding position of the user, and grants admission to a vehicle having a predetermined attribute value specified based on the set boarding position (for example, admission to a specific facility). Vehicles owned, vehicles other than vehicles of a specific taxi company, vehicles of UD taxi, etc.) are assigned to users, so it is possible to assign vehicles suitable for the boarding position, and specify vehicle conditions when requesting a vehicle allocation. The increase in the burden on the user is suppressed. That is, the vehicle allocation management server 10 in the present embodiment improves the convenience of the user when requesting vehicle allocation.

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

Even if it is explained that the processes and procedures described herein are performed by a single device, software, component, module, such processes or procedures are performed by multiple devices, multiple software, multiple devices. Can be executed by a component of, and / or multiple modules. The software and hardware elements described herein can also be achieved by integrating them into fewer components or by breaking them down into more components.

In the present specification, when the components of the invention are described as either one or more, or even if they are described without limitation to either the singular or the plurality, they should be understood separately in the context. Except for, the component may be either 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 department 100 Vehicle pick-up request confirmation screen 110 Vehicle pick-up screen 120 Arrival report screen 130 Boarding report screen 501 Top screen 502 Arranging screen 503 Pick-up waiting screen 504 Condition specification screen

Claims (12)

It is a system for managing the dispatch of vehicles.
A storage device for storing at least vehicle information and road map data of each of a plurality of vehicles, and one or more computer processors.
The one or more computer processors depend on the execution of readable instructions.
The process of accepting a vehicle dispatch request from the user
The process of setting the boarding position of the user and
Before identifying the entrance conditions to the riding position based at least on the Keno vehicle position and the road map data, based at least on said vehicle information and specified the admission condition, the entrance from the plurality of vehicles The process of selecting a vehicle that satisfies the conditions as the vehicle to be assigned to the user, and
It executes a process of requesting a Geisha Previous Kino vehicle position relative to the selected vehicle,
System. The road map data includes information about a specific restricted area where the vehicle can not be admitted no admission with a vehicle can entry having entry field authorization,
The vehicle information includes the presence or absence of admission to the specific restricted area.
Process of selecting the vehicle, if the previous keno vehicle position is included in the specific restricted area, the vehicle having admission for the specific restricted area, selecting a vehicle which satisfies the admission condition Including,
The system of claim 1. Process of selecting the vehicle, before keno vehicle position is included in the specific restricted area, and, if it can not select a vehicle having admission for the specific restricted area, the specific pre Keno vehicle position Including suggesting to the user a change to the outside of the restricted area of
The system of claim 2. The one or more computer processors further execute a process of setting the disembarkation position of the user.
The process of selecting the vehicle, before identifying the entrance conditions to the getting-off position at least based on the Kifu vehicle position and the road map data, based at least on said vehicle information and specified the admission condition, the Including selecting a vehicle satisfying the entrance conditions from a plurality of vehicles as a vehicle to be assigned to the user.
The system according to any one of claims 1 to 3. The road map data includes information about a specific restricted area where the vehicle can not be admitted no admission with a vehicle can entry having entry field authorization,
The vehicle information includes the presence or absence of admission to the specific restricted area.
Process of selecting the vehicle, if the previous Kifu vehicle position is included in the specific restricted area, the vehicle having admission for the specific restricted area, selecting a vehicle which satisfies the admission condition Including,
The system of claim 4. Process of selecting the vehicle, before Kifu vehicle position is included in the specific restricted area, and, if it can not select a vehicle having admission for the specific restricted area, the specific pre Kifu vehicle position Including suggesting to the user a change to the outside of the restricted area of
The system of claim 5. The road map data includes information about deprecated boarding area not recommended as ride vehicle position,
The process of setting the riding position includes setting a pre Keno vehicle position so as to be outside of the deprecated boarding area,
The system according to any one of claims 1 to 6. At least some of the vehicles are associated with any of the taxi operators.
The road map data includes information on a deprecated boarding area for each taxi operator and a non-recommended boarding area common to the plurality of vehicles.
Process of selecting the vehicle, if the previous keno vehicle position is included in deprecated boarding area of a particular taxi operators assign vehicles other than the vehicle associated with the particular taxi company to the user Including selecting as a vehicle,
The system of claim 7. The one or more computer processors further execute a process of setting the disembarkation position of the user.
The road map data includes information about deprecated alighting areas not recommended as a descending vehicle position,
The process of setting the disembarkation position includes setting the disembarkation position of the user so as to be outside the deprecated disembarkation area.
The system according to any one of claims 1 to 8. At least some of the vehicles are associated with any of the taxi operators.
The road map data includes information on a deprecated disembarkation area for each taxi operator and a non-recommended disembarkation area common to the plurality of vehicles.
In the process of selecting a vehicle, when the set disembarkation position is included in the non-recommended disembarkation area of a specific taxi operator, the user uses a vehicle associated with a taxi operator other than the specific taxi operator. Including selecting as a vehicle to assign to,
The system of claim 9. A method for managing vehicle allocation, executed by one or more computers accessible to a storage device that stores at least vehicle information and road map data for each of a plurality of vehicles.
Steps to accept user dispatch requests and
The step of setting the boarding position of the user and
Before identifying the entrance conditions to the riding position based at least on the Keno vehicle position and the road map data, based at least on said vehicle information and specified the admission condition, the entrance from the plurality of vehicles A step of selecting a vehicle that satisfies the conditions as a vehicle to be assigned to the user, and
A step of requesting a Geisha to riding position the setting for the selected vehicle, Ru provided with,
METHODS. A program for managing vehicle allocation,
Depending on the execution on one or more computers that have access to a storage device that stores at least the vehicle information and road map data of each of the plurality of vehicles, the one or more computers.
The process of accepting a vehicle dispatch request from the user
The process of setting the boarding position of the user and
Before identifying the entrance conditions to the riding position based at least on the Keno vehicle position and the road map data, based at least on said vehicle information and specified the admission condition, the entrance from the plurality of vehicles The process of selecting a vehicle that satisfies the conditions as the vehicle to be assigned to the user, and
A process of requesting a Geisha to have the setting for the selected vehicle riding position, Ru is the execution,
Program.

Images