Information processing system, information processing method, and information processing program

Abstract

To provide an appropriate operation history.SOLUTION: A vehicle terminal performs: a process for accepting required operations to be performed by a driver during a single service period from boarding to alighting by the user, the required operations including at least a first operation required at the time of boarding by the user and a second operation required at the time of alighting by the user; a process for transmitting to a server required information corresponding to the required operations, the required information including first information corresponding to the first operation and second information corresponding to the second operation; a process for allowing input of a travel distance of the vehicle at one or both of the user's boarding and alighting; and a process for transmitting to the server travel distance information that indicates the input travel distance. The server performs a process for generating a predetermined operation history based on the required information and the travel distance information received from the vehicle terminal.SELECTED DRAWING: Figure 10

Description

[Technical Field]

[0001] The present invention relates to an information processing system, an information processing method, and an information processing program. [Background technology]

[0002] There are known technologies for dispatching a taxi in response to a user's request for dispatching a taxi. For example, Patent Document 1 discloses a technology for estimating the arrival times of the user and the taxi at the user's desired boarding location, matching the estimated results, and dispatching a taxi so as to minimize the difference between the estimated results. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2023-027694 Summary of the Invention [Problem to be solved by the invention]

[0004] Recently, the shortage of taxi drivers has become a serious problem in some regions. As a result, there are areas where the supply of taxis is insufficient to meet the demand for taxi dispatch. As a result, the introduction of ride-sharing (Japanese-style ride-sharing), in which ordinary drivers use their own cars to transport users for a fee, is progressing.

[0005] When a taxi driver operates a terminal installed in the vehicle, various information is sent to a server. The server creates a business history based on the received information, allowing the driver to improve work efficiency by checking the business history and considering future measures. However, in the case of ride-sharing, it is difficult to output the same information as a taxi, making it difficult to create an appropriate business history.

[0006] In view of the above, an object of the present invention is to provide an information processing system, an information processing method, and an information processing program that are capable of creating an appropriate business history. [Means for solving the problem]

[0007] In order to solve the above problem, the information processing system includes: a vehicle terminal operable by a driver; a server that receives information from the vehicle terminal; Equipped with The vehicle terminal A process for accepting necessary operations required of the driver during one driving period from when the user gets on board to when the user gets off the vehicle, including at least a first operation required when the user gets on board and a second operation required when the user gets off the vehicle; a process of transmitting necessary information corresponding to the required operation, including first information corresponding to the first operation and second information corresponding to the second operation, to a server; A process for allowing a user to input a mileage of the vehicle at either one or both of the time of getting on and off the vehicle; a process of transmitting mileage information indicating the input mileage to the server; and The server A process of generating a predetermined business history based on the necessary information and the mileage information received from the vehicle terminal; Carry out the following.

[0008] The vehicle terminal A process of starting the training mode in response to an operation input from the driver; A process of setting a boarding location and a disembarking location in the training mode; a process for enabling acceptance of some or all of the required operations during the training mode; and During the training mode, some or all of the necessary information corresponding to the required operation may not be transmitted to the server.

[0009] The vehicle terminal A process of starting the training mode in response to an operation input from the driver; A process of setting a boarding location and a disembarking location in the training mode; a process for enabling acceptance of some or all of the required operations during the training mode; a process of transmitting a part or all of the necessary information corresponding to the necessary operation to the server during the training mode; and The server The sales history may be generated excluding the necessary information transmitted during the training mode.

[0010] In order to solve the above problem, an information processing method includes: An information processing method performed by a vehicle terminal operable by a driver and a server that receives information from the vehicle terminal, The vehicle terminal A process for accepting necessary operations required of the driver during one driving period from when the user gets on board to when the user gets off the vehicle, including at least a first operation required when the user gets on board and a second operation required when the user gets off the vehicle; a process of transmitting necessary information corresponding to the required operation, including first information corresponding to the first operation and second information corresponding to the second operation, to a server; A process for allowing a user to input a mileage of the vehicle at either one or both of the time of getting on and off the vehicle; a process of transmitting mileage information indicating the input mileage to the server; and The server A process of generating a predetermined business history based on the necessary information and the mileage information received from the vehicle terminal; Carry out the following.

[0011] In order to solve the above problem, an information processing program On the vehicle terminal that the driver can operate, A process for accepting necessary operations required of the driver during one driving period from when the user gets on board to when the user gets off the vehicle, including at least a first operation required when the user gets on board and a second operation required when the user gets off the vehicle; a process of transmitting necessary information corresponding to the required operation, including first information corresponding to the first operation and second information corresponding to the second operation, to a server; A process for allowing a user to input a mileage of the vehicle at either one or both of the time of getting on and off the vehicle; a process of transmitting mileage information indicating the input mileage to the server; and A server that receives information from the vehicle terminal, A process of generating a predetermined business history based on the necessary information and the mileage information received from the vehicle terminal; To carry out the following. [Effects of the Invention]

[0012] According to the present invention, it is possible to create an appropriate business history. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram for explaining an outline of a vehicle dispatch management system. [Figure 2] FIG. 2 is a block diagram illustrating the configuration of a user terminal. [Figure 3] FIG. 3 is a block diagram illustrating the configuration of the taxi terminal. [Figure 4] FIG. 4 is a block diagram illustrating the configuration of the NRS terminal. [Figure 5] FIG. 5 is a block diagram illustrating the configuration of the business server. [Figure 6] FIG. 6 is a block diagram illustrating the configuration of the vehicle dispatch management server. [Figure 7]FIG. 7 is a sequence diagram showing the flow of processing in a vehicle allocation management method by the vehicle allocation management system. [Figure 8] FIG. 8 is an explanatory diagram for explaining the processing of the vehicle extraction unit. [Figure 9] FIG. 9 is an explanatory diagram showing the results of matching by the matching unit. [Figure 10] FIG. 1 is a sequence diagram showing a flow of a vehicle transporting a user in a vehicle dispatch management system. [Figure 11] Fig. 11A is a first explanatory diagram for explaining the operation of the user terminal control unit, and Fig. 11B is a second explanatory diagram for explaining the operation of the user terminal control unit. [Figure 12] Fig. 12A is a diagram illustrating an example of a top screen displayed on the display device of the NRS terminal, and Fig. 12B is a diagram illustrating an example of a map screen displayed on the display device of the NRS terminal. [Figure 13] Fig. 13A is a diagram illustrating an example of a menu screen displayed on the display device of the NRS terminal, and Fig. 13B is a diagram illustrating an example of a pause screen displayed on the display device of the NRS terminal. [Figure 14] Fig. 14A is a first explanatory diagram for explaining the operation of the vehicle terminal control unit, and Fig. 14B is a second explanatory diagram for explaining the operation of the vehicle terminal control unit. [Figure 15] FIG. 15 is a diagram illustrating an example of a map screen displayed on the display device of the NRS terminal upon arrival. [Figure 16] Fig. 16A is a diagram illustrating an example of a map screen after notification of the arrival of a vehicle, and Fig. 16B is a diagram illustrating an example of an odometer input screen when getting on the vehicle. [Figure 17] Fig. 17A is a third explanatory diagram for explaining the operation of the vehicle terminal control unit, and Fig. 17B is a fourth explanatory diagram for explaining the operation of the vehicle terminal control unit. [Figure 18] FIG. 18 is a diagram illustrating an example of the odometer input screen when getting off the vehicle. [Figure 19]Fig. 19A is a first diagram illustrating an example of a screen during training mode, and Fig. 19B is a second diagram illustrating an example of a screen during training mode. [Figure 20] FIG. 20 is a third diagram illustrating an example of a screen in the training mode. [Figure 21] FIG. 21 is a diagram illustrating an example of a training mode execution process in an NRS terminal. [Figure 22] FIG. 22 is a diagram illustrating an example of server processing in the vehicle dispatch management server. [Figure 23] FIG. 23 is a sequence diagram showing the flow of processing in the training mode. [Figure 24] FIG. 24 is a diagram illustrating an example of the business history screen. [Figure 25] FIG. 25 is a diagram illustrating an example of business history information generated by the vehicle dispatch management server. DETAILED DESCRIPTION OF THE INVENTION

[0014] Preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Dimensions, materials, and other specific values ​​shown in the embodiments are merely examples for facilitating understanding of the invention and, unless otherwise specified, do not limit the present invention. In this specification and drawings, elements having substantially the same functions and configurations are designated by the same reference numerals to avoid redundant explanation, and elements not directly related to the present invention are not shown.

[0015] (Vehicle Dispatch Management System 1) 1 is a block diagram for explaining an overview of a vehicle dispatch management system 1. The vehicle dispatch management system 1 includes a plurality of user terminals 20, a plurality of taxi terminals 30, a plurality of taxi vehicles 32, a plurality of NRS terminals 40, a plurality of NRS vehicles 42, one or more business operator servers 50, and one or more vehicle dispatch management servers 60. In the vehicle dispatch management system 1, NRS vehicles 42 are included in addition to taxi vehicles 32 as commercial vehicles that serve as transportation means for users 2. Here, NRS is an abbreviation for Nippon-style Ride Share, and refers to a service in which ordinary drivers transport users 2 for a fee using their own cars or the like.

[0016] The user terminal 20 is an electronic device owned by the user 2. The user 2 is a passenger in a commercial vehicle (such as a taxi vehicle 32 or an NRS vehicle 42). Examples of the user terminal 20 include a smartphone, a personal computer, and a tablet PC. In the vehicle dispatch management system 1, there are multiple combinations of users 2 and user terminals 20. Note that the user 2 in this embodiment is not limited to one person, and may refer to multiple people who can ride in one taxi vehicle 32.

[0017] FIG. 2 is a block diagram illustrating the configuration of the user terminal 20. The user terminal 20 includes a communication device 120, a processing device 122, a display device 124, an input device 126, and a storage device 128. The communication device 120 is communicatively connected to an external device, such as a vehicle dispatch management server 60, via a base station 5 and a network 6. The processing device 122 includes a semiconductor integrated circuit including a processor such as a central processing unit (CPU), a read-only memory (ROM) storing programs, and a random access memory (RAM) used as a work area. A user application for the vehicle dispatch management system 1 is installed on the user terminal 20. The processing device 122 runs the program to control the user application and function as a vehicle dispatch request unit 180 that supports the user 2 in inputting a vehicle dispatch request. The display device 124 includes a liquid crystal display, an organic electroluminescence (EL) display, or the like, and displays various information, such as an image of the user application used to make a vehicle dispatch request. The input device 126 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc. superimposed on the display device 124, and accepts input from the user 2, such as information for requesting a vehicle dispatch. The storage device 128 is configured with storage means such as an HDD (Hard Disk Drive), SD memory, SSD (Solid State Drive), etc.

[0018] The taxi terminal 30 is an electronic device loaned to a taxi driver 3 of a taxi vehicle 32, or an electronic device owned by the taxi driver 3. The taxi terminal 30 is associated with the taxi vehicle 32. Examples of the taxi terminal 30 include a smartphone, a personal computer, and a tablet PC. The taxi terminal 30 is an example of a vehicle terminal. The taxi terminal 30 may be an electronic device installed in the taxi vehicle 32, or an electronic device that can be brought into the taxi vehicle 32 from outside. In either case, the taxi terminal 30 broadly includes electronic devices that can be operated by the driver.

[0019] FIG. 3 is a block diagram illustrating the configuration of the taxi terminal 30. The taxi terminal 30 includes a communication device 130, a processing device 132, a display device 134, an input device 136, and a storage device 138. The communication device 130 is communicatively connected to external devices, such as the operator server 50 and the dispatch management server 60, via a base station 5 and a network 6. The processing device 132 includes a semiconductor integrated circuit including a processor (CPU), a ROM storing programs and the like, and a RAM used as a work area. A vehicle application for the dispatch management system 1 is installed in the taxi terminal 30. The processing device 132 controls the vehicle application by running the program and functions as a dispatch response unit 182 that supports the taxi driver 3 in inputting responses to dispatch requests. The display device 134 includes a liquid crystal display and an organic electroluminescence (EL) display, and displays various information, such as a notification that the taxi driver's own taxi 32 has been the subject of a dispatch request (dispatch target notification) and information related to the dispatch request (boarding location, user information about the user 2). Hereinafter, the target of a dispatch request may be referred to as the "dispatch target," and the vehicle that has been dispatched may be referred to as the "dispatch target vehicle." The input device 136 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc. superimposed on the display device 134, and receives input from the taxi driver 3, such as acceptance of the dispatch request. The storage device 138 is composed of storage means such as an HDD, SD memory, or SSD. The taxi terminal 30 can acquire its own position on a map through location identification means such as a GPS (Global Positioning System).

[0020] The taxi driver 3 is a driver who holds a Class 2 driver's license for a standard vehicle and belongs to a taxi business (general passenger automobile transportation business). The taxi vehicle 32 is, for example, a vehicle that belongs to a taxi business and can transport the user 2 as a taxi business for a fee. In the vehicle dispatch management system 1, there are multiple combinations of taxi drivers 3, taxi vehicles 32, and taxi terminals 30. Note that in this embodiment, an example of a four-wheeled taxi (hire car) is given as the taxi vehicle 32 to be dispatched, but the taxi vehicle 32 is not limited to this example, and may include, for example, a motorcycle (motorcycle taxi) or the like as long as it is a vehicle capable of transporting people.

[0021] The NRS terminal 40 is an electronic device owned by the NRS driver 4, and can be placed in the NRS vehicle (second vehicle) 42. Examples of the NRS terminal 40 include a smartphone, a personal computer, and a tablet PC. The NRS driver 4, for example, brings the NRS terminal 40 that he or she owns into the NRS vehicle 42, which is his or her own personal car, and drives the NRS vehicle 42. This makes it possible to use the NRS vehicle 42 as a commercial vehicle in place of the taxi vehicle 32. The NRS terminal 40 is an example of a vehicle terminal.

[0022] FIG. 4 is a block diagram illustrating the configuration of the NRS terminal 40. The NRS terminal 40 includes a communication device 140, a processing device 142, a display device 144, an input device 146, and a storage device 148. The communication device 140 is communicatively connected to external devices, such as the operator server 50 and the vehicle dispatch management server 60, via the base station 5 and the network 6. The processing device 142 includes a semiconductor integrated circuit including a processor (CPU), a ROM storing programs, and a RAM used as a work area. A vehicle application for the vehicle dispatch management system 1 is installed in the NRS terminal 40. The processing device 142 controls the vehicle application by running the program and functions as a dispatch response unit 184 that supports the NRS driver 4 in inputting responses to vehicle dispatch requests. The display device 144 includes a liquid crystal display and an organic electroluminescence (EL) display, and displays various information, such as a notification that the NRS vehicle 42 has been selected for dispatch (dispatch target notification) and information related to the dispatch request (boarding location, disembarking location, and user information related to the user 2). The input device 146 includes a touch panel, switches, buttons, keys, a microphone for voice input, etc. superimposed on the display device 144, and receives input from the NRS driver 4, such as acceptance of a vehicle dispatch request. The storage device 148 is composed of storage means such as an HDD, SD memory, or SSD. The NRS terminal 40 can obtain its own position on a map through location identification means such as GPS.

[0023] The NRS driver 4 is a driver who holds a Class 1 driver's license for a standard vehicle and is involved in a ride-sharing business (a private vehicle passenger transportation business for a fee). However, in this embodiment, an example will be described in which a taxi business also manages a ride-sharing business based on Article 78, Paragraph 3 of the Road Transportation Act. Therefore, the NRS driver 4 can be said to be a driver who is involved in a taxi business. The NRS driver 4 differs from the taxi driver 3 in that he or she does not hold a Class 2 driver's license for a standard vehicle or may have poor driver qualifications, driving skills, and knowledge. The NRS vehicle 42 is, for example, a vehicle driven by the NRS driver 4 and can transport users 2 for a fee as part of a ride-sharing business. The NRS vehicle 42 can be a private car or an idle taxi vehicle 32. The vehicle dispatch management system 1 has multiple combinations of NRS drivers 4, NRS vehicles 42, and NRS terminals 40. Note that the NRS driver 4 cannot engage in so-called patrol business, which is to search for users 2 who want to ride while driving the taxi vehicle 32, as the taxi driver 3 does. However, in the case of paid passenger transportation by private car based on Article 78, Paragraph 3 of the Road Transportation Act, NRS Driver 4 may charge User 2 a fee (fare) equivalent to that charged for general passenger automobile transportation business as compensation for transporting User 2.

[0024] Such taxi vehicles 32 and NRS vehicles 42 have designated operating areas in which they can operate. A taxi vehicle 32 can operate in the operating area where its taxi business office is located. For example, if the operating area is within Tokyo's special wards, the taxi vehicle 32 can operate in Tokyo's 23 wards, Musashino City, and Mitaka City. The operating area of ​​such a taxi vehicle 32 may be referred to as a transportation area.

[0025] The operating area of ​​the NRS vehicle 42 is included in the operating area of ​​the taxi vehicle 32 and is often smaller than that of the taxi vehicle 32. Furthermore, while the operating area of ​​the taxi vehicle 32 is limited in geographical area but not in time, the operating area of ​​the NRS vehicle 42 is not only limited in geographical area but also in time, such as only during periods (including seasons) when the supply of taxi vehicles 32 is insufficient to meet the demand. Thus, a taxi shortage in an area, period, or time zone where there is a shortage of taxi vehicles 32 is considered an "unavoidable case for the public welfare" under Article 78, Paragraph 3 of the Road Transportation Act, and a ride-sharing business is permitted. The operating area of ​​the NRS vehicle 42, like the operating area of ​​the taxi vehicle 32, is managed by a taxi operator, and is subject to the same regulations as the operating area of ​​the taxi vehicle 32. While this embodiment describes an example in which the operating area of ​​the NRS vehicle 42 is limited in both geographical area and time zone, the present invention is not limited to such an example, and there are also cases in which the operating area is limited only in geographical area and not in time zone.

[0026] Hereinafter, for convenience of explanation, when there is no need to distinguish between taxi vehicle 32 and NRS vehicle 42, automobiles that transport user 2 for a fee, including taxi vehicle 32 and NRS vehicle 42, may be collectively referred to simply as "vehicles." Furthermore, when there is no need to distinguish between taxi driver 3 and NRS driver 4, drivers, including taxi driver 3 and NRS driver 4, may be collectively referred to simply as "drivers." Furthermore, when there is no need to distinguish between taxi terminal 30 and NRS terminal 40, devices possessed by drivers, including taxi terminal 30 and NRS terminal 40, may be collectively referred to simply as "vehicle terminals," display devices of vehicle terminals, including display device 134 and display device 144, may be collectively referred to simply as "vehicle display devices," input devices of vehicle terminals, including input device 136 and input device 146, may be collectively referred to simply as "vehicle input devices," and vehicle dispatch response units of vehicle terminals, including vehicle dispatch response unit 182 and vehicle dispatch response unit 184, may be collectively referred to simply as "vehicle dispatch response units."

[0027] FIG. 5 is a block diagram illustrating the configuration of the business operator server 50. The business operator server 50 is an information processing device (computer) owned by a business operator operating a taxi business. The business operator server 50 manages taxi vehicles 32 driven by taxi drivers 3 belonging to a taxi business and NRS vehicles 42 driven by NRS drivers 4. The business operator server 50 includes a communication device 150, a processing device 152, a display device 154, an input device 156, and a storage device 158. The communication device 150 is communicatively connected to external devices, such as taxi terminals 30, NRS terminals 40, and a vehicle dispatch management server 60, via a network 6. The processing device 152 includes a semiconductor integrated circuit including a processor (CPU), a ROM storing programs, and a RAM used as a work area. By running a program, the processing device 152 functions as a vehicle management unit 186 that manages vehicles belonging to the taxi business. The display device 154 includes a liquid crystal display (LCD) or an organic electroluminescence (EL) display, and displays various information, such as driver or vehicle information, obtained directly from the vehicles or via the vehicle dispatch management server 60. The input device 156 includes a keyboard, a touch panel superimposed on the display device 154, a microphone for voice input, etc., and receives input from an operator at the business. For example, the operator can talk to the driver or check images of the inside and outside of the vehicle, including an image of the driver, through the business server 50. The storage device 158 is composed of storage means such as an HDD, SD memory, or SSD.

[0028] FIG. 6 is a block diagram illustrating the configuration of the vehicle dispatch management server 60. The vehicle dispatch management server (vehicle dispatch management device) 60 is an information processing device (computer) that manages vehicles belonging to a taxi company based on a contract between the vehicle dispatch management company and the taxi company. The vehicle dispatch management server 60 is an example of a vehicle dispatch management device with server functions and is operated by the vehicle dispatch management company. The vehicle dispatch management server 60 can dispatch a vehicle to a user 2 in response to a vehicle dispatch request from a user terminal 20. The vehicle dispatch management server 60 includes a communication device 160, a processing device 162, and a storage device 164. The communication device 160 is communicatively connected to external devices, such as the user terminal 20, the taxi terminal 30, the NRS terminal 40, and the company server 50, via the network 6. The processing device 162 has a semiconductor integrated circuit including a processor (CPU), a ROM storing programs and the like, a RAM used as a work area, and the like. By running programs, the processing device 162 functions as functional units such as a user terminal control unit 170, a vehicle dispatch unit 172, and a vehicle terminal control unit 174. The user terminal control unit 170 controls the user application installed in the user terminal 20. The vehicle allocation unit 172 allocates a vehicle in response to a vehicle allocation request. The vehicle terminal control unit 174 controls the vehicle application installed in the vehicle terminal. The storage device 164 is composed of storage means such as an HDD, SD memory, or SSD, and stores information about the user 2 and the vehicle.

[0029] In the vehicle dispatch management system 1, when allocating a vehicle in response to a vehicle dispatch request (i.e., when dispatching a vehicle), for example, a plurality of vehicle dispatch requests are matched with a plurality of vehicles, thereby allocating one vehicle to a vehicle dispatch request from one user 2. Here, matching refers to a process of exclusively associating an arbitrary vehicle with an arbitrary vehicle in a state where a plurality of vehicle dispatch requests and a plurality of vehicles exist. In the following, an example of allocating one vehicle to one vehicle dispatch request will be described, but in a case where multiple users 2 are allowed to ride in one vehicle, so-called carpooling, a single vehicle may be allocated to multiple vehicle dispatch requests from multiple users 2.

[0030] (Vehicle allocation management method) FIG. 7 is a sequence diagram showing the processing flow of the vehicle dispatch management method by the vehicle dispatch management system 1. The vehicle dispatch management system 1 extracts one or more vehicles that can be dispatched from a plurality of vehicles for each dispatch request, and identifies one vehicle to be dispatched through matching. The vehicle dispatch management system 1 then asks the driver of the vehicle that has been selected as the dispatch target vehicle to dispatch the vehicle, and when the driver accepts the dispatch inquiry, the dispatch is confirmed. Each process in the vehicle dispatch management method will be described in detail below.

[0031] (Vehicle dispatch request processing S1) When user 2 wishes to ride in a vehicle, user 2 makes a vehicle dispatch request through user terminal 20. Specifically, vehicle dispatch request unit 180 of user terminal 20 launches a user application for making a vehicle dispatch request. The user application displays a map of a predetermined range including the current location of user terminal 20, and displays vehicles (e.g., taxi vehicles 32 and NRS vehicles 42) located near user terminal 20. Vehicle dispatch request unit 180 accepts user 2's vehicle dispatch request through input device 126. At this time, user 2 can set setting items for the vehicle to be boarded. Vehicle dispatch request unit 180 adds information related to the setting items set by user 2 and transmits the vehicle dispatch request to vehicle dispatch management server 60.

[0032] In addition to the initial setting of desired dispatch, the setting items include, for example, boarding location, disembarking location, payment information, dispatch category, taxi company, vehicle attributes, toll road information, etc.

[0033] The boarding location indicates the location on the map where User 2 wishes to board the vehicle. User 2 can set User 2's current location as the boarding location, or can set a desired location different from User 2's current location as the boarding location. The disembarking location indicates the location on the map where User 2 wishes to disembark. When User 2 sets the boarding location and disembarking location among the setting items, the fare calculated based on the set time, boarding location, and disembarking location is displayed on display device 124. In this way, User 2 can know in advance the fare that will be paid by boarding the vehicle.

[0034] When user 2 limits the vehicle dispatch target to taxi vehicles 32 only, the drop-off location is not required input information but is optional information that can be input. On the other hand, when user 2 includes NRS vehicles 42 in the vehicle dispatch target, the drop-off location is required input information. This is because ride-sharing services based on Article 78, Paragraph 3 of the Road Transportation Act require that the fare be determined in advance as a vehicle dispatch requirement (a requirement for dispatching an NRS vehicle 42). Therefore, when an NRS vehicle 42 is included in the vehicle dispatch target, user 2 must input the drop-off location in addition to the pick-up location in order to calculate the fare in advance. Payment information is information related to the payment of fees associated with vehicle use (e.g., fares and other additional fees). Note that when an NRS vehicle 42 is included in the vehicle dispatch target, in addition to inputting the drop-off location, information related to cashless automatic payment by credit card or the like (e.g., credit card number) is required as payment information. This is because ride-sharing services based on Article 78, Paragraph 3 of the Road Transportation Act require that a vehicle dispatch request be made through a user application and that cashless automatic payment be made as a vehicle dispatch requirement. In this way, the NRS vehicle 42 differs from the taxi vehicle 32 in that it requires input of information regarding the drop-off location and automatic payment as a requirement for dispatchability.

[0035] The dispatch category indicates the category of the vehicle to be dispatched. For example, as described above, taxi drivers 3 often hold Class 2 driver's licenses for standard vehicles and have high driver qualifications, driving skills, knowledge, etc. On the other hand, NRS drivers 4 vary in their driver qualifications, driving skills, knowledge, etc. Furthermore, even drivers who hold Class 2 driver's licenses for standard vehicles are not regularly employed as taxi drivers 3, and there are specific drivers who, for example, rent vehicles from taxi companies to transport users 2. These specific drivers often vary in their driver qualifications, driving skills, knowledge, etc. Note that when dispatching a specific vehicle driven by a specific driver, user 2 must also enter information about the drop-off location and automatic payment, just as with the NRS vehicle 42. Herein, vehicles with different dispatch requirements than taxi vehicle 32, including NRS vehicles 42 and specific vehicles, may be simply referred to as "required vehicles." Because driver qualifications, etc., vary depending on the vehicle, some users 2 may request a taxi vehicle 32 driven by taxi driver 3. In this case, user 2 selects "only taxi vehicles 32" as the dispatch category. On the other hand, if the dispatch target is limited to taxi vehicles 32, user 2 will miss the opportunity to ride in a vehicle with requirements, even in a situation where a vehicle with requirements can be dispatched quickly. Therefore, user 2 may not limit the dispatch target to taxi vehicles 32, but may prefer taxi vehicles 32 and vehicles with requirements so that he or she can board a vehicle quickly. In this case, user 2 should select "taxi vehicles 32 and vehicles with requirements" as the dispatch category.

[0036] Here, a dispatch mode in which a taxi vehicle 32 is assigned to a dispatch request but a vehicle with requirements is not assigned is referred to as a first dispatch mode, and a dispatch mode in which either a taxi vehicle 32 or a vehicle with requirements is assigned to a dispatch request is referred to as a second dispatch mode. User 2 can transition from the first dispatch mode to the second dispatch mode by inputting information about the boarding location, the drop-off location, and automatic payment through the user terminal 20. Also, as described above, user 2 can select "taxi vehicle 32 only" or "taxi vehicle 32 and vehicle with requirements" as the dispatch category. Therefore, even if information about the drop-off location and automatic payment has been input, if user 2 selects "taxi vehicle 32 only" as the dispatch category, the mode transitions from the second dispatch mode to the first dispatch mode. User 2 can set the purpose of using the vehicle (e.g., use for business) or set the drop-off location to be directly communicated to the driver without having to input it in advance. In this case, even if the user does not specify and input a vehicle dispatch category, only the taxi vehicle 32 (first vehicle dispatch mode) is automatically targeted for dispatch.

[0037] In this embodiment, an example will be described in which there are a first dispatch mode and a second dispatch mode as the dispatch mode. However, the present invention is not limited to this example, and if there are other circumstances, such as a cheaper fare to ride in a vehicle with special requirements than in a taxi vehicle 32, a third dispatch mode may be provided as the dispatch mode in which a taxi vehicle 32 is not allocated to a dispatch request, but a vehicle with special requirements is allocated.

[0038] The taxi company indicates the company to which the taxi driver 3 or NRS driver 4 belongs as a taxi business. User 2 can specify the desired taxi company by inputting information into the taxi company setting items. Vehicle attributes indicate the type and equipment of the vehicle. Examples of vehicle attributes include whether or not it is a high-class vehicle (a so-called hire car), whether or not it is wheelchair accessible, and whether or not it has sliding doors. User 2 can specify the attributes of the vehicle he or she wishes to dispatch by inputting information into the vehicle attribute setting items. Toll road information indicates whether or not toll roads, such as expressways, will be used. If the toll road information indicates the use of toll roads, toll roads will be actively included in the route from the pick-up point to the drop-off point.

[0039] (Dispatch request accumulation process S2) The user terminal control unit 170 of the vehicle dispatch management server 60 controls the user application of the user terminal 20 and performs processing corresponding to the dispatch request input through the user application. When the user terminal control unit 170 receives a dispatch request from the user terminal 20, it first identifies which of multiple operating areas the boarding location in the setting items is included in. The user terminal control unit 170 assigns the same identifier (taxi operating area ID) to dispatch requests sent in the same operating area. The user terminal control unit 170 associates the dispatch request received from the user terminal 20, including information on the various setting items described above, with the operating area identifier and the time of receipt of the dispatch request, and sequentially stores them in the storage device 164.

[0040] (Vehicle dispatch request extraction process S3) The vehicle dispatch unit 172 of the vehicle dispatch management server 60 extracts all vehicle dispatch requests that have occurred in a specified business area up to a specified execution timing from among the multiple vehicle dispatch requests stored in the storage device 164. Here, the execution timing indicates the timing at which the vehicle dispatch request extraction process S3 is started for the multiple vehicle dispatch requests, and is expressed, for example, as a time. The execution timing is set periodically and repeatedly at a specified processing interval. Therefore, a new execution timing is set after a specified processing period has elapsed since the vehicle dispatch request extraction process S3 was started at the previous execution timing. Here, the specified processing period is the length of time for which vehicle dispatch requests to be processed at one time are accumulated, and is set to, for example, 5 seconds.

[0041] However, in reality, in the matching started at the previous execution timing, a vehicle to be allocated may not have been determined for a vehicle allocation request. Such vehicle allocation requests for which a vehicle to be allocated has not been determined are carried over to the current execution timing, and matching continues. Therefore, the vehicle allocation unit 172 extracts, as vehicle allocation requests accumulated up to the current execution timing, vehicle allocation requests for which a vehicle to be allocated has not been determined in the previous matching, in addition to vehicle allocation requests accumulated from the previous execution timing to the current execution timing.

[0042] (Vehicle extraction process S4) The vehicle dispatch unit 172 extracts one or more vehicles that satisfy predetermined extraction conditions related to the vehicle dispatch request extracted in the vehicle dispatch request extraction process S3 from among multiple vehicles that can accommodate the user 2. Here, the extraction conditions include the conditions of the various setting items in the vehicle dispatch request, such as the vehicle dispatch category. If the vehicle dispatch category in the vehicle dispatch request is set to "taxi vehicles 32 only," the vehicle dispatch unit 172 extracts only taxi vehicles 32 for the vehicle dispatch request. If the vehicle dispatch category in the vehicle dispatch request is set to "taxi vehicles 32 and vehicles with special requirements," the vehicle dispatch unit 172 extracts taxi vehicles 32 and vehicles with special requirements for the vehicle dispatch request. Another extraction condition is, for example, that the estimated time of arrival at the boarding location is short. Specifically, the extraction condition is, for example, that the distance between the boarding location and the vehicle's current location is within a predetermined distance (e.g., 10 km), or that the estimated time of arrival at the boarding location is within a predetermined time (e.g., 10 minutes). In this case, the distance is the Euclidean distance between the boarding location and the current location of the vehicle, and the estimated arrival time is the time obtained by dividing the Euclidean distance by a predetermined speed (for example, the average speed when the vehicle is operating). Furthermore, the vehicle dispatch unit 172 may further limit the number of vehicles to be extracted to a predetermined number (for example, 10 vehicles) as an extraction condition in order of the shortest distance between the boarding location and the current location of the vehicle or the shortest estimated arrival time at the boarding location.

[0043] 8 is an explanatory diagram for explaining the processing of the vehicle dispatch unit 172. FIG. 8 shows four users 2a to 2d who have made vehicle dispatch requests within the service area A, and eleven vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, 42j, and 32k that exist within the service area A. In this embodiment, seven taxi vehicles 32a, 32c, 32d, 32e, 32g, 32h, and 32k and four NRS vehicles 42b, 42f, 42i, and 42j are shown. It is assumed that the service area A is a service area where the service area of ​​the taxi vehicle 32 and the service area of ​​the NRS vehicle 42 are the same.

[0044] The vehicle allocation unit 172 sets extraction conditions for each of the vehicle allocation requests extracted in the vehicle allocation request extraction process S3, i.e., for each of the vehicle allocation requests 22a to 22d of the users 2a to 2d. Here, the extraction condition is that the distance between the boarding location and the current location of the vehicle is equal to or less than a predetermined distance. Therefore, extraction conditions 24a to 24d, shown by dashed arcs in FIG. 8, are set for each of the vehicle allocation requests 22a to 22d of the users 2a to 2d.

[0045] The vehicle dispatch unit 172 extracts vehicles that satisfy extraction conditions 24a to 24d for each of the vehicle dispatch requests 22a to 22d of users 2a to 2d. For example, the vehicles that satisfy extraction condition 24a for user 2a's vehicle dispatch request 22a are vehicles 32a, 42b, 32c, 32d, and 32e. The vehicles that satisfy extraction condition 24b for user 2b's vehicle dispatch request 22b are vehicles 32e, 42f, 32g, 32h, and 42i. The vehicles that satisfy extraction condition 24c for user 2c's vehicle dispatch request 22c are vehicles 32d, 32e, 42f, 32h, and 42i. The vehicles that satisfy extraction condition 24d for user 2d's vehicle dispatch request 22d are vehicles 32d, 42i, and 42j. The vehicle dispatch unit 172 extracts all of the vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, and 42j, which are surrounded by solid lines in Figure 8 and satisfy any one of the extraction conditions 24a to 24d for each of the vehicle dispatch requests 22a to 22d, and excludes vehicle 32k, which does not satisfy any of the extraction conditions 24a to 24d, as a vehicle that has no possibility of being dispatched.

[0046] (Pair generation process S5) For each vehicle dispatch request 22 extracted in the vehicle dispatch request extraction process S3, the vehicle dispatch unit 172 extracts at least one vehicle that satisfies a predetermined pairing condition from the vehicles 32a, 42b, 32c, 32d, 32e, 42f, 32g, 32h, 42i, and 42j extracted in the vehicle extraction process S4, and associates the extracted vehicle with the vehicle dispatch request 22. Here, the pairing condition is that the vehicle's allowable items conform to all of the setting items of the vehicle dispatch request 22. For example, if the vehicle attribute included in the setting items of the vehicle dispatch request 22 is "sliding door compatible," the vehicle dispatch unit 172 determines that the vehicle is "suitable" if the vehicle's allowable items include sliding doors. Furthermore, for example, if the vehicle dispatch category included in the setting items of the vehicle dispatch request 22 is "taxi vehicles 32 only," the vehicle dispatch unit 172 determines that the vehicle is "suitable" if it is a taxi vehicle 32. The vehicle allocation unit 172 determines that a vehicle does not satisfy the pairing condition if any of the allowable items of the vehicle do not match the setting items of the vehicle allocation request 22. On the other hand, if the allowable items of the vehicle match all of the setting items of the vehicle allocation request 22, the vehicle allocation unit 172 associates the vehicle with the vehicle allocation request 22 as a vehicle that satisfies the pairing condition of the vehicle allocation request 22.

[0047] (Matching process S6) The vehicle allocation unit 172 matches the vehicle allocation requests 22 with vehicles for multiple combinations of the vehicle allocation requests 22 associated with the vehicles in the pair generation process S5. In this matching process, the vehicle allocation requests 22 are matched with the vehicles such that the vehicle with the highest priority among the at least one vehicle associated with each vehicle allocation request 22 does not overlap with at least one vehicle associated with another vehicle allocation request 22. For example, the vehicle allocation unit 172 exclusively matches the vehicle with the shortest average estimated arrival time with each of the vehicle allocation requests 22a to 22d. Note that various existing matching algorithms can be applied as the matching algorithm between the vehicle allocation requests 22 and vehicles, and therefore detailed description thereof will be omitted in this embodiment.

[0048] 9 is an explanatory diagram showing the results of matching by the vehicle dispatch unit 172. Using a predetermined matching algorithm, the vehicle dispatch unit 172 associates vehicles 42b, 32c, 32e, 32a, 42f, 32g, and 42j with the vehicle dispatch request 22a, and exclusively determines the NRS vehicle 42b with the highest priority. Similarly, the vehicle dispatch unit 172 associates vehicles 32h, 42f, 32e, 32g, 32a, 42j, and 32c with the vehicle dispatch request 22b, and exclusively determines the taxi vehicle 32h with the highest priority. Similarly, the vehicle dispatch unit 172 associates vehicles 42i, 32e, 42f, 32g, 32c, 42j, and 32a with the vehicle dispatch request 22c, and exclusively determines the NRS vehicle 42i with the highest priority. Similarly, vehicles 32d, 32e, 32c, and 32g are associated with the vehicle allocation request 22d, and the taxi vehicle 32d with the highest priority is exclusively determined. Here, "exclusive determination" means that the highest priority vehicles 42b, 32h, 42i, and 32d associated with the vehicle allocation requests 22a to 22d are determined so that they do not overlap with each other. The vehicle allocation unit 172 then determines the highest priority vehicle 42b, 32h, 42i, or 32d associated with each of the vehicle allocation requests 22a to 22d as the vehicle to be allocated for the vehicle allocation request 22a to 22d. In this way, the vehicle allocation unit 172 matches multiple vehicle allocation requests 22 with multiple vehicles at once and determines the vehicle to be allocated for each vehicle allocation request 22. In this way, compared to matching vehicle dispatch requests 22 sequentially and individually, matching can be optimized by comprehensively determining the relative positions of multiple users 2 and multiple vehicles, enabling efficient vehicle dispatch.

[0049] (Vehicle dispatch notification process S7) The vehicle terminal control unit 174 of the vehicle dispatch management server 60 controls the vehicle application of the vehicle terminal and performs vehicle dispatch management through the vehicle application. The vehicle terminal control unit 174 notifies the vehicle terminal disposed in the vehicle that has become the dispatch target vehicle in response to the dispatch request 22 of information (dispatch target notification) indicating that the vehicle has become the target of the dispatch request 22. This dispatch target notification corresponds to a prompt to the driver of the dispatch target vehicle as to whether or not to accept the dispatch request 22. In this way, the driver of the vehicle recognizes that his or her vehicle has become the target of the dispatch request 22, and can consider whether or not to accept the dispatch request 22.

[0050] (Acceptance response processing S8) When the vehicle dispatch response unit of the vehicle terminal arranged in the vehicle receives information indicating that the vehicle has been the target of the vehicle dispatch request 22 from the vehicle terminal control unit 174, the vehicle dispatch response unit notifies the driver of this fact, for example, via the vehicle display device. If the driver accepts the vehicle dispatch request 22, the driver accepts the vehicle dispatch request 22 via the vehicle input device of the vehicle terminal, for example, by tapping a position corresponding to a "request acceptance" button displayed on the vehicle display device. The vehicle dispatch response unit transmits information regarding the acceptance of the vehicle dispatch request 22 (acceptance response), including the acceptance of the vehicle dispatch request 22, to the vehicle dispatch management server 60.

[0051] If the driver cannot accept the vehicle allocation request 22 for some reason, the driver taps the "request reject" button displayed on the vehicle input device of the vehicle terminal to reject the vehicle allocation request 22, or does not tap the position corresponding to "request accept." The vehicle terminal control unit 174 waits for a predetermined time (e.g., 10 seconds) from the time the vehicle allocation target notification is sent, and if it does not receive information regarding acceptance of the vehicle allocation request 22 (acceptance response) from the vehicle terminal during the waiting time, it determines that the driver of the vehicle to be allocated has not accepted the vehicle allocation request 22. In this case, the vehicle allocation unit 172 determines the vehicle with the second highest priority among the vehicles associated with the vehicle allocation request 22 in the matching process S6 as the new vehicle to be allocated. Next, the vehicle terminal control unit 174 notifies the vehicle terminal of the other vehicle that has become the new vehicle to be allocated of information indicating that it has become the target of the vehicle allocation request 22 (vehicle allocation target notification).

[0052] (Vehicle dispatch completion notification process S9) When the vehicle terminal control unit 174 receives information (acceptance response) regarding acceptance of the vehicle allocation request 22 from the vehicle terminal, it confirms the allocation of the vehicle to be allocated in response to the vehicle allocation request 22 and transmits a vehicle allocation completion notification indicating that the vehicle allocation has been confirmed to the vehicle terminal. At this time, information regarding the vehicle allocation request 22, such as the boarding location and the route to the boarding location, is displayed on the vehicle display device of the vehicle terminal. With this configuration, the driver of the vehicle can grasp the information regarding the vehicle allocation request 22, drive an appropriate route toward the boarding location, and quickly find the user 2.

[0053] (User vehicle dispatch completion notification process S10) When the dispatch of the vehicle to be dispatched in response to the vehicle dispatch request 22 is confirmed, the user terminal control unit 170 transmits a vehicle dispatch completion notification indicating that the vehicle dispatch has been confirmed to the user terminal 20. At this time, the display device 124 of the user terminal 20 displays the location of the vehicle to be dispatched, the estimated arrival time, etc. In this way, the user 2 can appropriately board the vehicle at the boarding location. Note that if the vehicle dispatch unit 172 is unable to assign a vehicle to be dispatched in response to the vehicle dispatch request 22, the vehicle dispatch request 22 temporarily enters a vehicle dispatch failed (vehicle dispatch impossible) state. In this case, the display device 124 of the user terminal 20 displays information indicating that the vehicle dispatch was not possible and information indicating that the vehicle dispatch request 22 can be executed again. The user 2 will execute the vehicle dispatch request 22 again based on this information.

[0054] In the vehicle dispatch management method using the vehicle dispatch management system 1 described above, information on a plurality of vehicle dispatch requests 22 and a plurality of vehicles is accumulated and matched at once. In this case, by shortening the accumulation time, the frequency of execution of the vehicle dispatch matching process (S6) can be increased, thereby enabling efficient vehicle dispatch while maintaining convenience for the user 2.

[0055] (Setting item input process S11) 10 is a sequence diagram showing the flow of a vehicle transporting a user 2 in the vehicle dispatch management system 1. In this embodiment, the flow of transporting a user 2 will be described according to FIG. 10, focusing on the user application installed in the user terminal 20 and the vehicle application installed in the NRS terminal 40.

[0056] FIG. 11A is a first explanatory diagram illustrating the operation of the user terminal control unit 170. In response to an operation by user 2, the vehicle dispatch request unit 180 of the user terminal 20 launches a user application for making a vehicle dispatch request 22. Then, as shown in FIG. 11A , the user terminal control unit 170 of the vehicle dispatch management server 60 causes the display device 124 of the user terminal 20 to display a map 230 of a predetermined range including the location of the user terminal 20, a location 212 of the user terminal 20, and a vehicle 214 located near the user terminal 20. The user terminal control unit 170 also causes the display device 124 of the user terminal 20 to display an image 216 prompting the user to input a boarding location and a disembarking location. Here, assume that user 2 inputs, via the input device 126, for example, "1-chome, Shinagawa-ku, Tokyo" as the boarding location and "1-chome, Minato-ku, Tokyo" as the disembarking location in the text boxes of the image 216.

[0057] (Fee determination process S12) FIG. 11B is a second explanatory diagram illustrating the operation of the user terminal control unit 170. Based on the boarding and disembarking locations input through the user application, the user terminal control unit 170 derives the vehicle's mileage and driving time when user 2 actually drives the vehicle. Furthermore, the user terminal control unit 170 determines the fare based on the mileage and driving time using a fare table that associates fare with the mileage, driving time, and fare. The fare increases as the mileage and driving time increase. Furthermore, the user terminal control unit 170 adds a pick-up fee based on driving as a pick-up vehicle and an app arrangement fee based on dispatching a vehicle using the app to the fare. As shown in FIG. 11B, the user terminal control unit 170 displays an image 218 indicating the determined fare on the display device 124 of the user terminal 20. User 2 confirms the fare and determines whether to make a vehicle dispatch request 22.

[0058] (Vehicle dispatch request processing S13) When the user 2 operates the “vehicle allocation request” switch in the image 218 to make a vehicle allocation request 22 , the vehicle allocation request unit 180 of the user terminal 20 makes the vehicle allocation request 22 to the vehicle allocation management server 60 .

[0059] (Vehicle dispatch processing S14) The vehicle dispatch unit 172 of the vehicle dispatch management server 60 associates a vehicle with the vehicle dispatch request 22. Here, it is assumed that the NRS vehicle 42 is the vehicle to be dispatched in response to the vehicle dispatch request 22 from user 2. To facilitate understanding, each process will be explained below using images displayed on the display device 144 of the NRS terminal 40 installed in the NRS vehicle 42.

[0060] Fig. 12A is a diagram illustrating an example of a top screen displayed on the display device 144 of the NRS terminal 40. When the vehicle application is launched on the NRS terminal 40, the top screen shown in Fig. 12A is displayed. On the top screen, multiple commands are displayed that function as operation units of the input device 146 that accept tap operations by the driver. Of the multiple commands, Fig. 12A shows a sales history command 302 and a training command 304, but many other commands are also displayed on the top screen.

[0061] When the business history command 302 is tapped, a business history screen is displayed on the display device 144. As will be described in detail later, the business history screen displays a list of past business histories, in other words, riding records. Hereinafter, the history of one driving shift will be referred to as a driving history, and a collection of multiple driving shift histories per day will be referred to as a business history.

[0062] Furthermore, when the training command 304 is tapped, a training mode is started. As will be described in detail later, in the training mode, the driver can simulate the operations required of the driver during an actual driving shift, such as picking up the driver, driving the vehicle, and paying the toll. Note that the operations required of the driver of the NRS vehicle 42 during one driving shift, i.e., the operations that the driver of the NRS vehicle 42 must input into the NRS terminal 40 during one driving shift, may be referred to as required operations.

[0063] Furthermore, menu commands 306 are displayed at the top of the top screen. The menu commands 306 function as an operation unit of the input device 146 that accepts tap operations by the driver. When the menu command 306 is tapped, a menu list (not shown) is displayed on the display device 144. By tapping various menu commands displayed in the menu list, the driver can cause an image corresponding to the menu command to be displayed on the display device 144. For example, when a map display command displayed in the menu list is tapped, a map screen is displayed on the display device 144.

[0064] FIG. 12B is a diagram illustrating an example of a map screen displayed on the display device 144 of the NRS terminal 40. As shown in FIG. 12B, the map screen displays a map of the area around the NRS vehicle 42 (hereinafter simply referred to as the "own vehicle") on which the NRS terminal 40 currently being operated is installed. In addition, a host vehicle icon 308 representing the host vehicle is superimposed approximately in the center of the map. The map is displayed and moves as the host vehicle travels, allowing the driver to constantly check the current location of the host vehicle by the host vehicle icon 308. Note that, in this example, the vehicle terminal control unit 174 of the vehicle dispatch management server 60 controls the display device 144 of the NRS terminal 40 to display the map screen, but the processing device 142 of the NRS terminal 40 may also control the display of the map screen.

[0065] Menu commands 306 and navigation commands 310 are displayed at the top of the map screen. The navigation command 310 functions as an operation unit of the input device 146 that accepts tap operations by the driver. When the navigation command 310 is tapped, a navigation application stored in the NRS terminal 40 is launched. In this case, a navigation application is provided separately from the driver application installed on the NRS terminal 40. When the navigation command 310 is tapped, the navigation application is launched while the driver application currently being operated remains open, and a navigation screen for the navigation application is displayed on the display device 144. The navigation screen for the navigation application displays route guidance to the drop-off location.

[0066] The driver can switch the screen displayed on display device 144 from a navigation screen for the navigation application to a map screen for the driver application by inputting a predetermined operation into input device 146. Here, route guidance is performed by a navigation application separate from the driver application. However, a function for route guidance may be provided in the driver application. In this case, when navigation command 310 is tapped, route guidance to the drop-off location may be performed on the map screen shown in FIG. 12B.

[0067] Here, the control modes in the NRS terminal 40 include normal mode, stop mode, temporary suspension mode, and training mode. The driver can set the control mode by operating the input device 146 of the NRS terminal 40. The normal mode is a mode for transporting passengers. Specifically, when the control mode is switched in the NRS terminal 40, information indicating the current control mode is transmitted to the vehicle dispatch management server 60. The vehicle dispatch management server 60 manages the status of the NRS vehicles 42, and the dispatch unit 172 of the vehicle dispatch management server 60 extracts vehicles whose control mode is set to normal mode in the vehicle extraction process S4 described above.

[0068] In other words, vehicles whose control mode is set to the stop mode, temporary stop mode, or training mode are excluded from vehicles that are candidates for dispatch vehicles. Therefore, the normal mode can also be said to be a control mode in which a vehicle is permitted to be determined as a dispatch vehicle. However, the normal mode has multiple vehicle statuses. For example, statuses corresponding to the normal mode include an "empty vehicle" that is waiting to become a dispatch vehicle, a "pick-up vehicle" that is a dispatch vehicle, and an "active vehicle" that transports passengers to their drop-off locations.

[0069] The vehicle allocation management server 60 manages the status of vehicles set in normal mode, and vehicles with a status of vacant become candidates for vehicles to be allocated, while vehicles with other statuses are excluded from the candidates for vehicles to be allocated.

[0070] Fig. 12B shows a case in which the vehicle is in normal mode and the vehicle status is "vacant." When menu command 306 is tapped in the state shown in Fig. 12B, the menu screen shown in Fig. 13A is displayed on display device 144.

[0071] FIG. 13A is a diagram illustrating an example of a menu screen displayed on the display device 144 of the NRS terminal 40. The menu screen is provided with a vehicle allocation status display area 312a. The vehicle allocation status display area 312a identifiably displays whether or not the vehicle itself can currently be extracted as a vehicle to be allocated. During normal mode, as shown in FIG. 13A, the vehicle allocation status display area 312a displays "Vehicle allocation accepted."

[0072] Furthermore, the vehicle allocation status display area 312a is provided with a pause command 312. The pause command 312 functions as an operation unit of the input device 146 that accepts tap operations by the driver. When the pause command 312 is tapped, the control mode switches from normal mode to pause mode. At this time, a notification indicating that the control mode has been set to pause mode is sent to the vehicle allocation management server 60. Based on the received notification, the vehicle allocation management server 60 updates the status of the vehicle to "temporarily paused." As a result, the vehicle is subsequently excluded from the targets of the vehicle extraction process S4 in the vehicle allocation management server 60.

[0073] Fig. 13B is a diagram illustrating an example of a pause screen displayed on the display device 144 of the NRS terminal 40. When a pause command 312 is tapped on the menu screen shown in Fig. 13A, the pause screen shown in Fig. 13B is displayed on the display device 144. On the pause screen, it is possible to identify that the vehicle dispatch management server 60 has stopped extracting the subject vehicle as a vehicle to be dispatched. In addition, the pause screen is provided with a vehicle dispatch resume command 314. The vehicle dispatch resume command 314 functions as an operation unit of the input device 146 that accepts tap operations by the driver.

[0074] When the vehicle allocation resume command 314 is tapped, the control mode switches from the temporary stop mode to the normal mode. At this time, a notification indicating that the control mode has been set to the normal mode is sent to the vehicle allocation management server 60. As a result, the vehicle allocation management server 60 updates the status of the vehicle to "vacant," and the vehicle becomes a target for the vehicle extraction process S4. When the vehicle allocation resume command 314 is tapped and the control mode is changed to the normal mode, the menu screen shown in FIG. 13A or the map screen shown in FIG. 12B is displayed on the display device 144.

[0075] 13A, the menu screen also has a duty end information display area 316a. The duty end information display area 316a displays the time at which the driver will end their duty. Although a detailed explanation will be omitted, the driver of the NRS vehicle 42 inputs the duty end time from the input device 146 to the NRS terminal 40 before driving. The duty end time input by the driver is displayed in the duty end information display area 316a.

[0076] Furthermore, the driving end information display area 316a is provided with a driving end command 316. The driving end command 316 functions as an operation unit of the input device 146 that accepts tap operations by the driver. When the driving end command 316 is tapped, the control mode switches from normal mode to stop mode. At this time, a notification indicating that the control mode has been set to stop mode is sent to the vehicle dispatch management server 60, and the vehicle dispatch management server 60 updates the vehicle's status to "stopped." As a result, the vehicle is subsequently excluded from the targets of the vehicle extraction process S4 in the vehicle dispatch management server 60.

[0077] As with the top screen, the menu screen also has a business history command 302. When the business history command 302 is tapped on the menu screen, the business history screen described below is displayed on the display device 144, just as when the business history command 302 is tapped on the top screen.

[0078] Assume that the control mode of the NRS vehicle 42 (own vehicle) is set to normal mode (empty vehicle) and the map screen shown in Fig. 12B is displayed on the display device 144 of the NRS terminal 40. At this time, assume that the user 2 operates the "vehicle allocation request" switch to make a vehicle allocation request 22 as shown in Fig. 11B, and the vehicle allocation management server 60 determines the own vehicle as the vehicle to be allocated.

[0079] (Vehicle dispatch notification process S15) 14A is a first explanatory diagram for explaining the operation of the vehicle terminal control unit 174. As shown in FIG. 14A, the vehicle terminal control unit 174 of the vehicle dispatch management server 60 causes the display device 144 of the NRS terminal 40 disposed in the NRS vehicle 42 that has become the dispatch target vehicle in response to the dispatch request 22 to display a dispatch notification image 320 including the message "A dispatch request has been received" as information indicating that the vehicle itself has become the dispatch target vehicle.

[0080] (Acceptance response S16) The vehicle allocation notification image 320 includes a vehicle allocation acceptance command 320a. The vehicle allocation acceptance command 320a functions as an operation unit of the input device 146 that accepts a tap operation by the driver. By tapping the vehicle allocation acceptance command 320a, the driver can accept to be a vehicle to be allocated. When the vehicle allocation acceptance command 320a is tapped, the vehicle allocation response unit 184 transmits a notification to the vehicle allocation management server 60 indicating acceptance to be a vehicle to be allocated.

[0081] (Vehicle dispatch completion notification process S17) 14B is a second explanatory diagram for explaining the operation of the vehicle terminal control unit 174. Upon receiving a notification indicating consent to be a vehicle to be dispatched, the vehicle terminal control unit 174 confirms its own vehicle (the vehicle that has consented) as a vehicle to be dispatched for the vehicle dispatch request 22, and displays boarding location information 322 indicating the boarding location superimposed on the map screen. At this time, the vehicle dispatch management server 60 also updates the status of the vehicle to "pick-up." Vehicles with a status of "pick-up" are excluded from the targets of the vehicle extraction process S4.

[0082] The boarding location information 322 indicates the boarding location, for example, an address of "1-chome, Shinagawa-ku, Tokyo." In addition to the boarding location information 322, the display device 144 also displays on the map a vehicle icon 308 indicating the current location of the vehicle and a boarding location icon 324 indicating the boarding location. In addition, a vehicle command 326 is displayed in the lower left corner of the map screen.

[0083] (User vehicle dispatch completion notification process S18) When the dispatch of the vehicle to be dispatched in response to the dispatch request 22 is confirmed, the user terminal control unit 170 causes the display device 124 of the user terminal 20 to display an image showing information about the dispatch. At this time, the image displayed on the display device 124 includes the fee for using the vehicle, the current location of the confirmed vehicle to be dispatched, etc.

[0084] (Vehicle arrival notification process S19) 15 is a diagram illustrating an example of a map screen displayed on the display device 144 of the NRS terminal 40 upon arrival. Arrival means that the vehicle, which is the vehicle to be dispatched, enters within a predetermined distance from the boarding location. When the vehicle arrives, the vehicle terminal control unit 174 displays an arrival command 328, a call command 330, and a message command 332 at the bottom of the map screen.

[0085] The current arrival command 328, the call command 330, and the message command 332 all function as operation units of the input device 146 that accept tap operations by the driver. When the current arrival command 328 is tapped, a vehicle arrival notification indicating that the vehicle has arrived at or near the boarding location is transmitted to the vehicle dispatch management server 60. When the call command 330 is tapped, a call with user 2 is initiated based on the setting items entered by user 2. When the message command 332 is tapped, it becomes possible to send and receive messages to and from user 2.

[0086] (User current arrival notification process S20) When the vehicle dispatch management server 60 receives a vehicle arrival notification from the vehicle, the user terminal control unit 170 issues a user arrival notification to the user 2 notifying the user that the vehicle has arrived at the boarding location. In this user arrival notification, the user terminal control unit 170 causes the display device 124 of the user terminal 20 to display an image indicating that the vehicle has arrived at the boarding location.

[0087] (Actual vehicle notification process S21) 16A is a diagram illustrating an example of a map screen after notification of the arrival of a vehicle. When the arrival command 328 is tapped on the NRS terminal 40 of the vehicle, the map screen of the display device 144 of the vehicle is updated as shown in FIG. 16A. Here, a call command 330 and a message command 332 are provided at the bottom of the map screen, and the name of User 2 who requested the vehicle dispatch is also displayed.

[0088] Thereafter, when user 2 gets into the vehicle, the driver needs to tap the actual vehicle command 326. When the actual vehicle command 326 is tapped, an actual vehicle notification indicating that user 2 has gotten into the vehicle, i.e., that the actual vehicle has started, is sent to the vehicle dispatch management server 60.

[0089] (Actual vehicle time memory processing S22) When the vehicle dispatch management server 60 receives the actual vehicle notification, it stores the time of receipt of the actual vehicle notification, i.e., the time of user 2's ride, in association with the vehicle identification information set for each vehicle. In addition, the vehicle dispatch management server 60 updates the status of the vehicle that sent the actual vehicle notification to "actual vehicle." Vehicles with a status of "actual vehicle" are excluded from the vehicle extraction process S4.

[0090] (Meter information notification process when boarding S23) FIG. 16B is a diagram illustrating an example of a boarding odometer input screen. When the actual vehicle command 326 is tapped on the NRS terminal 40, the boarding odometer input screen is displayed on the display device 144 of the NRS terminal 40, as shown in FIG. 16B. The boarding odometer input screen is provided with an operation input unit 336 and a completion command 338. The operation input unit 336 and the completion command 338 function as operation units of the input device 146 that accept tap operations by the driver. The driver can input the current mileage of the vehicle by operating the operation input unit 336. When the completion command 338 is tapped after the mileage has been input, a boarding meter information notification indicating the mileage at the time of boarding is transmitted to the vehicle dispatch management server 60.

[0091] (Meter information storage process when getting on S24) When the vehicle dispatch management server 60 receives the boarding time meter information notification, it stores the meter value of the vehicle at the time of boarding, i.e., the distance traveled at the time of boarding, in association with the vehicle identification information set for each vehicle.

[0092] (Payment completion notification process S25) FIG. 17A is a third explanatory diagram illustrating the operation of the vehicle terminal control unit 174. FIG. 17B is a fourth explanatory diagram illustrating the operation of the vehicle terminal control unit 174. After completing the input and transmission of the boarding meter information notification, the driver starts transporting user 2 toward the drop-off location. During this time, as shown in FIG. 17A, the vehicle terminal control unit 174 displays drop-off location information 340 indicating the drop-off location superimposed on the map screen. The drop-off location information 340 indicates, for example, the address "1-chome, Chuo-ku, Tokyo" as the drop-off location. In addition to the drop-off location information 340, the display device 144 also displays the vehicle icon 308 and a drop-off location icon 342 indicating the drop-off location on the map. In addition, a payment icon 344 is displayed in the lower left corner of the map screen.

[0093] The payment icon 344 functions as an operation unit of the input device 146 that accepts tap operations by the driver. When the driver's vehicle arrives at the drop-off location, the driver needs to tap the payment icon 344. When the payment icon 344 is tapped, the vehicle terminal control unit 174 causes the display device 144 to display the payment screen shown in FIG. 17B. When the payment icon 344 is tapped, a notification indicating the start of payment may be sent to the vehicle dispatch management server 60. In this case, for example, the vehicle dispatch management server 60 may update the status of the vehicle to "payment in progress."

[0094] The payment screen displays a fee notification image 346. The fee notification image 346 displays the fee to be paid by the user 2. The fee notification image 346 also has a payment command 346a. The payment command 346a functions as an operation unit of the input device 146 that accepts tap operations by the driver.

[0095] The driver can start payment by tapping payment command 346a. When payment command 346a is tapped, a procedure screen (not shown) is displayed, and user 2 can perform the payment procedure. When the payment procedure is completed, a payment completion notice indicating that the payment has been completed successfully is sent to vehicle dispatch management server 60.

[0096] (Payment completion information storage process S26) When the vehicle dispatch management server 60 receives the payment completion notice, it stores the current time and the payment amount in association with the vehicle identification information set for each vehicle.

[0097] (Meter information notification process when getting off S27) FIG. 18 is a diagram illustrating an example of a dismounting odometer input screen. When the payment procedure is completed in the NRS terminal 40, as shown in FIG. 18, a dismounting odometer input screen is displayed on the display device 144 of the NRS terminal 40. The dismounting odometer input screen is provided with an operation input unit 348 and a completion command 350. The operation input unit 348 and the completion command 350 function as operation units of the input device 146 that accept tap operations by the driver. The driver can input the current mileage of the vehicle by operating the operation input unit 348. When the completion command 350 is tapped after the mileage has been input, a dismounting meter information notification indicating the mileage at the time of dismounting is transmitted to the vehicle dispatch management server 60.

[0098] (Meter information storage process when getting off S28) When the vehicle dispatch management server 60 receives the disembarking meter information notification, it stores the meter value of the NRS vehicle 42 at the time of disembarking, i.e., the mileage at the time of disembarking, in association with the vehicle identification information set for each vehicle. This makes it possible to manage the mileage for the current shift. The vehicle dispatch management server 60 also updates the status of the vehicle that sent the disembarking meter information notification from "occupied" to "vacant." By updating the status to "vacant," the vehicle becomes the target of the subsequent vehicle extraction process S4.

[0099] As described above, the driver is required to perform various operations on the NRS terminal 40 during one driving session, from when the driver agrees to be a vehicle to be dispatched to when the user 2 gets off the vehicle. If the driver does not perform the appropriate operations at the appropriate time, the driving session may be hindered. Therefore, in this embodiment, a training mode is provided to promote the education of inexperienced drivers in particular. The training mode will be described below.

[0100] (Training Mode) When the training command 304 is tapped on the top screen shown in FIG. 12A, the control mode of the NRS terminal 40 is set to training mode. When training mode is set, a training mode start notification indicating the start of training mode is transmitted from the NRS terminal 40 to the vehicle dispatch management server 60. Upon receiving the training mode start notification, the vehicle dispatch management server 60 updates the status of the vehicle identification information of the vehicle to "training mode." As a result, the vehicle is subsequently excluded from the targets of the vehicle extraction process S4.

[0101] Note that during training mode, the vehicle's status may be set to "temporarily suspended." In any case, the status may be managed so that the vehicle is excluded from the vehicle extraction process S4 during training mode. Here, the subject vehicle is excluded from the vehicle extraction process S4 during training mode, but the subject vehicle may also be subject to the vehicle extraction process S4 during training mode. In this case, when the subject vehicle agrees to be a vehicle to be dispatched, the training mode is forcibly terminated and the mode is switched to normal mode.

[0102] FIG. 19A is a first diagram illustrating an example of a screen during training mode. FIG. 19B is a second diagram illustrating an example of a screen during training mode. FIG. 20 is a third diagram illustrating an example of a screen during training mode. When a training command 304 is tapped on the top screen, a map screen is displayed on the display device 144 of the NRS terminal 40. As in normal mode, the map screen displays a map of a predetermined range centered on the current location, with the vehicle icon 308 and the boarding location setting icon 352 superimposed in the center.

[0103] The map screen functions as an operation section of the input device 146 that accepts a slide operation by the driver. The driver can change the position of the boarding location setting icon 352 on the map by sliding the map screen.

[0104] Additionally, in training mode, a message saying "Please set a boarding location on the map" is displayed at the top of the map screen, and a decision command 354 is displayed nearby. The decision command 354 functions as an operation unit of the input device 146 that accepts tap operations by the driver. When the decision command 354 is tapped, the position of the boarding location setting icon 352 that is displayed at that time is set as the boarding location in training mode.

[0105] Once the boarding location is set, a drop-off location setting icon 356 is superimposed on the map as shown in Fig. 19B. With the drop-off location setting icon 356 displayed, the driver can change the position of the drop-off location setting icon 356 on the map by sliding the map screen in the same manner as described above.

[0106] Additionally, a message saying "Please set a drop-off location on the map" is displayed at the top of the map screen, and a decision command 358 is displayed nearby. The decision command 358 functions as an operation unit of the input device 146 that accepts tap operations by the driver. When the decision command 358 is tapped, the position of the drop-off location setting icon 356 that is displayed at that time is set as the drop-off location in the training mode.

[0107] In this way, in the training mode, the driver can set the boarding and disembarking locations of the virtual passengers. Note that in the training mode, the driver's setting operation for setting the boarding and disembarking locations can be accepted, and the boarding and disembarking locations are set based on the setting operation input by the driver. However, the boarding and disembarking locations may be determined, for example, randomly, regardless of the driver's setting operation.

[0108] For example, the processing device 142 of the NRS terminal 40 may determine an arbitrary location within a predetermined range from the current location as the boarding location. The processing device 142 may also determine an arbitrary location within a predetermined distance from the boarding location as the disembarking location. In this case, for example, the driver may be able to set the distance from the current location to the boarding location or the distance from the boarding location to the disembarking location. The processing device 142 may determine the boarding location and the disembarking location based on the distance set by the driver.

[0109] In the training mode, the boarding location and disembarking location may be determined by the vehicle terminal control unit 174 of the vehicle dispatch management server 60. In this case, when the vehicle dispatch management server 60 receives a training mode start notification, it may determine the boarding location and disembarking location based on the position of the NRS terminal 40 and transmit information indicating the determined boarding location and disembarking location to the NRS terminal 40.

[0110] During training mode, menu commands 306 and navigation commands 310 are displayed at the top of the map screen, just as in normal mode. However, while the driver is setting the pick-up and drop-off locations, the navigation commands 310 are disabled. Also, during training mode, an exit command 360 is always displayed at the top of the map screen. The exit command 360 functions as an operation unit of the input device 146 that accepts driver operations. The driver can end training mode by tapping the exit command 360. When the exit command 360 is tapped, the control mode of the NRS terminal 40 is set to normal mode. Once set to normal mode, a training mode end notice indicating the end of training mode is sent from the NRS terminal 40 to the vehicle dispatch management server 60. Upon receiving the training mode end notice, the vehicle dispatch management server 60 updates the status of the vehicle identification information of the vehicle to "vacant." As a result, the vehicle becomes a target of vehicle extraction processing S4 thereafter.

[0111] When the boarding and disembarking locations are set, the driver's vehicle icon 308 and boarding location icon 324 are displayed on the map on the map screen, as shown in Fig. 20. At this time, boarding location information 322 and a vehicle command 326 are also displayed on the map screen. That is, when the boarding and disembarking locations are set in the training mode, the map screen is displayed in the same manner as when the driver agrees to be a dispatched vehicle in the normal mode. Thereafter, until the disembarking odometer input screen is displayed, screens similar to those displayed during driving in the normal mode, such as when picking up the driver, when the driver is in the vehicle, and when making a payment, are displayed based on the driver's operational input.

[0112] That is, during the training mode, the same screen as during driving in normal mode is displayed, except for the display of the end command 360. Therefore, during the training mode, the driver needs to input the same necessary operations into the NRS terminal 40 as during actual driving. This allows the driver to practice the necessary operations that will be required during actual driving.

[0113] The following mainly describes the processing related to the training mode in the NRS terminal 40 and the vehicle dispatch management server 60.

[0114] Fig. 21 is a diagram illustrating an example of the training mode execution process in the NRS terminal 40. The training mode execution process shown in Fig. 21 is started, for example, when the training command 304 is operated on the top screen.

[0115] (S100-1) The processing device 142 of the NRS terminal 40 executes processing to start the training mode. Here, the processing device 142 displays a screen for setting the boarding location and disembarking location on the display device 144, as shown in Figures 19A and 19B. Also, here, the processing device 142 transmits a training mode start notification to the vehicle dispatch management server 60.

[0116] (S100-2~S100-3) When a setting operation to set a boarding location, that is, a tap operation of the decision command 354 is input (YES in S100-2), the processing device 142 registers the display position of the boarding location setting icon 352 as a boarding location (S100-3).

[0117] (S100-4~S100-6) When a setting operation to set a drop-off location, i.e., a tap operation of the decision command 358, is input (YES in S100-4), the processing device 142 registers the display position of the drop-off location setting icon 356 as the drop-off location (S100-5). In addition, the processing device 142 transmits a boarding / alighting location notice indicating the registered boarding location and alighting location to the vehicle dispatch management server 60 (S100-6). Upon receiving the boarding / alighting location notice, the vehicle dispatch management server 60 calculates a fare based on the boarding location and alighting location, and transmits a fare notice indicating the calculated fare to the NRS terminal 40.

[0118] (S100-7~S100-8) If a fee notice is received (YES in S100-7), the processing device 142 stores the fee indicated in the received fee notice (S100-8).

[0119] (S100-9~S100-10) If any other operation is input during training mode (YES in S100-9), the processing device 142 updates the screen of the display device 144 based on the input operation (S100-10). Note that the other operations referred to here include operations on the actual vehicle command 326, arrival command 328, operation input unit 336, completion command 338, payment icon 344, settlement command 346a, operation input unit 348, and completion command 350, i.e., necessary operations. Therefore, for example, when the vehicle arrives at the drop-off location, operation of the payment icon 344 is required, and when the payment icon 344 is operated, operations related to the payment of the fare can be input.

[0120] (S100-11~S100-13) When an end operation to end the training mode, i.e., a tap operation of the end command 360, is input (YES in S100-11), the processing device 142 transmits a training mode end notification to the dispatch management server 60 (100-12) and executes end processing to end the training mode (S100-13). In this end processing, the training mode is ended and processing to set to normal mode is performed.

[0121] 22 is a diagram illustrating an example of server processing in the vehicle dispatch management server 60. Note that FIG. 22 shows a part of the processing of the vehicle dispatch management server 60, mainly related to communication with the NRS terminal 40.

[0122] (S200-1~S200-2) When a temporary stop notification is received from the NRS terminal 40 (YES in S200-1), the processing device 162 of the vehicle dispatch management server 60 updates the status of the NRS vehicle 42 in which the NRS terminal 40 that sent the temporary stop notification is installed to "temporarily stopped" (S200-2).

[0123] (S200-3~S200-4) If a training mode start notification is received from the NRS terminal 40 (YES in S200-3), the processing device 162 updates the status of the NRS vehicle 42 in which the NRS terminal 40 that sent the training mode start notification is installed to "in training mode" (S200-4).

[0124] (S200-5~S200-7) If a boarding / alighting location notification is received from the NRS terminal 40 (YES in S200-5), the processing device 162 calculates the fare (S200-6) and sends a fare notification to the NRS terminal 40 of the NRS vehicle 42 that sent the boarding / alighting location notification (S200-7).

[0125] (S200-8~S200-10) If other notifications are received from the NRS terminal 40 (YES in S200-8), the processing device 162 stores the driving history information based on the received notifications (S200-9). Note that the other notifications referred to here include notifications sent by operating the actual vehicle command 326, arrival command 328, operation input unit 336, completion command 338, payment icon 344, settlement command 346a, operation input unit 348, and completion command 350, i.e., notifications sent by inputting a required operation. Hereinafter, notifications sent from the NRS terminal 40 to the vehicle dispatch management server 60 by inputting a required operation may be referred to as required information.

[0126] Here, the other notifications are necessary information corresponding to the necessary operations required of the driver during one driving period from when user 2 gets on to when user 2 gets off, including at least a first operation (here, the operation of the actual vehicle command 326) indicating that user 2 is getting on and a second operation (here, the operation of the completion command 350) indicating that user 2 is getting off. The processing device 162 stores driving history information related to one driving session, linking it to the NRS terminal 40 or the NRS vehicle 42. The processing device 162 also generates business history information including multiple pieces of driving history information. Therefore, here, information necessary to generate the business history information and driving history information, in other words, various information included in the business history information and driving history information, is stored.

[0127] Furthermore, the processing device 162 updates the status of the sending NRS vehicle 42 (S200-10). When the processing device 162 receives a notification that the status should be updated, it updates the status of the sending NRS vehicle 42 based on the received notification. Although detailed explanations are omitted, various processes corresponding to the received notification are also executed here in addition to updating the status.

[0128] (S200-11~S200-12) When a training mode end notification is received from the NRS terminal 40 (YES in S200-11), the processing device 162 updates the status of the NRS vehicle 42 in which the NRS terminal 40 that sent the training mode end notification is installed to "vacant" (S200-12).

[0129] FIG. 23 is a sequence diagram showing the processing flow in training mode. In training mode, when the boarding and disembarking locations are set, a boarding and disembarking location notification including the location information of the boarding and disembarking locations is transmitted from the NRS terminal 40 to the vehicle dispatch management server 60 (S31). Upon receiving the boarding and disembarking location notification, the vehicle dispatch management server 60 calculates the fare from the boarding and disembarking locations (S32). The fare is calculated according to the same algorithm as in normal mode. The NRS terminal 40 receives a fare notification indicating the fare calculated by the vehicle dispatch management server 60 (S33). Based on this fare notification, a screen related to fare payment and settlement is displayed during training mode.

[0130] Here, in normal mode, i.e., during actual driving, based on the driver's operation input to the NRS terminal 40, a current arrival notification (S19), a current vehicle notification (S21), a boarding meter information notification (S23), a payment completion notification (S25), and a disembarking meter information notification (S27) are sent to the vehicle dispatch management server 60. On the other hand, even during training mode, the necessary operations of the current vehicle command 326, current arrival command 328, operation input unit 336, completion command 338, payment icon 344, payment command 346a, operation input unit 348, and completion command 350 are accepted, but various notifications are not sent from the NRS terminal 40 to the vehicle dispatch management server 60.

[0131] That is, the NRS terminal 40 performs the following processes in response to an operational input from the driver: starting the training mode; setting the boarding and disembarking locations in the training mode; and enabling the NRS terminal 40 to accept necessary operations required of the driver during one driving period from boarding to disembarking of the user 2 during the training mode. However, during the training mode, necessary information corresponding to the necessary operations is not transmitted to the vehicle dispatch management server 60.

[0132] During the training mode, only some of the necessary operations may be accepted, or all of the necessary operations required during actual driving may be accepted. Also, during the training mode, some of the necessary information may be transmitted to the vehicle dispatch management server 60, or none of the necessary information may be transmitted to the vehicle dispatch management server 60.

[0133] As described above, in training mode, only information for calculating fares is transmitted and received, and no other information is transmitted and received, thereby reducing the processing load on the NRS terminal 40 and the vehicle dispatch management server 60 during training mode. Furthermore, in normal mode, various notifications are sent from the NRS terminal 40 to the vehicle dispatch management server 60, and business history information is recorded in the vehicle dispatch management server 60. Therefore, if notifications are sent during training mode in the same way as in normal mode, the business history information will include driving history information for drivers who did not actually drive. In this embodiment, notifications from the NRS terminal 40 to the vehicle dispatch management server 60 are restricted during training mode, eliminating the risk of recording incorrect driving history information.

[0134] However, during the training mode, various notifications may be transmitted from the NRS terminal 40 to the vehicle dispatch management server 60, and the notifications may be discarded by the vehicle dispatch management server 60. That is, the NRS terminal 40 performs the following processes in response to an operational input from the driver: starting the training mode; setting the boarding and disembarking locations in the training mode; enabling acceptance of some or all of the necessary operations during the training mode; and transmitting some or all of the necessary information corresponding to the necessary operations to the vehicle dispatch management server 60 during the training mode. The vehicle dispatch management server 60 may then generate business history information by excluding the necessary information transmitted during the training mode.

[0135] Alternatively, notifications sent from the NRS terminal 40 to the vehicle dispatch management server 60 during training mode and normal mode may be distinguishable. In this case, the vehicle dispatch management server 60 may discard notifications sent during training mode.

[0136] FIG. 24 is a diagram illustrating an example of a business history screen. For example, when the business history command 302 is tapped on the top screen shown in FIG. 12A or the menu screen shown in FIG. 13A, the business history screen shown in FIG. 24 is displayed on the display device 144 of the NRS terminal 40. The business history screen displayed on the display device 144 includes a driving history display section 370. The driving history display section 370 displays driving history information corresponding to one driving session. Here, the driving history information displayed includes the boarding time, boarding location, disembarking time, disembarking location, and fare. However, the information included in the driving history information is not limited to this and can be designed as appropriate.

[0137] Here, the driving history display unit 370 is displayed for each day. Therefore, the driver can look back on his or her past driving duties by operating the NRS terminal 40 to display the business history screen. Note that driving history information may be stored in the NRS terminal 40 based on the driver's operational input to the NRS terminal 40 while on duty, and the business history screen may be displayed based on the driving history information stored in the NRS terminal 40. Alternatively, driving history information may not be stored in the NRS terminal 40, and when the business history screen is displayed, the driving history information may be acquired from the vehicle dispatch management server 60, and the processing device 142 may display the business history screen. Furthermore, the vehicle terminal control unit 174 of the vehicle dispatch management server 60 may generate the business history screen and display it on the display device 144 of the NRS terminal 40.

[0138] 25 is a diagram illustrating an example of business history information generated by the vehicle dispatch management server 60. As described above, while on duty, the driver is required to perform various operations on the NRS terminal 40. When an operation is input to the NRS terminal 40, a notification corresponding to the various operations is sent from the NRS terminal 40 to the vehicle dispatch management server 60. Based on the received notification, the processing device 162 of the vehicle dispatch management server 60 stores the business history information in association with the NRS vehicle 42 in which the sending NRS terminal 40 is installed.

[0139] Here, for example, upon receiving a vehicle notification, the processing device 162 of the vehicle dispatch management server 60 acquires the time at which the vehicle notification was received and stores it as the boarding time. Similarly, upon receiving a disembarking meter information notification (which may be a payment completion notification), the processing device 162 acquires the time at which the notification was received and stores it as the disembarking time. Furthermore, upon consent to be the vehicle to be dispatched, the processing device 162 associates the boarding location and disembarking location included in the dispatch request 22 with the NRS vehicle 42 that consented to be the vehicle to be dispatched and stores them. Furthermore, upon receiving a disembarking meter information notification (which may be a payment completion notification), the processing device 162 stores the fee calculated by the vehicle dispatch management server 60 as sales.

[0140] Here, the taxi terminal 30 of the taxi vehicle 32 can perform operations related to vehicle registration and payment, just like the NRS vehicle 42 described above, and when these operations are performed, a notification is sent from the taxi terminal 30 to the vehicle dispatch management server 60. In this respect, there is no difference between the taxi terminal 30 and the NRS terminal 40, but the taxi terminal 30 is equipped with a fare meter, and fares are calculated in the taxi vehicle 32. The taxi terminal 30 can also obtain the mileage (odometer) from the taxi vehicle 32, and can send the mileage during one ride to the vehicle dispatch management server 60.

[0141] However, the NRS terminal 40 installed in the NRS vehicle 42 is independent of the NRS vehicle 42, and it is difficult to obtain information related to mileage from the NRS terminal 40. If the business history information does not include the mileage per driving shift, it will be difficult to confirm sales, etc. Furthermore, if information related to mileage cannot be confirmed when looking back at past driving shifts, it will be difficult to use past business history for driver training.

[0142] Therefore, in this embodiment, as described above, the driver himself / herself inputs the distance traveled when getting on and the distance traveled when getting off into the NRS terminal 40, and business history information is generated based on the driver's operational input.

[0143] That is, the NRS terminal 40 performs the following operations: a process for accepting necessary operations required of the driver during one driving period from when user 2 gets on to when user 2 gets off, the process including at least a first operation indicating user 2 getting on and a second operation indicating user 2 getting off; a process for transmitting necessary information corresponding to the necessary operations, including first information corresponding to the first operation and second information corresponding to the second operation, to the vehicle dispatch management server 60; a process for allowing input of the mileage of the NRS vehicle 42 at the time of user 2 getting on and when user 2 gets off; and a process for transmitting mileage information indicating the input mileage to the vehicle dispatch management server 60. The vehicle dispatch management server 60 then performs a process for generating predetermined business history information based on the necessary information and mileage information received from the NRS vehicle 42. This makes it possible to output business history information to the NRS vehicle 42 similar to that of the taxi vehicle 32.

[0144] Here, the case where the operation of inputting the mileage at the time of boarding and disembarking has been described as a required operation. In other words, during one driving shift, the driver must input the mileage at the time of boarding and disembarking into the NRS terminal 40, because subsequent input operations will be impossible unless the driver inputs the mileage. However, the operation of inputting the mileage does not necessarily have to be a required operation. For example, the timing when the driver inputs the mileage is not limited to during driving, but may be after the end of one driving shift or when the vehicle is empty. Also, for example, it may be possible to input only the mileage of the vehicle at either the time when the user 2 boards or disembarks.

[0145] However, in this case, there is a risk that the driver will forget to input the mileage. Also, if the mileage is not input immediately after a driving shift ends, there is a high risk that the mileage at the time of boarding and disembarking will not be input properly. By setting the operation of inputting the mileage as a required operation as in this embodiment, it is possible to prevent the driver from forgetting to input the mileage or inputting an incorrect mileage.

[0146] In the above embodiment and various modified examples, the training mode and business history information are described as being applied to the NRS terminal 40 and the NRS vehicle 42. However, the training mode and business history information can also be applied to the taxi terminal 30 and the taxi vehicle 32. In any case, the vehicles and vehicle terminals to which the configurations described in the above embodiment and various modified examples are applied are not particularly limited.

[0147] In any case, the information processing system a vehicle terminal (as an example, an NRS terminal 40 in the embodiment) provided in the vehicle; a server (in the embodiment, as an example, a vehicle dispatch management server 60) that receives information from the vehicle terminal; Equipped with The vehicle terminal is A process (S100-10, for example, in the embodiment) that enables the driver to accept the necessary operations required during one driving period from when the user gets on to when the user gets off, including at least a first operation (in the embodiment, for example, an operation of the actual vehicle command 326 or the arrival command 328) required when the user gets on, and a second operation (in the embodiment, for example, an operation of the payment icon 344) required when the user gets off; a process of transmitting necessary information corresponding to the necessary operation to the server (S19, S21, and S25 are examples in the embodiment), the necessary information including first information corresponding to the first operation (a vehicle arrival notification is an example in the embodiment) and second information corresponding to the second operation (a payment completion notification is an example in the embodiment); A process for allowing the user to input the vehicle mileage at either or both the time of boarding and disembarking (in the embodiment, as an example, the screens of S21, S25, FIG. 16B, and FIG. 18); A process of transmitting mileage information indicating the input mileage (for example, in the embodiment, a meter information notification when boarding and a meter information notification when disembarking) to the server (for example, in the embodiment, S23 and S27); and The server A process of generating a predetermined business history based on the necessary information and mileage information received from the vehicle terminal (S200-9 in the embodiment as an example); All you have to do is carry out the following.

[0148] In addition, the vehicle terminal A process of starting the training mode in response to an operation input by the driver (S100-1 in the embodiment as an example); In the training mode, a process of setting a boarding location and a disembarking location (S100-3 and S100-5 are shown as examples in the embodiment); During the training mode, a process for enabling input of some or all of the necessary operations (S100-10 in the embodiment as an example); and During the training mode, some or all of the necessary information corresponding to the required operation may not be transmitted to the server.

[0149] In addition, the vehicle terminal A process of starting the training mode in response to an operation input by the driver (S100-1 in the embodiment as an example); In the training mode, a process of setting a boarding location and a disembarking location (S100-3 and S100-5 are shown as examples in the embodiment); During the training mode, a process for enabling input of some or all of the necessary operations (S100-10 in the embodiment as an example); During the training mode, a process of transmitting part or all of the necessary information corresponding to the necessary operation to the server (S100-10 in the embodiment as an example); and The server The sales history may be generated excluding the necessary information transmitted during the training mode.

[0150] While the preferred embodiments of the present invention have been described above with reference to the accompanying drawings, it goes without saying that the present invention is not limited to such embodiments. It is clear that those skilled in the art can conceive of various modifications and alterations within the scope of the claims, and it is understood that such modifications and alterations also fall within the technical scope of the present invention.

[0151] Also provided are programs that cause a computer to function as a vehicle terminal, and computer-readable storage media on which the programs are recorded, such as flexible disks, magneto-optical disks, ROMs, CDs, DVDs, and BDs. Here, a program refers to a data processing means written in any language or description method.

[0152] The computer that performs each of the above processes may be an information processing system (vehicle dispatch management system 1) that is provided in a vehicle terminal and an external device (vehicle dispatch management server 60) that can communicate with the vehicle terminal. Also, the computer may be an information processing method that performs each of the above processes.

[0153] It should be noted that the processes shown in this specification do not necessarily have to be performed in chronological order according to the order shown in the flowcharts, and may include parallel or subroutine processes. [Explanation of symbols]

[0154] 1. Vehicle dispatch management system 4 NRS Driver 40 NRS terminals 42 NRS vehicles 60 Vehicle dispatch management server

Claims

1. a vehicle terminal operable by a driver; a server that receives information from the vehicle terminal; Equipped with The vehicle terminal A process for accepting necessary operations required of the driver during one driving period from when the user gets on board to when the user gets off the vehicle, the operation including at least a first operation required when the user gets on board and a second operation required when the user gets off the vehicle; a process of transmitting necessary information corresponding to the required operation, including first information corresponding to the first operation and second information corresponding to the second operation, to a server; A process for allowing a user to input a mileage of the vehicle at either one or both of the time of getting on and off the vehicle; a process of transmitting mileage information indicating the input mileage to the server; and The server A process of generating a predetermined business history based on the necessary information and the mileage information received from the vehicle terminal; To carry out the Information processing system.

2. The vehicle terminal A process of starting the training mode in response to an operation input from the driver; A process of setting a boarding location and a disembarking location in the training mode; a process for enabling acceptance of some or all of the required operations during the training mode; and During the training mode, some or all of the necessary information corresponding to the required operation is not transmitted to the server. The information processing system according to claim 1 .

3. The vehicle terminal A process of starting the training mode in response to an operation input from the driver; A process of setting a boarding location and a disembarking location in the training mode; a process for enabling acceptance of some or all of the required operations during the training mode; During the training mode, a process of transmitting a part or all of the necessary information corresponding to the necessary operation to the server; and The server generating the sales history by excluding the necessary information transmitted during the training mode; The information processing system according to claim 1 .

4. An information processing method performed by a vehicle terminal operable by a driver and a server that receives information from the vehicle terminal, The vehicle terminal A process for accepting necessary operations required of the driver during one driving period from when the user gets on board to when the user gets off the vehicle, the operation including at least a first operation required when the user gets on board and a second operation required when the user gets off the vehicle; a process of transmitting necessary information corresponding to the required operation, including first information corresponding to the first operation and second information corresponding to the second operation, to a server; A process for allowing a user to input a mileage of the vehicle at either one or both of the time of getting on and off the vehicle; a process of transmitting mileage information indicating the input mileage to the server; and The server A process of generating a predetermined business history based on the necessary information and the mileage information received from the vehicle terminal; To carry out the Information processing methods.

5. On the vehicle terminal that the driver can operate, A process for accepting necessary operations required of the driver during one driving period from when the user gets on board to when the user gets off the vehicle, the operation including at least a first operation required when the user gets on board and a second operation required when the user gets off the vehicle; a process of transmitting necessary information corresponding to the required operation, including first information corresponding to the first operation and second information corresponding to the second operation, to a server; A process for allowing a user to input a mileage of the vehicle at either one or both of the time of getting on and off the vehicle; a process of transmitting mileage information indicating the input mileage to the server; and A server that receives information from the vehicle terminal, A process of generating a predetermined business history based on the necessary information and the mileage information received from the vehicle terminal; To carry out the Information processing program.

Images