Information processing device, information processing method, and program

Abstract

To provide an information processing device, etc., that can suitably generate operational plans dynamically. [Solution] The information processing device acquires passenger information including the permissible time between the boarding or alighting time desired by the passenger and the boarding or alighting time at which the vehicle boards or alights the passenger. It generates a route plan that sets the boarding or alighting time within the range of the permissible time. If the passenger's boarding or alighting time in the generated route plan differs from the passenger's desired boarding or alighting time, the device sets the passenger's fare according to the permissible time. The device receives input from the passenger indicating whether they approve the route plan in which the difference between the passenger's boarding or alighting time and the passenger's desired boarding or alighting time is greater than or equal to the permissible time. If the device receives input indicating approval of the route plan, it generates a route plan in which the difference is greater than or equal to the permissible time.

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] In transportation means such as buses, a demand bus system has been proposed that dynamically plans an operation route in response to a use request from a passenger. For example, in Patent Document 1, there is disclosed a demand-type operation management system that generates a bus operation plan in response to a use request from a user, and generates an operation plan with a stop position at an intermediate point between a first boarding / alighting point where a first user boards and alights and a second boarding / alighting point where a second user boards and alights.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the invention according to Patent Document 1 generates an operation plan so that it can operate within a time-allowed range from an operation route predetermined in a standard operation schedule, and cannot generate an operation plan outside the allowable range.

[0005] In one aspect, an object is to provide an information processing apparatus or the like that can suitably perform dynamic generation of an operation plan.

Means for Solving the Problems

[0006] An information processing device relating to one aspect comprises an acquisition unit that acquires passenger information indicating the boarding or alighting point of a passenger using a vehicle and the boarding or alighting time of the passenger, and a generation unit that generates a plurality of operation plans for the vehicle indicating the route on which the passenger will board or alight, based on the passenger information, wherein the acquisition unit acquires the passenger information including the allowable time between the boarding or alighting time desired by the passenger and the boarding or alighting time at which the vehicle boards or alights the passenger, and the generation unit generates the operation plan that determines the boarding or alighting time within the range of the allowable time The system includes a setting unit that generates a picture and, if the passenger's boarding or alighting time in the operation plan generated by the generation unit differs from the passenger's desired boarding or alighting time, sets the passenger's fare according to the allowable time; and a receiving unit that receives input from the passenger indicating whether or not they approve the operation plan in which the difference between the passenger's boarding or alighting time and the passenger's desired boarding or alighting time is equal to or greater than the allowable time, and if input indicating approval of the operation plan is received, the generation unit generates the operation plan in which the difference is equal to or greater than the allowable time. [Effects of the Invention]

[0007] In one respect, it allows for the dynamic generation of operational plans to be performed effectively. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic diagram showing an example of the configuration of a train operation planning system. [Figure 2] This is a block diagram showing an example server configuration. [Figure 3] This is a block diagram showing an example of a terminal configuration. [Figure 4] This is an explanatory diagram showing an example of the record layout for the user database, bus database, driver database, and operation plan database. [Figure 5] This is an explanatory diagram showing an example of a location selection screen. [Figure 6] This is an explanatory diagram showing an example of a bus reservation screen. [Figure 7]It is an explanatory diagram related to the operation plan generation process. [Figure 8A] It is an explanatory diagram related to the update process of the operation plan. [Figure 8B] It is an explanatory diagram related to the update process of the operation plan. [Figure 9] It is an explanatory diagram showing an example of the reservation confirmation screen. [Figure 10] It is an explanatory diagram showing an example of the operation status confirmation screen. [Figure 11] It is a flowchart showing an example of the processing procedure executed by the server. [Figure 12] It is a flowchart showing an example of the processing procedure executed by the terminal. [Figure 13] It is an explanatory diagram showing the outline of Embodiment 2. [Figure 14] It is an explanatory diagram showing an example of the operation plan list screen. [Figure 15A] It is an explanatory diagram showing an example of the driver information display screen. [Figure 15B] It is an explanatory diagram showing an example of the driver information display screen. [Figure 16] It is an explanatory diagram showing an example of the display screen of the driver terminal. [Figure 17] It is a flowchart showing an example of the processing procedure executed by the business operator terminal. [Figure 18] It is a flowchart showing an example of the processing procedure executed by the driver terminal.

Modes for Carrying Out the Invention

[0009] Hereinafter, the present invention will be described in detail based on the drawings showing its embodiments. (Embodiment 1) FIG. 1 is a schematic diagram showing a configuration example of an operation planning system. In the present embodiment, an operation planning system that dynamically generates an operation plan for a vehicle (bus) in which a plurality of passengers share a ride will be described. The operation planning system includes an information processing device 1, user terminals 2, 2, 2..., buses 3, a business operator terminal 4, and a driver terminal 5. Each device is communicatively connected to each other via a network N such as the Internet. In the present embodiment, a bus is taken as an example of a vehicle, but the type of vehicle is not limited as long as it is a vehicle that can carry a plurality of passengers such as a passenger car or a shuttle even if it is not a bus.

[0010] In the present embodiment, an operation plan is generated for a bus 3 that travels back and forth between a predetermined departure point and a destination. For example, the bus 3 is a shuttle bus that departs from a hotel and has an airport as its destination, but the departure point and the destination are not particularly limited. In the present embodiment, in response to a usage request for the bus 3 from a user who is registered in advance as a member of this system, an operation plan in which the operation route, operation time, etc. of the bus 3 are dynamically changed is generated.

[0011] The information processing device 1 is an information processing device capable of various information processing and information transmission and reception, and is, for example, a server device, a personal computer, or the like. In the present embodiment, it is assumed that the information processing device 1 is a server device, and hereinafter, it will be read as server 1 for the sake of simplicity. The server 1 receives a usage request for the bus 3 from each user, generates an operation plan, and notifies the driver of the bus 3.

[0012] The user terminal 2 is a terminal device operated by a user (passenger) who uses this system, and is, for example, a portable terminal such as a smartphone or a tablet terminal. An application program for realizing the functions related to this system is installed in advance in the user terminal 2, and the user terminal 2 executes the application program to perform the following-described processing. The server 1 receives a usage request from the user terminal 2 and generates an operation plan.

[0013] Bus 3 is a shuttle bus that travels back and forth between the departure point and the destination, as described above, and is a demand bus driven by a driver according to instructions from Server 1. Note that Bus 3 is not limited to a vehicle called a demand bus; any vehicle that operates according to instructions from Server 1 is acceptable. Also, although only one Bus 3 is shown in Figure 1 for illustrative purposes, this embodiment generates operation plans for multiple Buses 3. For example, Server 1 is a mobile device that the driver carries It communicates with a mobile terminal (driver's terminal 5), etc., to notify the driver of the bus's operation plan, and also provides the bus's location information (e.g., GPS (Global Positioning System) coordinates). It acquires and manages the data sequentially.

[0014] Operator terminal 4 is a terminal device of the operating company (bus company) that operates bus 3, and is, for example, a personal computer. Driver terminal 5 is a terminal device carried by the driver of each bus 3, and is, for example, a smartphone or tablet. Server 1 notifies operator terminal 4, driver terminal 5, etc., of the operation plan generated in response to the user's request, and operates bus 3.

[0015] Furthermore, the operating company that operates bus 3 in cooperation with this system may be a single entity or multiple entities. In addition, in this embodiment, when coordinating with the driver of bus 3, communication is performed with the driver's terminal 5, which is a mobile terminal, but it may also be possible to communicate with an in-vehicle system installed on bus 3 and notify the driver of the operation plan.

[0016] Figure 2 is a block diagram showing an example configuration of Server 1. Server 1 comprises a control unit 11, a main memory unit 12, a communication unit 13, and an auxiliary memory unit 14. The control unit 11 has one or more arithmetic processing units such as a CPU (Central Processing Unit), MPU (Micro-Processing Unit), and GPU (Graphics Processing Unit), and performs various information processing, control processing, etc. by reading and executing the program P1 stored in the auxiliary storage unit 14. The main memory unit 12 has SRAM (Static Random Access Memory), D The RAM (Dynamic Random Access Memory) and flash memory are temporary storage areas that temporarily store data necessary for the control unit 11 to perform calculations. The communication unit 13 is a communication module for performing communication-related processing and for sending and receiving information with the outside world.

[0017] The auxiliary storage unit 14 is a non-volatile storage area such as a large-capacity memory or hard disk, and stores the program P1 and other data necessary for the control unit 11 to execute processing. The auxiliary storage unit 14 also stores the user DB 141, bus DB 142, driver DB 143, and operation plan DB 144. The user DB 141 is a database that stores user information. The bus DB 142 is a database that stores information about bus 3. The driver DB 143 is a database that stores information about the driver who operates bus 3. The operation plan DB 144 is a database that stores information about the operation plan of bus 3.

[0018] The auxiliary storage unit 14 may be an external storage device connected to the server 1. Furthermore, the server 1 may be a multi-computer system consisting of multiple computers, or it may be a virtual machine virtually constructed by software.

[0019] Furthermore, in this embodiment, the server 1 is not limited to the above configuration and may include, for example, an input unit for receiving operation input, a display unit for displaying images, etc. The server 1 may also include a read unit for reading portable storage media 1a such as a CD (Compact Disk)-ROM or DVD (Digital Versatile Disc)-ROM, and may read and execute the program P1 from the portable storage media 1a. Alternatively, the server 1 may read the program P1 from a semiconductor memory 1b.

[0020] Figure 3 is a block diagram showing an example configuration of user terminal 2. User terminal 2 comprises a control unit 21, a main memory unit 22, a communication unit 23, a display unit 24, an input unit 25, a location information acquisition unit 26, and an auxiliary storage unit 27. The control unit 21 has one or more arithmetic processing units such as CPUs and MPUs, and performs various information processing and control processing related to the user terminal 2 by reading and executing the program P2 stored in the auxiliary storage unit 27. The main memory unit 22 is a temporary storage area such as RAM, and control The control unit 21 temporarily stores the data necessary for the control unit to perform calculations. The communication unit 23 includes an antenna, processing circuitry, etc., for communication and transmits and receives information with the outside. The display unit 24 is a display device such as a liquid crystal display or an organic EL (Electro-Luminescence) display and displays images provided by the control unit 21. The input unit 25 is an operation interface such as a touch panel or mechanical keys and inputs operation content to the control unit 21. The location information acquisition unit 26 is a communication module that acquires the location information (e.g., GPS coordinates) of the user terminal 2. The auxiliary storage unit 27 is a non-volatile storage area such as ROM (Read Only Memory) and stores the program P2 and other data necessary for the control unit 21 to perform processing.

[0021] The user terminal 2 may also be equipped with a reading unit for reading the portable storage medium 2a, and may read and execute the program P2 from the portable storage medium 2a. Alternatively, the user terminal 2 may read the program P2 from the semiconductor memory 2b.

[0022] Figure 4 is an explanatory diagram showing an example of the record layout for User DB141, Bus DB142, Driver DB143, and Operation Plan DB144. User DB141 includes User ID, Username, Address, and User Information columns. The User ID column stores the User ID used to identify each user. The Username, Address, and User Information columns store the user's name, email address, and other user information, respectively, in association with the User ID. The User Information column stores attribute information (passenger attribute information) such as the user's age, gender, nationality, affiliated organization (company, etc.), hobbies, residential area, and user rank (customer quality based on frequency of use of Bus 3, etc.).

[0023] Bus DB142 includes columns for Bus ID, Operating Company, and Bus Information. The Bus ID column stores the Bus ID used to identify each bus 3. The Operating Company column and Bus Information column store the name of the operating company (operator) and information about bus 3, respectively, in association with the Bus ID. The Bus Information column stores attribute information (vehicle attribute information) such as the passenger capacity and seat number of bus 3, as well as the vehicle rank representing the evaluation value of bus 3, the seat rank representing the evaluation value of each seat, whether or not it is a women-only vehicle, whether or not it is a welfare vehicle, and the services provided on board (e.g., tourist guide service, massage service, nail service, etc.).

[0024] The driver database 143 includes columns for driver ID, driver name, assigned bus, and driver attributes. The driver ID column stores the driver ID to identify the driver operating bus 3. The driver name, assigned bus, and driver attributes columns each store the driver's name, the bus ID of the bus 3 they are operating, and other information about the driver, corresponding to the driver ID. The driver attributes column stores driver attribute information such as the languages ​​the driver can converse in, the driver's rating from users, and gender.

[0025] The operation plan DB144 includes columns for bus ID, current location, and operation plan. The bus ID column stores the bus ID used to identify each bus 3. The current location column and operation plan column store information about the current location of bus 3 and the operation plan of bus 3, respectively, associated with the bus ID. For example, the operation plan column stores information such as the location of each point, the estimated arrival time, and the number of passengers boarding and alighting at each point where bus 3 is scheduled to stop (point 1, point 2, etc.).

[0026] Figure 5 is an explanatory diagram showing an example of the location selection screen. The outline of this embodiment will be described below. As described above, Bus 3 is a shuttle bus that travels back and forth between the departure point and the destination. It picks up passengers at the departure point and heads to the destination, and then picks up passengers again at the destination and returns to the departure point. However, the points where Bus 3 stops are not limited to just the departure point and the destination, but also include the departure point and Passengers may be allowed to board or alight at other points between the destinations. Server 1 receives bus usage requests from each user's user terminal 2 and generates a route plan that defines the outbound journey to the destination and the return journey back to the starting point.

[0027] User terminal 2 first displays the location selection screen shown in Figure 5 and accepts input from the user specifying the desired boarding location and the desired alighting location. For convenience, in the following explanation, the desired boarding location and the desired alighting location will be collectively referred to simply as "desired location." For example, user terminal 2 displays a map image on the location selection screen and accepts input from the user specifying the desired location. Alternatively, user terminal 2 may accept text input for the desired location, have server 1 search for candidate locations based on the entered text, and accept input from the candidate locations to specify the desired location. User terminal 2 may also display multiple locations that have been registered as candidate locations in advance and accept input from the displayed candidate locations to specify the desired location. Furthermore, user terminal 2 may determine the user's current location based on location information acquired via location information acquisition unit 26 and specify the user's current location as the desired boarding location.

[0028] Figure 6 is an explanatory diagram showing an example of a bus reservation screen. After completing the input of the desired location on the location selection screen, user terminal 2 transitions to the bus reservation screen shown in Figure 6. User terminal 2 displays a map image at the top of the bus reservation screen showing the departure and destination of bus 3. User terminal 2 also displays a time icon 61, a luggage icon 62, and a passenger icon 63 on the bus reservation screen.

[0029] First, when user terminal 2 receives input to the time icon 61, it displays a time specification field 64 as a pop-up. User terminal 2 accepts input of the desired boarding time or desired alighting time via the time specification field 64. The desired boarding time and desired alighting time are the time the user wishes to board bus 3 and the time the user wishes to alight from bus 3 at the destination. For example, user terminal 2 accepts input for either the desired boarding time or the desired alighting time. For convenience, in the following explanation, the desired boarding time and desired alighting time will be collectively referred to simply as "desired time".

[0030] Furthermore, when user terminal 2 receives input for the luggage icon 62 or the number of people icon 63, it displays a luggage / number of people specification field 65 as a pop-up. User terminal 2 accepts input from the user regarding the luggage information (for example, type of luggage (bag, suitcase, etc.), weight, size, number, etc.) and the number of users riding the train through the luggage / number of people specification field 65.

[0031] As described above, Server 1 acquires various information entered into User Terminal 2, namely passenger information such as desired location, desired time, luggage information, and number of passengers, from User Terminal 2 and accepts the request for use. Based on the acquired passenger information, Server 1 generates an operation plan that defines the route each bus 3 will take as it picks up or drops off users (passengers).

[0032] In this embodiment, bus 3 is assumed to carry only the user (and their luggage), but this embodiment is not limited to this, and requests for the transport of luggage only may also be accepted. The luggage referred to here includes luggage unrelated to the passengers of bus 3, such as luggage of a user who does not ride bus 3 but wishes to have their luggage transported to a hotel. For example, in addition to the passenger information mentioned above, server 1 receives a request from user terminal 2 for the transport of luggage that the user wishes to have transported to a destination (including, for example, the place of origin, destination, desired departure time, desired arrival time, etc.). In this case, server 1 treats the luggage as one of the items being transported, just like the passengers (users), and generates an operation plan by performing the clustering described below. Thus, server 1 may generate an operation plan that transports luggage in addition to the user.

[0033] Figure 7 is an explanatory diagram regarding the operation plan generation process. Based on Figure 7, the overview of the operation plan generation process will be explained. Server 1 obtains passenger information (first passenger information), including the desired location and time, from each user's user terminal 2, 2, 2... Server 1 performs clustering, classifying each user into multiple clusters (sets) based on the desired location and time indicated by the passenger information from each user.

[0034] Figure 7 conceptually illustrates the vector space involved in clustering. In Figure 7, the horizontal axis represents time, and the vertical axis represents geographical space (location). The upper part of the horizontal axis represents the vector space for the outward journey, and the lower part represents the vector space for the return journey. The dotted lines on the vertical axis represent the boundaries of time periods divided into predetermined intervals (e.g., 30 minutes). In practice, clustering is performed in a multidimensional space of three or more dimensions, but for the sake of illustration, the vector space is shown in two dimensions in Figure 7.

[0035] Server 1 maps each user to a vector space based on their desired location and time. Server 1 then performs clustering, grouping one or more users into predetermined time intervals, and generates clusters. The clustering method is not particularly limited, but for example, Server 1 generates clusters using methods such as the k-means method or the c-means method.

[0036] The reason why Server 1 performs clustering at predetermined time intervals is that, in this embodiment, airport transfers are assumed, and the transfers are completed at a predetermined time before the aircraft's departure and arrival times. By generating clusters at predetermined time intervals, transfers to destinations can be efficiently performed.

[0037] In this embodiment, since bus 3 is a shuttle bus that travels back and forth between a departure point and a destination, server 1 clusters users who ride on the outbound journey and users who ride on the return journey separately. That is, when server 1 obtains passenger information from user terminal 2 that the destination of bus 3 is the desired disembarking point, it maps the user of user terminal 2 to the vector space on the outbound side and performs clustering. When server 1 obtains passenger information from user terminal 2 that the destination of bus 3 is the desired boarding point, it maps the user of user terminal 2 to the vector space on the return journey and performs clustering.

[0038] Server 1 groups one or more users whose desired locations and times are close together and creates a cluster. Based on the clustering results, Server 1 generates a route plan for each bus 3.

[0039] Specifically, Server 1 assigns a bus 3 to each cluster and generates a route plan to have each user board the bus for each cluster. For example, as shown in Figure 7, Server 1 assigns one bus 3 to a cluster for the outbound (or return) route in a certain time period, then selects a cluster for the return route to be assigned to that bus 3 in the next time period, and operates the bus to allow users belonging to that cluster to board and alight. Furthermore, Server 1 selects a cluster for the outbound route in the next time period and operates the bus. Server 1 assigns clusters to each of the multiple buses 3, 3, 3... that are instructed to operate by this system, and generates a route plan to have users board the bus for all clusters.

[0040] For example, if each user in the cluster has a different desired destination, Server 1 determines the boarding or alighting point (hereinafter referred to as "boarding / alighting point") and the boarding or alighting time (hereinafter referred to as "boarding / alighting time") for each user, and estimates the optimal route for operation while picking up or alighting each user. Server 1 estimates the optimal route for each cluster and completes the operation plan.

[0041] In this embodiment, Server 1 generates the above-mentioned operation plan using the Traveling Salesperson Problem method. That is, given multiple buses 3, 3, 3..., Server 1 generates the operation plan by reducing it to a combinatorial optimization problem that finds the optimal combination for getting all users on and off using buses 3, 3, 3.... For example, Server 1 calculates a cost value for evaluating the operation plan based on each user's waiting time, the waiting time of bus 3 between clusters, the operating time of bus 3, the operating distance, etc. Server 1 generates the operation plan so as to minimize the cost value.

[0042] In this case, server 1 may set constraints on the total operating time of each bus 3, the number of round trips between the departure point and the destination, etc., and generate an operation plan under these constraints. This allows for effective management of the working environment of the bus drivers.

[0043] Furthermore, it is preferable for Server 1 to generate an operation plan for each bus 3 based on the number of buses 3 that are not carrying passengers out of all the buses 3, 3, 3.... Buses 3 that are not carrying passengers include, for example, buses 3 that are waiting at a designated vehicle depot and not in operation, buses 3 that are waiting on the road without passengers, and buses 3 that are operating without passengers (buses 3 that are out of service). For example, Server 1 generates an operation plan that reduces the overall number of buses in operation by calculating a lower cost value the more buses waiting at the vehicle depot are. Alternatively, for example, Server 1 generates an operation plan that reduces waste in bus operations by calculating a lower cost value the fewer buses 3 are waiting on the road or the fewer buses 3 are operating without passengers. This eliminates imbalances in passenger numbers and allows for appropriate operation of buses 3.

[0044] The traveling salesman problem is just one example of a method for optimizing the operation plan, and Server 1 may optimize the operation plan based on other algorithms.

[0045] The operation plan may be generated only once, or it may be generated multiple times periodically or in response to changes in the reservation status. For example, Server 1 generates an operation plan and confirms the reservation for users who have made a reservation via the bus reservation screen by a predetermined reservation confirmation time (for example, by the deadline for ordering the number of buses to be arranged with the bus operator on the day of operation (for example, 0:00 AM on the day of operation)). In this case, Server 1 repeatedly generates clusters until the schedule confirmation time and generates operation plans sequentially. For example, even if Server 1 has already classified users A and B into a certain cluster and generated an operation plan, if it receives a new request (reservation) for the use of bus 3 from user C, and it is cheaper to exclude user B and classify users A and C into the same cluster, Server 1 will perform clustering again, classifying users A and C into the same cluster. In this way, Server 1 repeatedly changes the groups (clusters) to which users belong and generates operation plans sequentially. After the reservation confirmation time has passed, there will be no group changes for users who have already made reservations, and the operation plan update process described later will be performed within the scope where no group changes occur.

[0046] When generating the above-mentioned route plan, Server 1 may generate a route plan in which the boarding and alighting times for the user are different from the desired times specified by the user. For example, when Server 1 receives a request for use, it accepts input for the allowable time range that the user is willing to accept from the desired time, and obtains this as passenger information from User Terminal 2. As shown in Figure 7, Server 1 changes the user's position in the vector space within the allowable time range and determines the bus 3 on which the user will board.

[0047] In this case, as will be described later, it is preferable for server 1 to vary the user's fare according to the allowable time. This makes it easy to optimize the operation plan.

[0048] Furthermore, Server 1 may set the boarding or alighting point for users to be different from the user's desired location, not only for boarding and alighting times. For example, Server 1 may set a different location for boarding if it shortens the travel time by more than the standard time. For example, if the user's desired boarding point is on one lane of a road, and it shortens the travel time to board at a point on the opposite lane, Server 1 will set the point on the opposite lane as the boarding point. Alternatively, Server 1 may set the boarding point to the point closest to the user's desired boarding point on the current route of Bus 3. In this case, the boarding point may be a landmark on a map (intersection, facility, etc.).

[0049] In this case, for example, server 1 preferably notifies user terminal 2 of the actual boarding location, as will be described later. This makes it easy to guide the user to the boarding location.

[0050] Furthermore, Server 1 may assign (match) users to buses 3 by referring to information other than the desired location and time, and generate a route plan. For example, Server 1 may cluster (classify) each user based on attribute information such as age, gender, and nationality (passenger attribute information) and select a bus 3 for the user to board. For example, Server 1 may match the attribute information of users, classify users with the same or similar attribute information into the same cluster, and assign them to buses 3. This allows for the operation of buses 3 as appropriate, such as by providing women-only carriages.

[0051] The above is merely one example of assignment using user attribute information, and this embodiment is not limited to this. For example, Server 1 may prevent users from being assigned to the same bus 3 if they belong to the same organization (company, etc.). Alternatively, Server 1 may prioritize assigning users with common hobbies to the same bus 3. Or, Server 1 may prioritize assigning users with a high rank (customer quality). As such, various methods can be considered for assignment based on user attribute information.

[0052] Furthermore, for example, Server 1 may perform clustering based not only on user attribute information but also on the attribute information of the bus driver (driver attribute information) and assign buses 3 accordingly. Driver attribute information includes, for example, the driver's skills (languages ​​they can converse, etc.) and user ratings. For example, Server 1 matches the user attribute information with the driver attribute information and selects a bus 3 for the user to ride. This allows for appropriate operation, such as assigning a bus 3 with a driver who can converse in a language corresponding to the user's nationality if the user is a foreign tourist.

[0053] Alternatively, for example, Server 1 may perform clustering based on the attribute information (vehicle attribute information) of Bus 3 itself and assign Bus 3. The attribute information of Bus 3 may include, for example, the vehicle rank representing the evaluation value of Bus 3, the seat rank representing the evaluation value of each seat, whether or not it is a women-only vehicle, whether or not it is a welfare vehicle, and the services provided on board. For example, if Server 1 obtains desired conditions such as the vehicle rank and seat rank of Bus 3 as passenger information from User Terminal 2, it will match them with the attribute information of Bus 3 and select Bus 3.

[0054] In performing the above matching (clustering), for example, when Server 1 receives a request from User Terminal 2, it may accept input of desired conditions for passengers, drivers, buses 3, etc., and perform matching according to the desired conditions. Alternatively, for example, Server 1 may automatically perform matching by referring to attribute information stored in each database such as User DB141, Bus DB142, Driver DB143, etc., without accepting input of desired conditions.

[0055] Figure 8 is an explanatory diagram regarding the operation plan update process. In this embodiment, Server 1 continuously receives usage requests from User Terminal 2 and updates the operation plan in real time. Figure 8 conceptually illustrates the operation plan update process.

[0056] Figure 8A conceptually illustrates the process when the operating plan is changed and a newly requested user is added to bus 3. When the server 1 obtains passenger information (second passenger information) for a new user from user terminal 2, the server 1 determines whether the new user should be classified into the cluster of users who have already booked bus 3, based on the desired location and time indicated by the newly obtained passenger information. That is, as shown by the thick line in Figure 8A, the server 1 maps the new user into a vector space based on the desired location and time, and performs clustering to determine whether the user belongs to the cluster of users who have already booked and whether they belong to the cluster for which an operating plan has already been generated. If the user is classified into the generated cluster, the server 1 changes the route, operating time, etc. related to the operating plan of that cluster and updates the operating plan to allow the user to board.

[0057] Figure 8B conceptually illustrates the process by which bus 3 dynamically generates the cluster of users it will next board. As described above, server 1 assigns bus 3 to each cluster and generates a bus operation plan for each cluster. In this embodiment, server 1 generates the next cluster following the first cluster at a predetermined timing after bus 3 has started operating according to the operation plan for at least one cluster, assigns bus 3 to that cluster, and generates the next operation plan.

[0058] For example, after the completion of an operation plan related to a cluster, or at a time between the start of an operation according to the said operation plan and its completion, Server 1 performs clustering for users whose desired time is the next time slot after the current time slot, and creates a new cluster. In this case, Server 1 performs clustering including the new user, to the extent that it does not cause a change in the group (cluster) of the reserved user. From the newly created cluster, Server 1 selects the cluster to which Bus 3 should be assigned next and generates an operation plan for the selected cluster. As a result, Server 1 updates the operation plan, notifies the driver of the operation route, operation time, etc. related to the updated operation plan, and operates Bus 3.

[0059] In this way, by having server 1 generate the next cluster after bus 3 starts operating for one cluster, it is possible to include as many newly requested users as possible in the next operating plan, and thus the operating plan can be updated appropriately.

[0060] Returning to Figure 6, let's continue the explanation. Once the user has finished specifying the desired time, luggage information, number of passengers, etc., the user terminal 2 sends the user's passenger information to the server 1. In this case, as described above, the server 1 generates a route plan based on the passenger information of each passenger, including the user. The user terminal 2 retrieves the information (route information) for the reserved bus 3 from the server 1 according to the generated route plan and displays it on the bus reservation screen.

[0061] For example, user terminal 2 displays the name of the reserved bus 3, as well as the fare. User terminal 2 also displays the route of bus 3 on a map image. More specifically, in addition to the route, user terminal 2 displays the travel time and fare if the user takes bus 3, as well as the travel time and fare if the user uses other means of transportation (e.g., a taxi).

[0062] In this case, if server 1 generates a travel plan in which the user's boarding and alighting times differ from the desired times, it sets the fare to a discounted amount from the standard fare according to the acceptable time allowed by the user, and displays the discounted fare on user terminal 2. This makes it easier to optimize the travel plan.

[0063] In this embodiment, a service plan is generated in which the boarding and alighting times differ from the desired times when the difference between the boarding and alighting times and the desired times is within the allowable time. However, this embodiment is not limited to this. For example, even if the difference exceeds the allowable time, Server 1 may generate a service plan in which the difference between the boarding and alighting times and the desired times exceeds the allowable time if it outputs the discounted amount to User Terminal 2 and obtains approval from the user.

[0064] Figure 9 is an explanatory diagram showing an example of a reservation confirmation screen. In the bus reservation screen of Figure 6, user terminal 2 receives input from the user indicating whether or not to reserve the displayed bus 3 and notifies server 1. If the reservation is made, server 1 notifies driver terminal 5 of the route and other details to start the operation. User terminal 2 transitions from the bus reservation screen to the reservation confirmation screen of Figure 9, and the user is informed that the reservation for bus 3 is complete.

[0065] In this embodiment, reservation confirmation is received only from the user (passenger), but it is preferable to also receive confirmation (approval) from the bus operator, as described in Embodiment 3 below. The processing on the GUI (Graphical User Interface) for the bus operator and individual drivers will be explained in detail in Embodiment 3.

[0066] Figure 10 is an explanatory diagram showing an example of a bus operation status confirmation screen. After displaying the reservation confirmation screen in Figure 9, the user terminal 2 transitions to the bus operation status confirmation screen in Figure 10, and while communicating with the server 1, displays the real-time operation status (operation information) of the reserved bus 3.

[0067] For example, as shown in the operation status confirmation screen on the left side of Figure 10, user terminal 2 displays a map image, and on the map image, it displays a user icon 101 indicating the user's current location and a stop location icon 102 indicating the planned stopping location (boarding point) of bus 3. As described above, if an operation plan is generated with a boarding point different from the desired boarding point requested by the user, as shown in Figure 10, server 1 notifies user terminal 2 of the actual boarding point and displays the stop location icon 102, thereby enabling smooth operation of bus 3. Furthermore, displaying the user's current location at the same time can further improve the smooth operation of bus 3.

[0068] Furthermore, user terminal 2 displays both the current location of bus 3 and the estimated arrival time calculated from the distance between the bus 3's current location and its planned stopping location. When bus 3 moves to the location shown on the map image, user terminal 2 displays a bus icon 103 indicating the bus 3's current location, as shown in the operation status confirmation screen on the right side of Figure 10.

[0069] Furthermore, for example, user terminal 2 displays the bus information section 104 at the bottom of the screen, showing information about the reserved bus 3 (e.g., vehicle registration number). Also, for example, user terminal 2 displays a call icon 105 and a message icon 106 within the bus information section 104 for contacting the bus 3 driver. When user terminal 2 receives input to the call icon 105 or message icon 106, it makes a call or sends / receives a message to the driver terminal 5 via server 1. In addition, when user terminal 2 receives an upward swipe operation on the bus information section 104, it displays the number of passengers, luggage information, destination or departure point, fare, etc., that were registered at the time of reservation.

[0070] In the above description, Server 1 notifies and displays the operating status of Bus 3 to the user terminal 2 of the user who has reserved Bus 3, but this embodiment is not limited to this. For example, Server 1 may also notify the operating status to the user terminal 2 of other users (potential passengers) who have not reserved Bus 3 and accept requests to use Bus 3. For example, Server 1 refers to the generated operating plan and determines the availability of seats on Bus 3 in operation. If it is determined that there are seats available, Server 1 displays the current location of Bus 3, the destination, and the availability of seats. The number of passengers and other information are notified to other users' terminals 2, and usage requests are accepted. Alternatively, server 1 may output the information to a website, an electronic display board installed in a designated location, a travel tour company, etc., and accept usage requests. In this way, by outputting the availability status of bus 3 and accepting usage requests from the output destination, users can make appropriate usage requests, such as when they suddenly want to use bus 3, by considering the availability of buses currently in operation.

[0071] Furthermore, when notifying users of the availability of bus 3, server 1 may, for example, obtain the user's schedule from an external API (scheduler) to determine whether or not they are likely to board, and then notify users who are determined to be likely to board of bus 3 of the availability. Whether or not a user is likely to board can be determined, for example, by whether or not they have plans to board or disembark from an airplane, whether or not they have plans to attend an event, or whether or not they have checked in or checked out of a hotel. This makes it possible to effectively encourage the use of bus 3.

[0072] Figure 11 is a flowchart showing an example of the processing procedure performed by Server 1. Based on Figure 11, the processing details performed by Server 1 will be explained. Server 1 obtains passenger information (first passenger information) from each user's user terminal 2, 2, 2... and accepts the request for use (step S11). The passenger information includes at least the desired location (desired boarding location or desired alighting location) and the desired time (desired boarding time or desired alighting time). More specifically, in addition to the desired location and desired time, the passenger information includes the number of passengers boarding and alighting, luggage information, and the allowable time between the desired time and the actual boarding time.

[0073] Server 1 classifies each user into multiple clusters (groups) based on their desired location and time (step S12). Server 1 then assigns a bus 3 to each cluster and generates a route plan for each cluster to pick up and drop off users (step S13). In this case, Server 1 may also refer to passenger attribute information, driver attribute information, vehicle attribute information, etc., in addition to the desired location and time, to select the bus 3 to pick up the users and generate the route plan.

[0074] Server 1 sets the fare according to the generated operation plan and notifies user terminal 2 of bus 3 information (operation information) including the fare (step S14). For example, if the time the user boards bus 3 differs from the desired time, Server 1 sets the fare according to the allowable time set by the user. In addition to the fare, Server 1 notifies user terminal 2 of information such as the route and duration of bus 3 and receives a response from whether or not to confirm the reservation for bus 3. If Server 1 receives a response from user terminal 2 confirming the reservation for bus 3, Server 1 confirms the operation plan and notifies driver terminal 5 of the route, etc. (step S15).

[0075] Server 1 then acquires passenger information (second passenger information) from a new user terminal 2 of a different user (a passenger who has already made a reservation) from the user whose request was received in step S11, and accepts the request (step S16). Based on the newly acquired passenger information, Server 1 determines whether or not the user should be classified into an already created cluster (step S17). If it is determined that the user should be classified into an already created cluster (S17: YES), Server 1 updates the bus operation plan for the bus 3 corresponding to the cluster that it determined should be classified into by changing the route, operating time, etc. to accommodate the user (step S18).

[0076] After completing the process in step S18, or if the answer in step S17 is NO, server 1 determines whether it is the predetermined timing to generate the next operation plan for bus 3 (step S19). The timing used as the criterion in step S19 is at least the time after bus 3 has started operating in accordance with the current operation plan to pick up and drop off users of the assigned cluster. For example, server 1 determines whether it is the time when bus 3 has completed its operation for the operation plan related to the cluster, or the time between the start of operation and the completion of operation.

[0077] If it determines that it is time to generate the next operation plan (S19: YES), Server 1 performs clustering, classifying users who have made reservations but have not yet been picked up, and users whose passenger information was newly acquired in step S16, into multiple clusters, and generates new clusters (step S20). Then, Server 1 assigns Bus 3 to the newly generated cluster and generates a new operation plan (step S21).

[0078] Server 1 determines whether a predetermined termination condition (e.g., end of business hours) for ending the operation of bus 3 has been met (step S22). If the answer in step S19 or S22 is NO, Server 1 returns to step S16. If the answer in step S22 is YES, Server 1 terminates the series of processes.

[0079] Figure 12 is a flowchart illustrating an example of the processing steps performed by user terminal 2. Based on Figure 12, the processing details performed by user terminal 2 will be explained. User terminal 2 displays a location input screen, accepts input for the desired location, and sends it to server 1 (step S41). User terminal 2 then transitions to the bus reservation screen, accepts input for the desired time, number of passengers, luggage information, etc., and sends it to server 1 (step S42).

[0080] User terminal 2 obtains information about the bus 3 to be dispatched to the user (operation information) from server 1, which generated the operation plan based on the information entered in steps S41 and S42, and displays it on the bus reservation screen (step S43). For example, in addition to the fare and travel time of bus 3, user terminal 2 displays the fare and travel time of other modes of transportation. User terminal 2 determines whether or not to confirm the reservation for bus 3 according to the user's input (step S44).

[0081] If it is determined that the reservation should be confirmed (S44: YES), the user terminal 2 displays the reservation confirmation screen, then transitions to the dispatch status confirmation screen and displays the current operating status (operation information) of bus 3 (step S45). For example, the user terminal 2 displays the user's current location, the boarding location where the user will board bus 3, the arrival time of bus 3, the current location of bus 3, etc. The user terminal 2 determines whether bus 3 has arrived at the boarding location and whether the user has boarded (step S46). If it is determined that the user has not boarded (S46: NO), the user terminal 2 returns to step S45 and continues to display the operation status. If the answer in step S44 is NO, or in step S46 is YES, the user terminal 2 terminates the series of processes.

[0082] Based on the above, according to this embodiment 1, a suitable dynamic generation of a bus operation plan can be performed based on passenger information (first passenger information) of users (passengers) who have already made a reservation to use bus 3 and passenger information (second passenger information) of users who have newly requested to use bus 3.

[0083] Furthermore, according to this embodiment 1, clustering is performed based on the boarding and alighting points and boarding and alighting times indicated by the passenger information, and an operation plan is generated for each cluster, thereby enabling the creation of a suitable operation plan for a bus 3 shared by multiple users.

[0084] Furthermore, according to this embodiment 1, it is possible to determine whether or not a newly requested user should be classified into an existing cluster, and if it is determined that the user should be classified, the operation plan of the cluster is updated to allow the user to board or alight, thereby enabling the real-time updating of the operation plan.

[0085] Furthermore, according to this embodiment 1, a more suitable operation plan can be generated by selecting the bus 3 to which the user boards and alights according to attribute information such as the user (passenger), driver, and bus 3 (vehicle).

[0086] Furthermore, according to this embodiment 1, it is possible to dynamically generate the outbound and return travel plans for a bus 3 that travels back and forth between a predetermined departure point and destination.

[0087] Furthermore, according to this embodiment 1, by generating an operation plan for a plurality of buses 3, 3, 3... according to the number of buses 3 that have no passengers, the overall operation efficiency of buses 3, 3, 3... can be optimized.

[0088] Furthermore, according to this embodiment 1, when passengers are picked up at a boarding location different from their desired boarding location, the actual boarding location can be notified to the user, thereby improving user convenience.

[0089] Furthermore, according to this embodiment 1, by setting a tolerance time between the desired boarding / alighting time and the actual boarding / alighting time, it is possible to easily optimize the operation plan. In addition, by varying the fare according to the tolerance time, an incentive can be provided for users to cooperate in optimizing the operation plan.

[0090] Furthermore, according to this embodiment 1, user convenience can be improved by notifying users who have not made a reservation for bus 3 of the operating status of bus 3, including the availability of seats.

[0091] (Variation 1) Embodiment 1 described how a bus schedule is generated upon receiving a request to use bus 3 from a new user other than a user who has already made a reservation. However, this new user may not only be a user who is currently making a request (reservation) to use bus 3, but also a user who is expected to use bus 3.

[0092] For example, Server 1 may predict the demand for Bus 3 from other users (new users) who are expected to use Bus 3, in addition to users who have already made reservations, and generate an operation plan from the predicted demand. This demand is a predicted value that predicts the inflow and outflow of users at, for example, a departure point (hotel, etc.), a destination (airport, etc.), and other locations. Taking a hotel as an example, Server 1 predicts the desired location and time (second passenger information) of usage requests received from users staying at the hotel, based on the check-in or check-out times at the hotel, the number of hotel rooms, etc. Similarly, taking an airport as an example, Server 1 predicts the desired location and time of usage requests received from users using the airport, based on the flight schedule. Server 1 obtains demand information related to these demand values ​​from external systems (e.g., travel sites, flight reservation sites, etc.) and uses it to generate the operation plan.

[0093] Specifically, Server 1 determines the number of buses to operate based on the level of demand and generates a service plan that uses that number of buses. For example, on days and times with high demand, Server 1 increases the number of buses and distributes users across buses 3, 3, 3... to accommodate new requests for use on the same day. On days and times with low demand, Server 1 reduces the number of buses and generates a service plan that increases the number of passengers per bus, thereby reducing the number of buses 3, 3, 3... that need to be secured.

[0094] Although the above explanation described the demand information for bus 3 using hotels and airports as examples, this embodiment is not limited to these examples. The demand information can be any data that can predict usage requests from new users. For example, server 1 may predict demand values ​​from past operation plans and use them to generate new operation plans without acquiring demand information via an external system.

[0095] Furthermore, for example, Server 1 may predict the supply value (supply information) of Bus 3, rather than the demand value of Bus 3, to determine whether it is possible to accommodate new users boarding or alighting, and use this prediction in the operation plan. The supply value of Bus 3 could be, for example, the occupancy rate of each Bus 3, or the total number of Buses 3, 3, 3... in operation, and is data indicating the supply capacity of Bus 3, indicating whether it is possible to accommodate all users boarding or alighting by Bus 3. For example, Server 1 could refer to past operation plans to predict the occupancy rate and number of Buses 3 in operation for each time period, and generate an operation plan for each time period from the predicted occupancy rate, etc. This would allow Server 1 to generate an appropriate operation plan, for example, by not filling Bus 3 to capacity in certain time periods, but leaving a certain number of empty seats.

[0096] As described above, Server 1 may generate a route plan based on demand or supply information for Bus 3 from new users. In this case, it is preferable for Server 1 to set the user's fare according to the demand or supply information. For example, Server 1 may set a higher fare during times when demand is high and many users are expected to use the service. Also, for example, Server 1 may set a higher fare during times when supply is low and few seats are expected to be available on Bus 3. This is expected to distribute the usage frequency of each user and ensure smooth operation of Bus 3.

[0097] (Modification 2) Embodiment 1 described a scenario in which the user travels the entire route from one point (boarding point) to another point (disembarking point) by bus 3. However, it is also possible to combine public transportation other than bus 3 for part of the journey from one point to the other point.

[0098] Public transportation includes, for example, airplanes and trains, but is not limited to any means of transport other than bus 3. Server 1 may generate a travel plan on the assumption that the user will use these public transportation options.

[0099] For example, if it is cheaper for the user to travel part of the distance between their desired pick-up and drop-off points by public transport, Server 1 suggests to the user that they use a combination of public transport and Bus 3. For example, when Server 1 obtains the user's passenger information (desired location, desired time, etc.) and accepts a request to use Bus 3, it generates two operation plans: one where the entire distance between the desired pick-up and drop-off points is traveled by Bus 3, and another where public transport and Bus 3 are combined. Note that the method for generating travel routes by combining public transport (airplane, train, etc.) and Bus 3 is publicly known, so the explanation is omitted here. Server 1 calculates the fare for Bus 3 based on the former operation plan and the fare based on the latter operation plan (the sum of the public transport fare and the Bus 3 fare), and adopts the operation plan combining public transport if the latter fare is lower than the former fare. For example, Server 1 outputs the information of the adopted operation plan to User Terminal 2 and obtains approval from the user.

[0100] Furthermore, if, for example, bus 3 is unable to operate on a portion of the route between two points desired by the user, server 1 will suggest to the user that they use a combination of public transportation and bus 3. This case could be considered for long-distance travel (for example, between Tokyo and Fukuoka). For example, server 1 will determine whether the distance, travel time, etc., between the two points are above a predetermined threshold, and if they are above the threshold, it will generate a travel plan that combines public transportation (for example, a plan to travel from Tokyo to Haneda by bus 3 and from Haneda to Fukuoka by airplane).

[0101] As mentioned above, the route plan may be generated by combining not only bus 3 but also other public transportation.

[0102] (Embodiment 2) In Embodiment 1, bus 3 is a shuttle bus that travels back and forth between a predetermined destination. This has been explained. However, bus 3 may not have a specific destination and may be a demand bus that circulates within a certain area, picking up and dropping off users. In this embodiment, we will describe a form in which bus 3 is a demand bus that circulates within a certain area.

[0103] Figure 13 is an explanatory diagram illustrating the overview of Embodiment 2. Figure 13 conceptually illustrates the vector space during clustering according to this embodiment. The overview of this embodiment will be explained based on Figure 13.

[0104] As described above, in this embodiment, bus 3 does not have a specific departure point or destination, but circulates within a certain area, picking up and dropping off each user. Therefore, server 1 does not divide the vector space into outbound and return routes, but instead divides the area circulated by bus 3 into districts of predetermined units. Also, the time axis is divided into predetermined time zones, as in Embodiment 1. As a result, as shown in Figure 13, server 1 divides the vector space by district and time zone.

[0105] Server 1 maps each user to a vector space based on passenger information obtained from each user's user terminal 2. Server 1 then classifies each user into multiple clusters. When generating a route plan, Server 1 first assigns a bus 3 to a cluster for a certain time period and generates a route plan, then assigns a bus 3 to a cluster in one of the districts from the clusters for the next time period and generates the next route plan. Server 1 optimizes the route plan using, for example, the traveling salesman problem method, similar to Embodiment 1.

[0106] In this case, it is preferable for Server 1 to generate a route plan according to the number of empty buses 3, similar to Embodiment 1. Specifically, Server 1 calculates a lower cost value for fewer empty buses 3, thereby generating a route plan that distributes passengers across all buses 3, 3, 3...

[0107] As described above, the operation planning system according to Embodiment 1 can also be applied to a circulating demand bus that does not have a specific destination. Since it is the same as Embodiment 1 except for the difference in the operation pattern of bus 3, flowcharts and other detailed explanations are omitted in this embodiment.

[0108] (Embodiment 3) In Embodiment 1, we explained that requests for the use of bus 3 are received from each user (passenger), clustering is performed, and a route plan is generated for each cluster to operate bus 3. In this embodiment, we will explain the process of actually having the bus operator operate bus 3, which involves assigning the generated route plan to each driver and bus 3 belonging to the bus operator, and presenting the driving route according to the assigned route plan to the driver of bus 3 (driver terminal 5).

[0109] Figure 14 is an explanatory diagram showing an example of a list screen for the operation plan. As described above, Server 1 generates an operation plan for each cluster. In this embodiment, Server 1 distributes the operation plan corresponding to each cluster to the operator terminal 4 and displays it on the list screen in Figure 14. This embodiment can be used in any of the following scenarios: for example, when a new cluster is created based on users who have requested to use Bus 3, and then Bus 3 is dispatched to the new operation plan for each cluster (specifically, when a cluster of people traveling from their homes to the airport at a predetermined date and time is created, an operation plan is generated, and a bus is dispatched to travel from the people's homes to the airport at the predetermined date and time); or when an operation plan has already been created, and a Bus 3 assigned to that operation plan is in operation, users who have requested to use Bus 3 are classified into the already created cluster, and the boarding or alighting of those users is included in the already created operation plan (specifically, when a user who is near a taxi in transit requests to use the taxi, that user is allowed to board the taxi).

[0110] For example, operator terminal 4 displays a list of information for each operation plan, including the departure and destination points, operating hours, number of passengers, and luggage information for each passenger. Furthermore, for each operation plan, operator terminal 4 displays the driver and bus 3, which it has automatically assigned, in the driver display field 41 and bus display field 42, respectively, by default. For example, the driver display field 41 and bus display field 42 allow for operation input via pull-down menus, enabling the driver and bus 3 settings to be changed (setting input). If route display 44 is selected, the route passing through the departure point, boarding point, alighting point, and destination of the operation plan is displayed.

[0111] When the operator terminal 4 automatically assigns a driver to the operation plan, it refers to the schedule of each driver (which may also be the schedule of each vehicle; the same applies hereinafter in this embodiment) as shown in Figure 15A, described later, and assigns a driver who has availability in the schedule between the departure and arrival times in the operation plan (a driver who is available to transport passengers according to their schedule). In this case, if there are multiple drivers with availability in their schedules, the appropriate driver may be assigned based on passenger information (language used, country of origin, address, location information, etc.), driver information (language used, passenger evaluation, location information, etc.), vehicle information (vehicle rank, seat rank, number of passengers who can be accommodated in available seats, etc.). Furthermore, if there are multiple drivers with availability in their schedules, the driver located in a nearby location may be assigned to the passenger. Specifically, the driver whose location information (GPS information) is close to the passenger's location information (GPS information) may be assigned. Furthermore, the system may assign a driver whose location is closest to the boarding point and boarding time entered by the passenger, based on the driver's work schedule (for example, if the route plan indicates that the passenger wishes to board at Haneda Airport at 2 PM, and the driver's schedule is to drop the passenger off at Haneda Airport at 1:45 PM, then that driver will be assigned to that route plan).

[0112] Furthermore, when the operator terminal 4 automatically assigns a vehicle (or the driver who will operate the vehicle) to the operation plan, it may determine whether the number of passengers and the amount of luggage that can be transported are within the limits of the passenger capacity and luggage capacity included in the vehicle information of bus 3, based on the number of passengers and luggage information of the passengers included in the operation plan, and assign a vehicle (or the driver who will operate the vehicle) that can transport the luggage. In this case, if the number of passengers included in the operation plan is less than or equal to the passenger capacity included in the vehicle information, it may be determined that passengers can be transported. Also, if the luggage information of the passengers included in the operation plan is within the range of the luggage capacity included in the vehicle information, it may be determined that luggage can be transported. Moreover, if the luggage information of the passengers included in the operation plan is not within the range of the luggage capacity included in the vehicle information, and the number of passengers included in the operation plan is less than the passenger capacity included in the vehicle information, it may be determined that luggage can be transported if it is determined that luggage corresponding to the luggage information of the passengers included in the operation plan that exceeds the range of the luggage capacity included in the vehicle information can be loaded onto seats in the vehicle that are not occupied by passengers. Whether it is possible to load luggage corresponding to passenger luggage information included in the operation plan, exceeding the maximum load capacity included in the vehicle information, onto seats in a vehicle that are not occupied by passengers can be determined, for example, by counting one piece of luggage as one person in the vehicle (or by pre-determining how many people each type of luggage should be equivalent to as a parameter, and performing the calculation based on that parameter). If the sum of the number of passengers in the vehicle included in the operation plan and the converted number is less than or equal to the maximum load capacity included in the vehicle information, then it can be determined that it is possible to load the luggage. Note that although this explanation uses luggage owned by passengers as an example, it may also apply to luggage not owned by passengers (luggage owned by someone other than a passenger, for example, when only luggage is being transported by vehicle).

[0113] When the operator terminal 4 automatically assigns a driver or vehicle to a route plan, if the departure point, pick-up point, drop-off point, or destination in the route plan is not within the operator's service area (area where driving is possible), the operator terminal may choose not to assign a driver or vehicle to that route plan.

[0114] Through the above process, the operator terminal 4 refers to the driver and vehicle schedules, passenger information, driver information, vehicle information, etc., to determine and display by default the drivers and vehicles to be assigned to the operation plan. The operating company can then change the assignment settings for the drivers and vehicles displayed by default by operating the driver display field 41 and the bus display field 42.

[0115] Figure 15 is an explanatory diagram showing an example of a driver information display screen. The operator terminal 4 switches between displaying the list screen in Figure 14, the schedule screen in Figure 15A, or the profile screen in Figure 15B, depending on the operation input from the operator.

[0116] The schedule screen is a display screen that lists the work schedules (operation schedules) of each driver working under the operating company in a time chart format. In addition, the schedule screen also displays each driver's working hours. Server 1 receives a request to output the schedule screen from the operator terminal 4, generates the schedule screen by referring to the operation plan DB 144, and distributes it to the operator terminal 4 for display.

[0117] The profile screen displays a list of each driver's attributes, including their name, phone number, and other bibliographic information (such as the languages ​​they can communicate in Figure 15B). In response to an output request from the operator terminal 4, server 1 generates the profile screen and displays it on the operator terminal 4.

[0118] In this embodiment, only driver information is displayed, but for example, the operator terminal 4 may also display a list of vehicle information such as the operating schedule, passenger capacity, cargo capacity, and vehicle type for each bus 3 owned by the operating company. This would allow the operating company to easily assign buses 3 by understanding the vehicle information.

[0119] The schedule screen and profile screen allow the operator to easily check each driver's schedule and profile (especially the driver's attribute information). Returning to Figure 14, the operator operates the driver display field 41 and the bus display field 42 to input changes to the settings for the driver and bus 3 assignments that were automatically assigned by default. Through the above process, the operator terminal 4 can correct the driver and bus 3 assignments that were automatically determined, making the operation plan more appropriate.

[0120] In this embodiment, the operator terminal 4 automatically sets the assignment of drivers and buses 3, and the operator manually changes them. However, the operator terminal 4 may not perform the assignment of drivers and buses 3, and the operator may manually set (determine) them. In other words, it is sufficient that the operator terminal 4 can determine the assignment of drivers and / or buses 3, and this process may be performed automatically by the operator terminal 4, or it may be performed based on the results of manual input.

[0121] Furthermore, while the above describes assigning drivers who have availability between the departure and arrival times of bus 3 to the operation plan based on their work schedules, the opposite is also possible: drivers' work schedules (i.e., work shifts) may be changed according to the operation plan. For example, operator terminal 4 may refer to a table that holds each driver's monthly working hours, daily working hours, required number of holidays, and maximum daily driving distance to be covered, assign drivers to the operation plan for each bus 3, generate a work schedule, and present it to the operator (or driver) for approval. Thus, instead of assigning drivers based on their schedules, drivers' schedules may be changed to make them available for assignment to the operation plan.

[0122] Furthermore, when changing the driver's schedule, the demand information explained in Variation Example 1 should also be taken into consideration. Schedule changes are permitted. For example, operator terminal 4 determines whether the demand value for bus 3 (predicted number of users getting on and off) is above a certain value, and if it determines that it is above a certain value, it raises the upper limits for working hours, etc., and generates a schedule. In this way, the driver's schedule may be changed taking into account the demand for bus 3.

[0123] The explanation continues based on Figure 14. The operator terminal 4 displays an approval button 43 corresponding to each operation plan. When an operation input is received for the approval button 43, an operation menu of "Approve" and "Deny" will be displayed as a pull-down menu as shown in Figure 14, and the operator will be asked whether to approve or reject the operation plan. For operation plans that have already been approved, the approval button 43 will change to display "Approved". In this case, the operator terminal 4 notifies (outputs) the server 1 that it has approved the operation plan.

[0124] For example, Server 1 collaborates with multiple operators and distributes (outputs) operation plans to each operator's terminal 4. For example, Server 1 may display the screen shown in Figure 14 to all operator terminals 4 and accept approvals on a first-come, first-served basis for each operator. Alternatively, Server 1 may maintain a table relating to the priority of each operator and display each operation plan to the operator with the highest priority in order, accepting approval if approval is obtained. If approval is not obtained, it may repeatedly display each operation plan to the next-ranked operator until approval is obtained. When approval is received from one operator's terminal 4, Server 1 removes the approved operation plan from the list screen displayed on the operator terminals 4 of the other operators.

[0125] In this embodiment, the server 1 outputs the operation plan to the operator terminal 4, and the operator approves the operation plan. However, the server 1 may also output the operation plan to the driver terminal 5 and accept approval from the driver.

[0126] In the embodiments described above, we have explained whether or not the operator approves each operation plan displayed on the operator terminal 4. However, the operator may also consolidate multiple operation plans into a single operation plan and approve it. That is, if there are operation plans that can be operated even after consolidation because the sections and times are close together, the operator can select the operation plans that can be consolidated and choose to consolidate them, so that the consolidated operation plan is displayed on the operator terminal 4. The operator can then approve the consolidated operation plan using the operator terminal 4.

[0127] In the above example, approval (orders) for operation plans are accepted on a first-come, first-served basis, but this embodiment is not limited to this. For example, Server 1 may decide which operation company to entrust the operation plan to based on the order price quoted by the operation company. For example, when Operator Terminal 4 receives the input of "Approve," it further accepts the input of the order price for the operation plan and notifies Server 1. Server 1 receives notifications regarding the order price from each operation company's Operator Terminal 4 and decides, for example, to entrust the operation plan to the operation company with the lowest order price. By determining the recipient of the operation plan according to the order price, the shuttle service can be implemented effectively.

[0128] In this case, it is preferable for Server 1 to set a time limit (e.g., 5 minutes) between distributing the operation plan and receiving notification of the order payment. Setting a time limit can encourage prompt approval (order acceptance) of the operation plan.

[0129] Furthermore, while the above describes the operator manually approving (accepting) the operation plan, the operator terminal 4 may automatically approve (accept) the operation plan. For example, the operator terminal 4 may automatically approve all operation plans for which the driver and bus 3 have been assigned processing (in this case, the processing assigned to the driver and bus 3 may include the approval processing). (i) It may also be done as follows. Furthermore, the operator terminal 4 may automatically approve operation plans that meet certain conditions (for example, the distance between the departure point and the destination is greater than or equal to a predetermined distance, or the number of passengers is greater than or equal to a predetermined number) from among the operation plans for which the driver and bus 3 have been processed.

[0130] In addition, when Server 1 receives "approval" inputs from multiple operators, it may determine the operator based on all or some of the following elements: operator information (passenger ratings, service area, etc.), passenger information (language used, country of origin, address, gender, etc.), driver information (language used, passenger ratings, gender, etc.), vehicle information (number of passengers, rank, etc.), and order price.

[0131] When the operator terminal 4 approves the operation plan, the server 1 notifies the user terminal 2 of the operation plan via email, SMS, etc. (not shown), which includes the time of boarding, boarding location, etc., as well as the operator and type of bus 3. In this case, for example, the server 1 generates an email, etc. with a request for confirmation of opening (viewing) and notifies the user terminal 2. If the notification is opened, the user terminal 2 automatically replies to the server 1 that the notification has been opened. Upon receiving this reply, the server 1 notifies the operator terminal 4 that the operation plan has been finalized. Through the above process, the operation plan can be finalized without the need for an intermediary operator between the user and the operator.

[0132] Even after an operating company has approved an operating plan, it may still classify passengers who can be classified under that operating plan under that plan.

[0133] Figure 16 is an explanatory diagram showing an example of the display screen of the driver's terminal 5. When the operation plan is finalized, the server 1 distributes information about the operation plan to the driver's terminal 5 of the assigned driver, and displays the screen shown in Figure 16.

[0134] For example, the driver terminal 5 first displays a list of the route plans (outbound or inbound trips) that the driver is responsible for that day, as shown on the left side of Figure 16. When each text item indicating a route plan is tapped, the driver terminal 5 displays a dropdown menu showing the boarding and alighting times and locations for each user.

[0135] For example, the driver terminal 5 accepts a selection input to choose one of the operation plans and transitions to the screen in the center of Figure 16, which shows the route related to the selected operation plan. Alternatively, the driver terminal 5 may be configured to automatically display the screen in the center of Figure 16 when the start time of the operation arrives. As shown in the center of Figure 16, the driver terminal 5 displays a map image showing the route from the current location of the bus 3 to the boarding / alighting point where the user will board or alight.

[0136] For the sake of brevity, the following explanation will only describe the outbound journey, where bus 3 departs from the starting point, picks up users at various points, and heads towards the destination.

[0137] The driver terminal 5 first displays the route to the first user's pick-up location. In addition to the route, the driver terminal 5 also displays information such as the address of the pick-up location and the name of the user being picked up at the bottom of the screen. Furthermore, the driver terminal 5 displays, for example, the estimated time of arrival at the pick-up location, the estimated time of departure from the pick-up location, the distance from the current location, and the estimated remaining travel time from the current location.

[0138] Furthermore, for example, the driver terminal 5 displays objects such as a call icon 161 and a message icon 162 at the bottom of the screen for contacting the user to be picked up at the displayed pick-up location. When an operation input is received for the call icon 161 or message icon 162, the driver terminal 5 makes a call or message to the user's user terminal 2 via the server 1. Send the message.

[0139] For example, the driver terminal 5 switches the display at the bottom of the screen to the display on the right side of Figure 16 in response to input from the driver. Specifically, the driver terminal 5 displays an arrival button 163 at the bottom of the screen for the driver to input that they have arrived at the boarding location. Alternatively, the driver terminal 5 may automatically display the arrival button 163 depending on the distance between the current location of the bus 3 and the boarding location.

[0140] When the bus arrives at the boarding location, the driver taps the arrival button 163. Upon receiving input to the arrival button 163, the driver terminal 5 determines that the bus has arrived at the boarding location and notifies the user terminal 2 via the server 1 that the bus has arrived. For example, the driver terminal 5 may notify the user via email, SMS message, or other means, or it may make a phone call to the user terminal 2. This allows the user to be notified of the bus's arrival as quickly as possible. Alternatively, even if the driver does not tap the arrival button 163, if the driver terminal 5 determines that the bus has arrived at the boarding location based on the bus's location information, the driver terminal 5 will notify the user terminal 2 via the server 1 that the bus has arrived.

[0141] Once a user has boarded, Server 1 switches to the route to the next boarding point and displays it on the driver's terminal 5. For example, the driver's terminal 5 displays an object (button) similar to the arrival button 163 and accepts input from the driver to determine whether a user has boarded. Alternatively, Server 1 may determine whether a user has boarded based on the location information of both the bus 3 and the user (user terminal 2). If a user has boarded, the driver's terminal 5 displays the route to the next user's boarding point and resumes operation.

[0142] Furthermore, if the user does not arrive at the boarding location by the boarding time, i.e., misses the bus, Server 1 may cancel the user's scheduled boarding. For example, if Server 1 determines that the arrival button 163 has not been pressed by the boarding time and the user has not boarded, it will inquire with User Terminal 2 whether or not to cancel the boarding. Alternatively, Server 1 may automatically determine whether or not the user has boarded based on location information, etc. In response to the inquiry, if Server 1 receives a response from User Terminal 2 indicating that it approves the cancellation, Server 1 cancels the user's scheduled boarding and notifies Driver Terminal 5 accordingly.

[0143] If a user misses their bus, Server 1 may have the user board another bus 3. For example, Server 1 may identify a bus 3 with available seats from the route plan DB 144 among the buses 3 operating in the vicinity and notify the driver's terminal 5 of that bus 3 to allow the user to board.

[0144] The above describes the case where a user's arrival is delayed, but it is also possible that bus 3 may arrive late or early. In that case, server 1 may change the bus 3 that the user is on, depending on the operating status of each bus 3, 3, 3... For example, if the scheduled operating schedule of bus 3 that a user is scheduled to ride is delayed (the arrival time at each boarding / alighting point for each user is delayed by a certain amount of time or more compared to the scheduled boarding / alighting time), and the scheduled operating schedule of a subsequent bus 3 (a bus 3 whose departure and destination are the same as the preceding bus 3, and whose departure time is later than the preceding bus 3) is also delayed, server 1 will have the user board the subsequent bus 3. Also, for example, if the scheduled operating schedule of bus 3 that a user is scheduled to ride is earlier than planned (the arrival time at each boarding / alighting point for each user is earlier than the scheduled boarding / alighting time), and the scheduled operating schedule of the preceding bus 3 is also earlier than planned, server 1 will have the user board the preceding bus 3. Thus, Server 1 may modify (update) the operation plan to change which bus 3 the user is on, depending on the operating status of buses 3, 3, 3...

[0145] If a user's boarding is confirmed (determined) at one boarding point, for example, server 1 may notify the user terminal 2 of the user who will board at the next boarding point that another user (previous passenger) boarded at the previous boarding point, and the estimated arrival time of bus 3 at the next boarding point. This allows each user to know the bus's operating status accurately, improving convenience.

[0146] Each time a user boards at a boarding point, the driver terminal 5 switches and displays the route. When all users have boarded, the driver terminal 5 displays the route to the destination (airport, etc.) and drives the bus 3 to the destination.

[0147] On the return journey, the driver terminal 5 sequentially displays the route from the departure point (airport, etc.) to each user's drop-off point. In this case, for example, when the driver terminal 5 arrives at the departure point, it accepts input to the arrival button 163 and notifies each user's user terminal 2 that the bus 3 has arrived, allowing them to board. The driver terminal 5 displays the route to each user's drop-off point according to the bus 3's operating status, switches the route each time a drop-off point is passed, and provides route guidance so that the bus 3 heads towards each drop-off point.

[0148] Figure 17 is a flowchart showing an example of the processing procedure performed by the carrier terminal 4. Based on Figure 17, the processing content performed by the carrier terminal 4 will be explained. The operator terminal 4 obtains multiple operation plans from the server 1 based on usage requests (passenger information) from each user (step S301). The operator terminal 4 determines the driver and vehicle to be assigned to each operation plan based on the contents of the operation plan, the driver's schedule, the vehicle's schedule, passenger information, driver information, vehicle information, etc. (step S302). The operator terminal 4 displays a list of the multiple operation plans obtained (step S303). In this case, the operator terminal 4 displays a list of operation plans to which the driver and vehicle determined in step S302 have been assigned.

[0149] The operator terminal 4 displays a list of driver information for each driver engaged in driving bus 3 under the operator, in accordance with the operation input from the operator (step S304). For example, as illustrated in Figure 15, the operator terminal 4 displays a list of each driver's bus 3 operation schedule, driver attribute information, and other driver profiles. The operator terminal 4 returns to the operation plan list screen in accordance with the operation input from the operator and accepts input for the settings of the driver and vehicle to be assigned to each operation plan (step S305). Note that once a driver is decided, the vehicle to be used by that driver may also be decided, so it is not mandatory to receive input of vehicle information. Conversely, once a vehicle is decided, the driver who will operate that vehicle may also be decided, so it is not mandatory to receive input of driver information.

[0150] The operator terminal 4 determines whether to approve the operation plan based on the operation input from the operator (step S306). If it determines to approve the operation plan (S306: YES), the operator terminal 4 notifies the server 1 that the operation plan has been approved (step S307). After executing the process in step S307, or if the result in step S306 is NO, the operator terminal 4 terminates the series of processes.

[0151] Although not shown in Figure 17, the processing of Server 1 after S307 will be explained. When Server 1 receives a notification from the operator terminal 4 that the operator approves the operation plan, it processes the assignment of the operator (which may be the operator's driver or vehicle) to the operation plan based on the receipt. Even after assigning the operator to the operation plan in this way, passengers who have made new usage requests may be classified into the cluster corresponding to the operation plan, and the operation plan may be modified. Modification of the operation plan may be conditional on the operator approving the modified operation plan. Furthermore, such modification of the operation plan is It may be permitted to carry out the necessary procedures from the start time up to a specified time before. Furthermore, if the operation plan is finalized at a specified time before the start time of operation, each user to be transported based on that operation plan may be notified of their boarding time.

[0152] In Figure 17, the operator terminal 4 is explained as a flowchart showing an example of the processing procedure performed by the operator terminal 4. However, it is also possible that the server 1 performs the processing from S301 to S305, the driver and vehicle transmit the set operation plan to the operator terminal 4, and the operator terminal 4 determines whether or not to approve the operation plan (step S306).

[0153] Figure 18 is a flowchart showing an example of the processing procedure performed by the driver terminal 5. Based on Figure 18, the processing content performed by the driver terminal 5 will be explained. The driver terminal 5 obtains a route plan generated from the server 1 based on usage requests (passenger information) from each user (step S321). For example, the driver terminal 5 obtains information on one or more route plans that the driver is scheduled to operate on that day. The driver terminal 5 displays the obtained one or more route plans and accepts input for selecting a route plan to display (step S322).

[0154] The driver terminal 5 displays the route for each user to be picked up for the selected route plan (step S323). For example, in step S323, the driver terminal 5 first displays the route to the pick-up location of the first user to be picked up. For example, in addition to the route to the pick-up location, the driver terminal 5 displays the estimated arrival time at the pick-up location, the estimated departure time from the pick-up location, the distance from the current location, the remaining travel time, etc. Also, for example, the driver terminal 5 displays objects for contacting the user to be picked up at the pick-up location (call icon 161, message icon 162, etc.).

[0155] The driver terminal 5 determines whether or not to contact the user who is scheduled to board the vehicle, based on the operation input to the contact object (step S324). If it determines to contact the user (S324: YES), the driver terminal 5 makes a call or sends a message to the user terminal 2 of the user corresponding to the displayed boarding location via the server 1 (step S325).

[0156] If the response is NO in step S324, or if the processing in step S325 is performed, the driver terminal 5 determines whether or not the bus 3 has arrived at the boarding point based on the input to the arrival button 163 (step S326). If it is determined that the bus has not arrived (S326: NO), the driver terminal 5 returns to step S324. If it is determined that the bus has arrived (S326: YES), the driver terminal 5 notifies the user terminal 2 of the user corresponding to the boarding point that the bus 3 has arrived, via the server 1 (step S327).

[0157] The driver terminal 5 determines whether a user has boarded the vehicle based on the driver's input (step S328). If it determines that no user has boarded (S328: NO), the driver terminal 5 waits for processing. If it determines that a user has boarded (S328: YES), the driver terminal 5 determines whether all users have boarded the vehicle (step S329). If it determines that no users have boarded the vehicle (S329: NO), the driver terminal 5 switches to displaying the route to the next user's boarding point (step S330) and returns to step S324. If it determines that all users have boarded the vehicle (S329: YES), the driver terminal 5 displays the route to the destination (step S331) and terminates the series of processes.

[0158] Furthermore, the driver terminal 5 may notify the server 1 that it has reached its destination. The server 1 may also notify the user that it has reached its destination and process the payment of the user's fare.

[0159] Based on the above, this embodiment 3 can support the smooth execution of the operation plan automatically generated by the server 1.

[0160] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended. [Explanation of Symbols]

[0161] 1. Server (Information Processing Device) 11 Control Unit 12 Main memory 13 Communications Department 14 Auxiliary storage P1 Program 141 User DB 142 Bus DB 143 Driver DB 144 Operation Plan Database 2 User terminals 21 Control Unit 22 Main memory 23 Communications Department 24 Display 25 Input section 26 Location information acquisition section 27 Auxiliary storage P2 Program 3. Bus (vehicle) 4. Carrier terminals 5. Driver terminal

Claims

1. An acquisition unit that acquires passenger information indicating the boarding or alighting point of passengers using the vehicle, and the boarding or alighting time of said passengers, The system includes a generation unit that generates multiple vehicle operation plans indicating routes for boarding or alighting passengers based on the aforementioned passenger information, The acquisition unit acquires passenger information including the allowable time between the boarding or alighting time desired by the passenger and the boarding or alighting time at which the vehicle boards or alights the passenger. The generation unit generates the operation plan which determines the boarding time or alighting time within the allowable time range, If the boarding or alighting time of the passenger in the operation plan generated by the generation unit differs from the boarding or alighting time desired by the passenger, the setting unit sets the passenger's fare according to the allowable time, The system includes a reception unit that receives input from the passenger indicating whether or not they approve the operation plan in which the difference between the passenger's boarding or alighting time and the passenger's desired boarding or alighting time is equal to or greater than the allowable time, When the unit receives input indicating approval of the aforementioned operation plan, it generates an operation plan in which the difference is equal to or greater than the allowable time. An information processing device characterized by the following:

2. The aforementioned vehicle is a vehicle in which multiple passengers ride together, The system includes a classification unit that classifies the passengers into multiple groups based on the passenger information, The generation unit generates the operation plan for each set, which shows the route along which to transport multiple passengers boarding or alighting. The information processing apparatus according to feature 1.

3. The acquisition unit acquires first passenger information indicating the boarding or alighting point of a passenger who has already reserved the use of the vehicle by a predetermined time, and the boarding or alighting time of the passenger. The classification unit classifies the passengers who have already made reservations into the plurality of groups based on the first passenger information. The acquisition unit further acquires second passenger information indicating the boarding or alighting point of a new passenger who applied to use the vehicle after the predetermined time, and the boarding or alighting time of the passenger. When the second passenger information is obtained, the classification unit determines, based on the second passenger information, whether or not the new passenger should be classified into the set of passengers who have already made reservations. If the generation unit determines that the new passenger should be classified into the group, it updates the generated operation plan to allow the new passenger to board or alight from the vehicle corresponding to the group to which the already booked passenger belongs, to the extent that there is no change to the group to which the already booked passenger belongs. The information processing apparatus according to feature 2.

4. The acquisition unit acquires demand information related to the demand of the new passenger, or supply information related to the supply of the vehicle. The generation unit generates the operation plan that includes vacant seats in the vehicle according to the demand information or supply information. The information processing apparatus according to claim 3.

5. The generation unit generates the operation plan by referring to the number of vehicles waiting at the vehicle depot among the multiple vehicles. The information processing apparatus according to any one of claims 1 to 4.

6. The generation unit generates a travel plan that allows passengers to board at a different boarding location than the one requested by the passenger, if doing so would shorten the travel time. The system includes a notification unit that informs the passenger of the boarding point specified in the aforementioned operation plan. The information processing apparatus according to any one of claims 1 to 5.

7. The generation unit generates the operation plan which involves picking up the passenger at a boarding point located in the lane opposite to the lane where the passenger's desired boarding point is located. The information processing apparatus according to feature 6.

8. The generation unit generates the operation plan that allows the passenger to board at the point closest to the passenger's desired boarding point on the current route of the vehicle. The information processing apparatus according to feature 6.

9. The system acquires passenger information indicating the boarding or alighting point of passengers using the vehicle, and the boarding or alighting time of those passengers. Based on the passenger information, the system generates operation plans for multiple vehicles that indicate routes for picking up or dropping off passengers. An information processing method in which a computer performs the processing, The vehicle acquires passenger information including the permissible time between the boarding or alighting time desired by the passenger and the boarding or alighting time at which the vehicle boards or alights the passenger. The operation plan is generated, which sets the boarding or alighting time within the aforementioned allowable time range. If the passenger's boarding or alighting time in the generated service plan differs from the passenger's desired boarding or alighting time, the passenger's fare will be set according to the allowable time. The system receives input from the passenger indicating whether or not they approve the operation plan in which the difference between the passenger's boarding or alighting time and the passenger's desired boarding or alighting time is equal to or greater than the allowable time. If an input indicating approval of the aforementioned operation plan is received, the system will generate the aforementioned operation plan in which the difference is equal to or greater than the allowable time. An information processing method characterized in that the processing is performed by a computer.

10. The system acquires passenger information indicating the boarding or alighting point of passengers using the vehicle, and the boarding or alighting time of those passengers. Based on the passenger information, the system generates operation plans for multiple vehicles that indicate routes for picking up or dropping off passengers. A program that causes a computer to perform a process, The vehicle acquires passenger information including the permissible time between the boarding or alighting time desired by the passenger and the boarding or alighting time at which the vehicle boards or alights the passenger. The operation plan is generated, which sets the boarding or alighting time within the aforementioned allowable time range. If the passenger's boarding or alighting time in the generated service plan differs from the passenger's desired boarding or alighting time, the passenger's fare will be set according to the allowable time. The system receives input from the passenger indicating whether or not they approve the operation plan in which the difference between the passenger's boarding or alighting time and the passenger's desired boarding or alighting time is equal to or greater than the allowable time. If an input indicating approval of the aforementioned operation plan is received, the system will generate the aforementioned operation plan in which the difference is equal to or greater than the allowable time. A program characterized by having a computer perform a process.

Images