Information processing device, information processing method and program

Abstract

To provide an information processing device, etc., capable of appropriately performing dynamic creation of an operation plan.SOLUTION: An information processing device is configured to: acquire passenger information including a getting-on time or a getting-off time desired by a passenger and an allowable time which is allowed between a getting-on time or a getting-off time, within which a vehicle allows the passenger to get on the vehicle or get off the vehicle; generate an operation plan in which the getting-on time or the getting-off time is determined within a range of the allowable time; in a case where a getting-on time or a getting-off time of the passenger in the generated operation plan is different from the getting-on time or the getting-off time desired by the passenger, set a fare of the passenger correspondingly to the allowable time; receive from the passenger input of whether to approve the operation plan in which a differential between the getting-on time or the getting-off time of the passenger and the getting-on time or the getting-off time desired by the passenger is equal to or more than the allowable time; and in a case where the input that the operation plan is approved is received, generate the operation plan in which the differential is equal to or more than the allowable time.SELECTED DRAWING: Figure 6

Description

[Technical field]

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

[0002] For transportation such as buses, a demand-based bus system has been proposed that dynamically plans operation routes in response to requests from passengers. For example, Patent Document 1 discloses a demand-based operation control system that generates a bus operation plan in response to requests from users, and generates an operation plan with stopping positions at midpoints between a first boarding and alighting point where a first user boards and alights, and a second boarding and alighting point where a second user boards and alights. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6273656 Summary of the Invention [Problem to be solved by the invention]

[0004] However, the invention in Patent Document 1 generates an operation plan that enables operation within an allowable time range from the operation route predetermined in the standard bus schedule, and cannot generate an operation plan that falls outside the allowable range.

[0005] According to one aspect, an object of the present invention is to provide an information processing device or the like that can suitably perform dynamic generation of an operation plan. [Means for solving the problem]

[0006] According to one aspect, an information processing device includes an acquisition unit that acquires passenger information indicating boarding points or alighting points of passengers using a vehicle and boarding times or alighting times of the passengers, and a generation unit that generates an operation plan for a plurality of the vehicles indicating a route for boarding or alighting the passengers based on the passenger information, the acquisition unit acquires the passenger information including an allowable time allowed between a boarding time or alighting time desired by the passengers and a boarding time or alighting time at which the vehicle boards or alights the passengers, and the generation unit generates the operation plan in which the boarding time or alighting time is set within a range of the allowable time. the operation plan generating unit generates an image of the operation plan, and if the boarding time or disembarking time of the passenger in the operation plan generated by the generation unit differs from the boarding time or disembarking time desired by the passenger, sets the passenger's fare according to the allowable time; and a reception unit receives input from the passenger as to whether or not to approve the operation plan in which the difference between the passenger's boarding time or disembarking time and the passenger's desired boarding time or disembarking time is equal to or greater than the allowable time, and when an input to the effect of approving 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. Effect of the Invention

[0007] In one aspect, dynamic generation of an operation plan can be suitably performed. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a schematic diagram illustrating a configuration example of an operation planning system. [Diagram 2] FIG. 2 is a block diagram showing an example of the configuration of a server. [Diagram 3] FIG. 2 is a block diagram showing a configuration example of a terminal. [Figure 4] 1 is an explanatory diagram showing an example of the record layout of a user DB, a bus DB, a driver DB, and an operation plan DB. [Diagram 5] FIG. 13 is an explanatory diagram showing an example of a location designation screen. [Figure 6] FIG. 13 is an explanatory diagram showing an example of a bus reservation screen. [Figure 7]FIG. 11 is an explanatory diagram relating to an operation plan generation process. [Figure 8A] FIG. 11 is an explanatory diagram relating to an update process of an operation plan. [Figure 8B] FIG. 11 is an explanatory diagram relating to an update process of an operation plan. [Figure 9] FIG. 13 is an explanatory diagram showing an example of a reservation confirmation screen. [Figure 10] FIG. 13 is an explanatory diagram showing an example of an operation status confirmation screen. [Figure 11] 11 is a flowchart illustrating an example of a processing procedure executed by a server. [Figure 12] 11 is a flowchart illustrating an example of a processing procedure executed by a terminal. [Figure 13] FIG. 11 is an explanatory diagram showing an overview of a second embodiment. [Figure 14] FIG. 13 is an explanatory diagram illustrating an example of a list screen of an operation plan. [Figure 15A] FIG. 13 is an explanatory diagram showing an example of a driver information display screen. [Figure 15B] FIG. 13 is an explanatory diagram showing an example of a driver information display screen. [Figure 16] FIG. 2 is an explanatory diagram showing an example of a display screen of a driver's terminal. [Figure 17] 13 is a flowchart illustrating an example of a processing procedure executed by a carrier terminal. [Figure 18] 10 is a flowchart showing an example of a processing procedure executed by a driver's terminal. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The present invention will now be described in detail with reference to the drawings showing embodiments thereof. (Embodiment 1) FIG. 1 is a schematic diagram showing a configuration example of an operation planning system. In this embodiment, an operation planning system that dynamically generates an operation plan for a vehicle (bus) in which multiple passengers share a ride will be described. The operation planning system includes an information processing device 1, user terminals 2, 2, 2..., a bus 3, an operator terminal 4, and a driver terminal 5. Each device is communicatively connected to each other via a network N such as the Internet. Note that in this embodiment, a bus is given as an example of a vehicle, but the type of vehicle is not limited to a bus and may be any vehicle that can carry multiple passengers, such as a passenger car or a shuttle.

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

[0011] The information processing device 1 is an information processing device capable of various information processing and transmitting and receiving information, such as a server device, a personal computer, etc. In this embodiment, the information processing device 1 is assumed to be a server device, and for the sake of simplicity, will be referred to as the server 1 below. The server 1 accepts requests to use 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 the system, and is, for example, a mobile terminal such as a smartphone or a tablet terminal. An application program for realizing functions related to the system is pre-installed in the user terminal 2, and the user terminal 2 executes the application program to perform the processes described below. The server 1 receives a usage request from the user terminal 2 and generates an operation plan.

[0013] As described above, the bus 3 is a shuttle bus that travels between a departure point and a destination, and is a demand bus that is driven by a driver according to instructions from the server 1. The bus 3 is not limited to a vehicle (bus) called a demand bus, and may be any vehicle that operates according to instructions from the server 1. For convenience of illustration, only one bus 3 is shown in FIG. 1, but in this embodiment, operation plans for multiple buses 3 are generated. For example, the server 1 communicates with a mobile terminal (driver's terminal 5) carried by the driver, notifies the driver of the operation plan for the bus 3, and sequentially acquires and manages position information (e.g., GPS (Global Positioning System) coordinate values) of the bus 3.

[0014] The business operator terminal 4 is a terminal device of the business operator (bus company) that operates the bus 3, such as a personal computer. The driver terminal 5 is a terminal device carried by the driver of each bus 3, such as a smartphone or tablet terminal. The server 1 notifies the business operator terminal 4, driver terminal 5, etc. of an operation plan generated in response to a usage request from a user, and operates the bus 3.

[0015] The system may operate the bus 3 in cooperation with a single operator or multiple operators. In this embodiment, when coordinating with the driver of the 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 in the bus 3 to notify the driver of the operation plan.

[0016] 2 is a block diagram showing an example of the configuration of the server 1. The server 1 includes a control unit 11, a main storage unit 12, a communication unit 13, and an auxiliary storage unit . The control unit 11 has one or more arithmetic processing devices such as a CPU (Central Processing Unit), an MPU (Micro-Processing Unit), a GPU (Graphics Processing Unit), etc., and performs various information processing, control processing, etc. by reading and executing a program P1 stored in the auxiliary storage unit 14. The main storage unit 12 is a temporary storage area such as an SRAM (Static Random Access Memory), a DRAM (Dynamic Random Access Memory), a flash memory, etc., and temporarily stores data necessary for the control unit 11 to execute arithmetic processing. The communication unit 13 is a communication module for performing processing related to communication, and transmits and receives information to and from the outside.

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

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

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

[0020] 3 is a block diagram showing an example of the configuration of the user terminal 2. The user terminal 2 includes a control unit 21, a main memory unit 22, a communication unit 23, a display unit 24, an input unit 25, a position information acquisition unit 26, and an auxiliary memory unit 27. The control unit 21 has one or more arithmetic processing devices such as a CPU, an MPU, etc., and performs various information processing, control processing, etc. related to the user terminal 2 by reading and executing the program P2 stored in the auxiliary storage unit 27. The main storage unit 22 is a temporary storage area such as a RAM, and temporarily stores data required for the control unit 21 to execute arithmetic processing. The communication unit 23 includes an antenna for communication, a processing circuit, etc., and transmits and receives information to and from 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 an image provided by the control unit 21. The input unit 25 is an operation interface such as a touch panel or a mechanical key, and inputs operation contents to the control unit 21. The position information acquisition unit 26 is a communication module that acquires position information (e.g., GPS coordinate values) of the user terminal 2. The auxiliary storage unit 27 is a non-volatile storage area such as a ROM (Read Only Memory), and stores the program P2 and other data required for the control unit 21 to execute processing.

[0021] The user terminal 2 may include a reading unit for reading the portable storage medium 2a and may read and execute the program P2 from the portable storage medium 2a, or the user terminal 2 may read the program P2 from the semiconductor memory 2b.

[0022] FIG. 4 is an explanatory diagram showing an example of the record layout of the user DB 141, the bus DB 142, the driver DB 143, and the operation plan DB 144. The user DB 141 includes a user ID column, a user name column, an address column, and a user information column. The user ID column stores a user ID for identifying each user. The user name column, the address column, and the user information column store the user's name, email address, and other user information in association with the user ID. The user information column stores attribute information (passenger attribute information) such as the user's age, sex, nationality, organization (company, etc.), hobbies, residential area, and user rank (customer loyalty level according to frequency of use of bus 3, etc.).

[0023] The bus DB 142 includes a bus ID column, an operating company column, and a bus information column. The bus ID column stores a bus ID for identifying each bus 3. The operating company column and the bus information column store the name of the operating company (operating business operator) and information on the bus 3 in association with the bus ID, respectively. The bus information column stores attribute information (vehicle attribute information) such as the number of passengers that the bus 3 can accommodate, seat numbers, etc., as well as a vehicle rank indicating an evaluation value of the bus 3, a seat rank indicating an evaluation value of each seat, whether the bus is a women-only vehicle or not, whether the bus is a welfare vehicle or not, and services provided in the vehicle (e.g., tourist guide services, massage services, nail services, etc.).

[0024] The driver DB 143 includes a driver ID column, a driver name column, a driving bus column, and a driver attribute column. The driver ID column stores a driver ID for identifying the driver who drives the bus 3. The driver name column, the driving bus column, and the driver attribute column store the driver's name, the bus ID of the bus 3 driven, and other information related to the driver, respectively, in association with the driver ID. The driver attribute column stores driver attribute information such as languages ​​the driver can speak, an evaluation value of the driver from users, and gender.

[0025] The operation plan DB 144 includes a bus ID column, a current location column, and an operation plan column. The bus ID column stores a bus ID for identifying each bus 3. The current location column and the operation plan column store information on the current location of the bus 3 and the operation plan of the bus 3, respectively, in association with the bus ID. For example, the operation plan column stores the location of each point, the estimated arrival time, the number of passengers getting on and off, etc. for each of the first point, second point, etc. where the bus 3 is scheduled to stop in sequence.

[0026] 5 is an explanatory diagram showing an example of a location designation screen. An outline of this embodiment will be described below. As described above, the bus 3 is a shuttle bus that travels between a departure point and a destination, picking up passengers at the departure point and heading to the destination, and then picking up passengers again at the destination and returning to the departure point. Note that the points at which the bus 3 stops are not limited to the departure point and the destination, and passengers may be picked up or dropped off at other points between the departure point and the destination. The server 1 accepts requests to use the bus 3 from the user terminals 2 of each user, and generates an operation plan that specifies the outbound route to the destination and the return route back to the departure point.

[0027] The user terminal 2 first displays a location specification screen shown in FIG. 5 and accepts a specification input of a desired boarding location where the user wishes to board and a desired disembarking location where the user wishes to disembark. In the following description, for convenience, the desired boarding location where the user wishes to board and the desired disembarking location where the user wishes to disembark are collectively referred to as "desired location". For example, the user terminal 2 displays a map image on the location specification screen and accepts a specification input of the desired location from the user. Alternatively, the user terminal 2 may accept a text input of the desired location, have the server 1 search for candidate locations based on the input text, and accept a specification input of the desired location from the candidate locations. The user terminal 2 may also display a plurality of locations registered in advance as candidate locations and accept a specification input of the desired location from the displayed candidate locations. The user terminal 2 may also determine the user's current location based on location information acquired via the location information acquisition unit 26, and designate the user's current location as the desired boarding location.

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

[0029] First, when the user terminal 2 receives an operation input to the time icon 61, it pops up a time designation field 64. The user terminal 2 receives a designation input of a desired boarding time or a desired disembarking time through the time designation field 64. The desired boarding time and desired disembarking time are the time the user wishes to board the bus 3 and the time the user wishes to disembark from the bus 3 at the destination. For example, the user terminal 2 receives a designation input of either the desired boarding time or the desired disembarking time. For convenience in the following explanation, the desired boarding time and desired disembarking time will be collectively referred to simply as "desired time."

[0030] Furthermore, when the user terminal 2 receives an operation input to the luggage icon 62 or the number of people icon 63, it pops up and displays a luggage / number of people designation field 65. The user terminal 2 receives, through the luggage / number of people designation field 65, designation input regarding luggage information possessed by the user (for example, type of luggage (bag, suitcase, etc.), weight, size, number, etc.) and the number of users getting on.

[0031] The server 1 acquires from the user terminal 2 various information input to the user terminal 2 as described above, i.e., passenger information indicating the desired location, desired time, baggage information, number of passengers, etc., and accepts a utilization request. Based on the acquired passenger information, the server 1 generates an operation plan that specifies the route along which each bus 3 will operate while picking up and dropping off users (passengers).

[0032] In this embodiment, the bus 3 operates with only the user (and the user's baggage) on board, but the embodiment is not limited to this, and a transport request for only baggage may be accepted. The baggage referred to here includes baggage unrelated to the passengers of the bus 3, such as the baggage of a user who does not board the bus 3 but wishes to have the baggage transported to a hotel. For example, the server 1 accepts a transport request for baggage to be transported to a destination (including, for example, a dispatch point, a destination, a desired dispatch time, a desired arrival time, etc.) from the user terminal 2 in addition to the above passenger information. In this case, the server 1 regards the baggage as one of the objects to be transported, just like the passenger (user), and generates an operation plan by performing the following clustering. In this way, the server 1 may generate an operation plan for transporting baggage in addition to the user.

[0033] Fig. 7 is an explanatory diagram regarding the operation plan generation processing. An overview of the operation plan generation processing will be described with reference to Fig. 7. The server 1 acquires passenger information (first passenger information) including a desired point and a desired time from each user's user terminal 2, 2, 2.... The server 1 performs clustering to classify each user into a plurality of clusters (sets) based on the desired point and desired time indicated in the passenger information from each user.

[0034] A vector space related to clustering is conceptually illustrated in FIG. 7. In FIG. 7, the horizontal axis represents time, and the vertical axis represents geographical space (location). The upper side of the horizontal axis represents the vector space for the outbound journey, and the lower side represents the vector space for the return journey. The dotted lines on the vertical axis represent the boundaries of time periods separated by a predetermined time (e.g., 30 minutes). Note that, in practice, clustering is performed in a multidimensional space of three or more dimensions, but for convenience of illustration, the vector space is illustrated in two dimensions in FIG. 7.

[0035] The server 1 maps each user to a vector space based on the desired location and desired time of each user. The server 1 then performs clustering to group one or more users for each time period divided by a predetermined time, and generates each cluster. The clustering method is not particularly limited, but for example, the server 1 generates clusters using a method such as the k-means method or the c-means method.

[0036] The reason why the server 1 performs clustering for each predetermined time period is that, in this embodiment, it is assumed that the transfer to the airport is to be completed by a predetermined time before the flight takes off or lands. By generating clusters for each time period separated by a predetermined time, transfer to the destination can be performed in an optimal manner.

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

[0038] The server 1 groups one or more users whose desired locations and desired times are close to each other, and generates a cluster. The server 1 generates an operation plan for each bus 3 based on the clustering result.

[0039] Specifically, the server 1 generates an operation plan to assign a bus 3 to each cluster and have each user board for each cluster. For example, as shown in Fig. 7, the server 1 assigns one bus 3 to a cluster for the outbound (or return) journey in a certain time period, and then selects a cluster for the return journey to be assigned to that bus 3 in the next time period, and operates the bus so that users belonging to that cluster can board and disembark. The server 1 further selects a cluster for the outbound journey in the next time period and operates the bus. The server 1 assigns clusters to each of the multiple buses 3, 3, 3... that are instructed to operate by this system, and generates an operation plan to have users board all of the clusters.

[0040] For example, when the desired locations of each user in a cluster are different, the server 1 determines the boarding or disembarking points (hereinafter referred to as "boarding or disembarking points") where each user will board or disembark, and the boarding or disembarking times (hereinafter referred to as "boarding or disembarking times") where each user will board or disembark, and estimates the optimal route for operation while boarding or disembarking each user. The server 1 estimates the optimal route for each cluster and completes the operation plan.

[0041] In this embodiment, the server 1 generates the above operation plan using a traveling salesman problem technique. That is, when multiple buses 3, 3, 3... are given, the server 1 generates the operation plan by reducing it to a combinatorial optimization problem of finding an optimal solution for a combination of buses 3, 3, 3... that allows all users to get on and off. For example, the server 1 calculates a cost value for evaluating the operation plan based on the waiting time of each user, the waiting time of the bus 3 between clusters, the operating time of the bus 3, the operating distance, etc. The server 1 generates the operation plan so as to minimize the cost value.

[0042] In this case, the 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 the constraints. This makes it possible to appropriately manage the working environment of the driver of the bus 3.

[0043] In addition, it is preferable that the server 1 generates an operation plan for each bus 3 according to the number of buses 3 with no passengers among all the buses 3, 3, 3, .... The buses 3 with no passengers include, for example, buses 3 waiting at a specific vehicle depot and not in operation, buses 3 waiting on the road without passengers, and buses 3 operating without passengers (buses 3 being forwarded). For example, the server 1 generates an operation plan so as to reduce the overall number of operating buses 3 by calculating a lower cost value as the number of waiting buses waiting at the vehicle depot increases. In addition, for example, the server 1 generates an operation plan so as to reduce waste in the operation of the buses 3 by calculating a lower cost value as the number of waiting buses 3 on the road or the number of operating buses 3 without passengers decreases. This eliminates bias in the number of passengers, and allows the buses 3 to be operated appropriately.

[0044] The traveling salesman problem is an example of a method for optimizing an operation plan, and the server 1 may optimize the operation plan based on another algorithm.

[0045] The operation plan may be generated only once, or may be generated periodically or multiple times depending on changes in reservation status. For example, the server 1 generates an operation plan for a user who has applied for a reservation via a bus reservation screen by a predetermined reservation confirmation time (for example, a deadline for ordering the number of buses to be arranged on the day of operation from the bus operating company (for example, midnight on the day of operation)) and confirms the reservation. In this case, the server 1 repeats the generation of clusters until the schedule confirmation time, and generates operation plans sequentially. For example, even if the server 1 has already classified users A and B into a certain cluster and generated an operation plan, when a new request (reservation) for using the bus 3 is received from user C, if the cost of the operation plan is lower if the user B is excluded and users A and C are classified into the same cluster, the server 1 performs clustering again with users A and C in the same cluster. In this way, the server 1 repeatedly replaces the groups (clusters) to which the users belong, and generates operation plans sequentially. If the reservation confirmation time has passed, the groups of users who have made reservations are not replaced, and the update process of the operation plan described later is performed within a range where the groups are not replaced.

[0046] When generating the above operation plan, the server 1 may generate an operation plan in which the boarding or alighting time for the user is different from the desired time specified by the user. For example, when accepting a usage request, the server 1 accepts a setting input of the allowable time allowed by the user from the desired time, and acquires it as passenger information from the user terminal 2. As shown in Fig. 7, the server 1 moves the position of the user on the vector space within the range of the allowable time, and determines the bus 3 for the user to board.

[0047] In this case, as described later, it is preferable that the server 1 varies the fare for the user depending on the permissible time, which makes it possible to easily optimize the operation plan.

[0048] In addition, the server 1 may set not only the boarding and alighting times but also the boarding or alighting point where the user boards or alights from the user to a point different from the user's desired point. For example, the server 1 may set the boarding point to a point different from the desired point when boarding the user at a point different from the desired point will shorten the travel time by more than a reference time. For example, when the user's desired boarding point is a point on one lane side of a road, the server 1 sets the point on the opposite lane as the boarding point when boarding the user at a point on the opposite lane will shorten the travel time. Alternatively, the server 1 may set the boarding point to a point on the current route of the bus 3 that is closest to the user's desired boarding point. In this case, the boarding point may be a landmark on a map (such as an intersection or a facility).

[0049] In this case, for example, as described below, it is preferable that the server 1 notifies the user terminal 2 of the boarding point that is actually set. This makes it possible to easily guide the user to the boarding point.

[0050] Furthermore, the server 1 may refer to information other than the desired location and desired time to allocate (match) the bus 3 for the user to board, and generate an operation plan. For example, the server 1 performs clustering (classification) based on attribute information (passenger attribute information) such as age, sex, and nationality of each user, and selects the bus 3 for the user to board. For example, the server 1 matches attribute information between users, classifies users with the same or similar attribute information into the same cluster, and allocates the bus 3. This allows the bus 3 to be operated appropriately, for example by providing women-only cars.

[0051] The above is an example of allocation using user attribute information, and the present embodiment is not limited to this. For example, the server 1 may prevent fellow traders from being allocated to the same bus 3, depending on the organization (company, etc.) to which the user belongs. The server 1 may also preferentially allocate users with common hobbies to the same bus 3. Alternatively, the server 1 may preferentially allocate users with high ranks (customer loyalty). In this way, various methods of allocation based on user attribute information are possible.

[0052] Furthermore, for example, the server 1 may perform clustering based on attribute information of the driver of the bus 3 (driver attribute information) in addition to the user attribute information, and assign the bus 3. The driver attribute information may be, for example, the driver's skills (languages ​​that can be spoken, etc.) and user evaluations. For example, the server 1 matches the user attribute information with the driver attribute information, and selects a bus 3 for the user to board. This allows appropriate operation, such as assigning a bus 3 with a driver who can speak a language corresponding to the user's nationality, when the user is a foreign tourist.

[0053] Furthermore, for example, the server 1 may perform clustering based on attribute information (vehicle attribute information) of the bus 3 itself, and allocate the bus 3. The attribute information of the bus 3 may be, for example, a vehicle rank indicating an evaluation value of the bus 3, a seat rank indicating an evaluation value of each seat, whether it is a women-only vehicle or not, whether it is a welfare vehicle or not, services provided in the vehicle, etc. For example, when the server 1 acquires desired conditions such as the vehicle rank and seat rank of the bus 3 as passenger information from the user terminal 2, it performs matching with the attribute information of the bus 3 and selects the bus 3.

[0054] In performing the above matching (clustering), for example, when the server 1 receives a utilization request from the user terminal 2, it may receive input of desired conditions for passengers, drivers, buses 3, etc., and perform matching according to the desired conditions. Also, for example, the server 1 may automatically perform matching by referring to attribute information stored in each database, such as the user DB 141, bus DB 142, and driver DB 143, without receiving input of desired conditions.

[0055] Fig. 8 is an explanatory diagram regarding the update processing of the operation plan. In this embodiment, the server 1 continuously accepts a use request from the user terminal 2 and updates the operation plan in real time. Fig. 8 conceptually illustrates the process contents of the update processing of the operation plan.

[0056] FIG. 8A conceptually illustrates the processing contents when changing the operation plan and allowing a user who has newly accepted a use request to board the bus 3. When acquiring passenger information (second passenger information) of a new user from the user terminal 2, the server 1 judges whether or not the new user should be classified into a cluster of users who have already reserved the bus 3, based on the desired point and desired time indicated in the newly acquired passenger information. That is, as shown by the bold line in FIG. 8A, the server 1 maps the new user into a vector space based on the desired point and desired time, and judges whether or not the user has been classified into a cluster of users who have already reserved and a cluster for which an operation plan has been generated, as a result of performing clustering. When classified into a cluster for which an operation plan has been generated, the server 1 changes the operation route, operation time, etc. related to the operation plan of the cluster, and updates the operation plan to allow the user to board.

[0057] 8B conceptually illustrates the process of dynamically generating a cluster of users to be boarded next by the bus 3. As described above, the server 1 assigns the bus 3 to each cluster, and generates an operation plan for the bus 3 for each cluster. In this embodiment, at a predetermined timing after the bus 3 starts operating according to the operation plan for at least one cluster, the server 1 generates the next cluster following the one cluster, assigns the bus 3 to the cluster, and generates the next operation plan.

[0058] For example, after the operation of an operation plan related to one cluster is completed, or at a timing between the start of operation according to the operation plan and the completion of operation, the server 1 performs clustering of users who have a desired time in the time slot following the current time slot, and generates a new cluster. In this case, the server 1 performs clustering including the new user to the extent that does not cause a change in the group (cluster) of users who have made reservations. The server 1 selects a cluster to which the bus 3 should be assigned next from the newly generated clusters, and generates an operation plan for the selected cluster. As a result, the server 1 updates the operation plan, notifies the driver of the operation route, operation time, etc. related to the updated operation plan, and operates the bus 3.

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

[0060] Returning to Fig. 6, the explanation will be continued. When the designated input of the desired time, baggage information, number of people, etc. is completed, the user terminal 2 transmits the user's passenger information to the server 1. In this case, as described above, the server 1 generates an operation plan based on the passenger information of each passenger including the user. The user terminal 2 obtains information (operation guide) of the reserved bus 3 from the server 1 according to the generated operation plan, and displays it on the bus reservation screen.

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

[0062] In this case, when the server 1 generates an operation plan in which the boarding and alighting times of the user are different from the desired times, the server 1 sets the boarding fare to an amount discounted from the standard fare according to the allowable time allowed by the user, and displays the discounted boarding fare on the user terminal 2. This makes it easy to optimize the operation plan.

[0063] In this embodiment, an operation plan in which the boarding / alighting time is different from the desired time is generated when the difference between the boarding / alighting time and the desired time is within the allowable time, but this embodiment is not limited to this. For example, even if the difference is greater than the allowable time, the server 1 may generate an operation plan in which the difference between the boarding / alighting time and the desired time is greater than the allowable time if the discounted amount is output to the user terminal 2 and approval is obtained from the user.

[0064] Fig. 9 is an explanatory diagram showing an example of a reservation confirmation screen. On the bus reservation screen in Fig. 6, the user terminal 2 accepts an input from the user as to whether or not to reserve the displayed bus 3, and notifies the server 1. If a reservation is made, the server 1 notifies the driver's terminal 5 of the driving route and the like and operates the bus. The user terminal 2 transitions from the bus reservation screen to the reservation confirmation screen in Fig. 9, and notifies the user that the reservation of the bus 3 has been completed.

[0065] In this embodiment, confirmation of the reservation is received only from the user (passenger), but it is preferable to receive confirmation (approval) from the operating company of the bus 3 as in the third embodiment described later. The processing on the GUI (Graphical User Interface) for the operating company of the bus 3 and for each driver will be described in detail in the third embodiment.

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

[0067] For example, the user terminal 2 displays a map image as shown in the operation status confirmation screen on the left side of Fig. 10, and displays a user icon 101 indicating the user's current location and a stop position icon 102 indicating the planned stop position (boarding point) of the bus 3 on the map image. As described above, when an operation plan is generated for a boarding point different from the desired boarding point desired by the user, the server 1 notifies the user terminal 2 of the actual boarding point and displays the stop position icon 102 as shown in Fig. 10, thereby enabling smooth operation of the bus 3. Furthermore, by also displaying the user's current location, the bus 3 can be operated even more smoothly.

[0068] The user terminal 2 also displays the expected arrival time estimated from the distance between the current position of the bus 3 and the planned stop position of the bus 3. When the current position of the bus 3 moves to a position on the displayed map image, the user terminal 2 displays a bus icon 103 indicating the current position of the bus 3, as shown in the operation status confirmation screen on the right side of FIG.

[0069] Furthermore, for example, the user terminal 2 displays a bus information field 104 at the bottom of the screen, and displays information about the reserved bus 3 (for example, the vehicle registration number). Furthermore, for example, the user terminal 2 displays a call icon 105 and a message icon 106 for contacting the driver of the bus 3 in the bus information field 104. When an operation input to the call icon 105 or the message icon 106 is accepted, the user terminal 2 makes a call or transmits / receives a message with the driver's terminal 5 via the server 1. Furthermore, when an upward swipe operation on the bus information field 104 is accepted, the user terminal 2 displays the number of passengers, baggage information, destination or departure point, fare, etc., registered at the time of reservation.

[0070] In the above, the server 1 notifies the user terminal 2 of the user who has reserved the bus 3 of the operation status of the bus 3 and displays it, but the present embodiment is not limited to this. For example, the server 1 may also notify the user terminal 2 of other users (potential passengers) who have not reserved the bus 3 of the operation status and accept a request to use the bus 3. For example, the server 1 refers to the generated operation plan to determine the availability of the bus 3 in operation. If it is determined that there is an available seat, the server 1 notifies the user terminal 2 of the other user of the current location, destination, number of available passengers, etc. of the bus 3 and accepts a request to use the bus. Alternatively, the server 1 may output the information to a website, an electronic bulletin board installed at a predetermined location, a travel tour company, etc., and accept the request to use the bus. In this way, by outputting the availability status of the bus 3 and accepting a request to use the bus 3 from the output destination, the user can make a request to use the bus 3 in an appropriate manner, taking into consideration the availability status of the bus 3 currently in operation, when the user suddenly wants to use the bus 3.

[0071] When notifying the user of the availability of the bus 3, for example, the server 1 may obtain the user's schedule from an external API (scheduler) to determine whether or not the user is likely to board the bus, and notify the availability of the bus to users who are determined to be likely to board the bus. Whether or not a user is likely to board the bus is determined, for example, based on whether or not the user plans to board or disembark from an airplane, whether or not the user plans to participate in an event, whether or not the user plans to check in or check out from a hotel, etc. This can favorably encourage the user to use the bus 3.

[0072] 11 is a flowchart showing an example of a processing procedure executed by the server 1. The processing contents executed by the server 1 will be described with reference to FIG. The server 1 acquires passenger information (first passenger information) from each user's user terminal 2, 2, 2..., and accepts a request for use (step S11). The passenger information includes at least a desired location (desired boarding location or desired disembarking location) and a desired time (desired boarding time or desired disembarking time). More specifically, in addition to the desired location and desired time, the passenger information includes the number of passengers getting on and off, baggage information, the allowable time between the desired time and the actual boarding time, and the like.

[0073] The server 1 classifies each user into a plurality of clusters (sets) based on the desired location and desired time of each user (step S12). The server 1 then assigns a bus 3 to each cluster, and generates an operation plan for getting users on and off for each cluster (step S13). In this case, the server 1 may select a bus 3 for the user to board by referring to passenger attribute information, driver attribute information, vehicle attribute information, etc. in addition to the desired location and desired time, and generate an operation plan.

[0074] The server 1 sets the fare according to the generated operation plan, and notifies the user terminal 2 of information (operation guide) of the bus 3 including the fare (step S14). For example, when the boarding time of the user to board the bus 3 is different from the desired time, the server 1 sets the fare according to the allowable time set by the user. In addition to the fare, the server 1 notifies the user terminal 2 of information such as the operation route and required time of the bus 3, and receives a response as to whether or not to confirm the reservation of the bus 3. When a response to confirm the reservation of the bus 3 is received from the user terminal 2, the server 1 confirms the operation plan and notifies the driver terminal 5 of the operation route, etc. (step S15).

[0075] The server 1 further acquires passenger information (second passenger information) from the user terminal 2 of a new user different from the user (passenger who has already made a reservation) whose request was accepted in step S11, and accepts the request (step S16). Based on the newly acquired passenger information, the server 1 determines whether the user should be classified into a cluster that has already been generated (step S17). If it is determined that the user should be classified into a cluster that has already been generated (S17: YES), the server 1 updates the operation plan of the bus 3 corresponding to the cluster that has been determined to be classified by changing the operation route, operation time, etc. so that the user can board the bus (step S18).

[0076] After completing the process of step S18, or if the answer is NO in step S17, the server 1 judges whether it is a predetermined timing for generating the next operation plan for the bus 3 (step S19). The timing used as the judgment criterion in step S19 is at least the timing after the bus 3 starts operating to board and disembark users of the assigned cluster according to the current operation plan. For example, the server 1 judges whether it is the timing when the bus 3 completes operation according to the operation plan for the cluster, or the timing between the start of operation and the completion of operation.

[0077] When it is determined that it is time to generate the next operation plan (S19: YES), the server 1 performs clustering to classify 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, the server 1 assigns buses 3 to the newly generated clusters, and generates a new operation plan (step S21).

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

[0079] 12 is a flowchart showing an example of a processing procedure executed by the user terminal 2. The processing contents executed by the user terminal 2 will be described with reference to FIG. The user terminal 2 displays a location input screen, accepts input of a desired location, and transmits the input to the server 1 (step S41). The user terminal 2 transitions to a bus reservation screen, accepts input of a desired time, number of passengers, baggage information, etc., and transmits the input to the server 1 (step S42).

[0080] The user terminal 2 acquires information (operation guide) of the bus 3 to be dispatched to the user from the server 1 that has generated an operation plan based on the information input in steps S41 and S42, and displays it on the bus reservation screen (step S43). For example, the user terminal 2 displays the fare and required time for the bus 3, as well as the fare and required time for other means of transportation. The user terminal 2 determines whether or not to confirm the reservation for the bus 3 according to the operation input from the user (step S44).

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

[0082] As described above, according to this embodiment 1, an operation plan can be dynamically generated in an optimal manner based on passenger information (first passenger information) of users (passengers) who have already made reservations to use the bus 3 and passenger information (second passenger information) of a user who has newly requested to use the bus 3.

[0083] Furthermore, according to this embodiment 1, by performing clustering based on the boarding / alighting points and boarding / alighting times indicated by the passenger information and generating an operation plan for each cluster, it is possible to preferably generate an operation plan for a bus 3 in which multiple users share the bus.

[0084] Furthermore, according to this embodiment 1, it is possible to determine whether or not a user for whom a new usage request has been received should be classified into an existing cluster, and if it is determined that the user should be classified, the operation plan for that cluster is updated to allow the user to board and disembark, thereby enabling the operation plan to be updated in real time in an optimal manner.

[0085] Furthermore, according to the first embodiment, a more suitable operation plan can be generated by selecting a bus 3 for a user to board and disembark based on attribute information of the user (passenger), the driver, the bus 3 (vehicle), etc.

[0086] Furthermore, according to the first embodiment, it is possible to dynamically generate operation plans for the outbound and inbound journeys of the bus 3 that travels between a given departure point and destination.

[0087] Furthermore, according to this embodiment 1, by generating an operation plan based on the number of buses 3 that have no users among the multiple buses 3, 3, 3... for which an operation plan is generated, it is possible to optimize the operation efficiency of all the buses 3, 3, 3...

[0088] Furthermore, according to the first embodiment, when a passenger is to board at a boarding point different from the desired boarding point, the actual boarding point is notified to the user, thereby improving user convenience.

[0089] According to the first embodiment, the optimization of the operation plan can be facilitated by providing an allowable time between the desired boarding / alighting time and the actual boarding / alighting time. Also, by varying the fare according to the allowable time, an incentive can be given to the user to cooperate in optimizing the operation plan.

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

[0091] (Variation 1) In the first embodiment, it has been described that an operation plan is generated upon receiving a request to use the bus 3 from a new user other than a user who has made a reservation. However, the new user may be not only a user who is currently making a request to use (reservation) the bus 3, but also a user who is predicted to use the bus 3.

[0092] For example, the server 1 may predict the demand value of the bus 3 from other users (new users) who are expected to use the bus 3, in addition to the users who have made reservations, and generate an operation plan from the predicted demand value. The demand value is, for example, a predicted value that predicts the value related to the inflow and outflow of users at a departure point (hotel, etc.), a destination (airport, etc.), and other points. In the case of a hotel as an example, the server 1 predicts the desired location and desired time (second passenger information) of a usage request received from a user staying at the hotel based on the time slot of check-in or check-out at the hotel, the number of rooms in the hotel, etc. In addition, in the case of an airport as an example, the server 1 predicts the desired location and desired time of a usage request received from a user using the airport based on an aircraft flight schedule. The server 1 acquires demand information related to these demand values ​​from an external system (for example, a travel site, an aircraft reservation site, etc.) and uses it to generate an operation plan.

[0093] Specifically, the server 1 determines the number of buses 3 in operation depending on the level of the demand value, and generates an operation plan for operating with the determined number of buses in operation. For example, the server 1 increases the number of buses in operation on dates and times when the demand value is high, and distributes users among the buses 3, 3, 3..., so that it can also respond to new usage requests received on the same day. The server 1 also reduces the number of buses in operation on dates and times when the demand value is low, and generates an operation plan to increase the number of passengers per bus, thereby reducing the number of buses 3, 3, 3... to be secured.

[0094] Although the demand information for the bus 3 has been described above using a hotel and an airport as examples, the present embodiment is not limited to this, and the demand information may be any data that can predict a usage request from a new user. For example, the server 1 may predict a demand value from a past operation plan and use it to generate a new operation plan, without acquiring the demand information via an external system.

[0095] Also, for example, the server 1 may predict the supply value (supply information) of the bus 3, not the demand value of the bus 3, as to whether it is possible to board and disembark new users, and use this in the operation plan. The supply value of the bus 3 is, 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 the bus 3, as to whether it is possible for all users to board and disembark using the bus 3. For example, the server 1 predicts the occupancy rate and number of buses 3 in operation by time period with reference to past operation plans, and generates an operation plan for each time period from the predicted occupancy rate, etc. This allows the server 1 to generate an operation plan in an optimal manner, such as by not filling the bus 3 to capacity during certain time periods, but by providing a certain number of empty seats.

[0096] As described above, the server 1 may generate an operation plan based on demand information or supply information for the bus 3 from new users. In this case, it is preferable for the server 1 to set the fare for the user according to the demand information or supply information. For example, the server 1 sets the fare high for a time period when the demand value is high and many users are expected to use the bus. Also, for example, the server 1 sets the fare high for a time period when the supply value is low and there are expected to be few vacant seats on the bus 3. This is expected to distribute the frequency of use by each user and make the operation of the bus 3 smoother.

[0097] (Variation 2) In the first embodiment, a description has been given of a mode in which a user travels the entire route from one point (boarding point) to another point (drop-off point) by bus 3. However, a part of the travel from the one point to the other point may be combined with a public transportation mode other than the bus 3.

[0098] The public transportation means is, for example, an airplane, a train, etc., but is not particularly limited as long as it is a means of transportation other than the bus 3. The server 1 may generate an operation plan on the assumption that the user uses these public transportation means.

[0099] For example, when the fare is cheaper if the user travels a part of the distance between the desired boarding point and the desired disembarking point by public transportation, the server 1 proposes to the user to use the public transportation in combination with the bus 3. For example, when the server 1 acquires the passenger information (desired point, desired time, etc.) of the user and accepts a request to use the bus 3, the server 1 generates an operation plan for traveling the entire distance between the desired boarding point and the desired disembarking point by the bus 3, and an operation plan for combining the public transportation and the bus 3. Note that since a means for generating a travel route by combining a public transportation (airplane, train, etc.) with the bus 3 is well known, a description thereof will be omitted here. The server 1 calculates the fare of the bus 3 based on the former operation plan and the fare (the sum of the fare of the public transportation and the fare of the bus 3) based on the latter operation plan, and adopts the operation plan that combines the public transportation if the fare of the latter is lower than the fare of the former. For example, the server 1 outputs information of the adopted operation plan to the user terminal 2 and obtains approval from the user.

[0100] Furthermore, for example, when the bus 3 cannot operate on a portion of the distance between two points desired by the user, the server 1 suggests to the user to combine public transportation with the bus 3. This case can be considered as a long-distance trip (for example, between Tokyo and Fukuoka). For example, the server 1 determines whether the distance and travel time between two points are equal to or greater than a predetermined threshold, and if so, generates an operation plan that combines public transportation (for example, a plan to travel between Tokyo and Haneda by bus 3, and between Haneda and Fukuoka by airplane).

[0101] As described above, an operation plan may be generated by combining not only the bus 3 but also public transportation facilities.

[0102] (Embodiment 2) In the first embodiment, the bus 3 is a shuttle bus that travels to and from a specified destination. However, the bus 3 may be a demand bus that does not have a specific destination and travels around a certain area to allow users to get on and off. In the present embodiment, a description will be given of a mode in which the bus 3 is a demand bus that travels around a certain area.

[0103] Fig. 13 is an explanatory diagram showing an overview of the second embodiment. Fig. 13 conceptually illustrates a vector space at the time of clustering according to the present embodiment. The overview of the present embodiment will be described with reference to Fig. 13.

[0104] As described above, in this embodiment, the bus 3 does not have a specific departure point or destination, but travels around a certain area to get users on and off. Therefore, the server 1 does not divide the vector space into outbound and inbound routes, but instead divides the area traveled by the bus 3 into districts divided into predetermined units. Also, the time axis is divided into time periods of predetermined units, as in the first embodiment. As a result, the server 1 divides the vector space by district and time period, as shown in FIG. 13.

[0105] The server 1 maps each user to a vector space based on passenger information acquired from the user terminal 2 of each user. The server 1 then classifies each user into a plurality of clusters. When generating an operation plan, the server 1 first generates an operation plan by allocating a bus 3 to a cluster for a certain time period, and then generates the next operation plan by allocating a cluster for one of the districts among the clusters for the next time period. The server 1 optimizes the operation plan by using, for example, a method of the traveling salesman problem, as in the first embodiment.

[0106] In this case, it is preferable that the server 1 generates an operation plan according to the number of unoccupied buses 3, as in the first embodiment. Specifically, the server 1 generates an operation plan such that passengers are distributed among all the buses 3, 3, 3, ... by calculating a lower cost value as the number of unoccupied buses 3 is smaller.

[0107] As described above, the operation planning system according to the first embodiment can also be applied to a circular demand bus that does not have a specific destination. Since this embodiment is the same as the first embodiment except for the operation mode of the bus 3, detailed explanations of the flowchart and other details are omitted in this embodiment.

[0108] (Embodiment 3) In the first embodiment, it has been described that requests to use the bus 3 are accepted from each user (passenger) and clustered, and an operation plan is generated for each cluster to operate the bus 3. In the present embodiment, as a process for actually having an operator operate the bus 3, a process is described in which the generated operation plan is assigned to each driver and the bus 3 associated with the operator, and a driving route according to the assigned operation plan is presented to the driver of the bus 3 (driver's terminal 5).

[0109] FIG. 14 is an explanatory diagram showing an example of a list screen of an operation plan. As described above, the server 1 generates an operation plan for each cluster. In this embodiment, the server 1 distributes the operation plan corresponding to each cluster to the business operator terminal 4 and displays it on the list screen of FIG. 14. This embodiment can be used in any of the following situations: for example, a new cluster is generated based on a user who has accepted a request to use the bus 3, and then a bus 3 is dispatched for the new operation plan for each cluster (specifically, a cluster of people heading to the airport from their homes on a specific date and time is generated, and then an operation plan is generated, and a bus that runs from people's homes to the airport on a specific date and time is dispatched, etc.); or, when there is an operation plan that has already been generated, a user who has accepted a request to use the bus 3 while the bus 3 assigned to the operation plan is running is classified into the already generated cluster, and the boarding or alighting of the user is included in the already generated operation plan (specifically, when a user in the vicinity of a running taxi makes a request to use the taxi, the user is allowed to board the taxi).

[0110] For example, the business operator terminal 4 displays a list of information for each operation plan including the departure point and destination, operating time period, number of passengers, luggage information for each passenger, etc. Also, for example, for each operation plan, the business operator terminal 4 displays the driver and bus 3 automatically assigned by the business operator terminal 4 in a driver display field 41 and a bus display field 42 by default. For example, the driver display field 41 and the bus display field 42 each allow operation input using a pull-down menu, and the settings for the driver and bus 3 can be changed (setting input). When the route display 44 is selected, a route that passes through the departure point, boarding point, disembarking point, and destination point of the operation plan is displayed.

[0111] When the business operator terminal 4 automatically assigns a driver to the operation plan, it refers to the schedule of each driver (or the schedule of each vehicle, the same applies below in this embodiment) in FIG. 15A described later, and assigns a driver who is available in the schedule for the time period between the departure time and the arrival time in the operation plan (a driver who can transport according to the schedule). At that time, if there are multiple drivers who are available in the schedule, an appropriate driver may be assigned based on passenger information (language used, country of origin, address, location information, etc.) of the passengers who will board the operation plan, driver information (language used, passenger evaluation, location information, etc.), vehicle information (vehicle rank, seat rank, number of passengers that can board an available seat, etc.). In addition, if there are multiple drivers who are available in the schedule, a driver who is located in a close position to the passenger may be assigned. Specifically, a driver whose location information (GPS information) of the passenger is close to that of the driver may be assigned. In addition, a driver whose location at the predicted pick-up time based on the driver's work schedule is close to the pick-up point and pick-up time input by the passenger may be assigned (for example, if a passenger wishes to board from Haneda Airport at 2:00 p.m. in an operation plan, and the driver's schedule is for the passenger to be dropped off at Haneda Airport at 1:45 p.m., the driver will be assigned to the operation plan).

[0112] In addition, when the operator terminal 4 automatically assigns a vehicle (or a driver who drives the vehicle) to the operation plan, the operator terminal 4 may determine whether the number of passengers and the amount of passenger luggage included in the vehicle information of the bus 3 are transportable based on the number of passengers and the luggage information of the passengers included in the operation plan, and may assign a vehicle (or a driver who drives the vehicle) that can transport the passengers. In this case, if the number of passengers included in the operation plan is equal to or less than the number of passengers included in the vehicle information, it may be determined that the 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 the luggage can be transported. Furthermore, 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 number of passengers included in the vehicle information, it may be determined that the luggage can be transported when 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 on a seat in the vehicle where no passenger is riding. In determining whether or not it is possible to load luggage corresponding to the luggage information of a passenger included in the operation plan, which exceeds the range of the luggage capacity included in the vehicle information, in a seat in a vehicle where no passenger is seated, for example, one piece of luggage may be converted to one passenger in the vehicle (alternatively, a parameter may be determined in advance as to how many passengers each type of luggage is to be converted into, and the conversion may be performed based on the parameter), and if the total of the number of passengers in the vehicle included in the operation plan and the converted number of people is equal to or less than the maximum number of passengers included in the vehicle information, it may be determined that the luggage can be loaded. Note that, although an example of luggage carried by a passenger has been described here, luggage not carried by a passenger (luggage carried by a person other than a passenger, for example, when only luggage is transported by the vehicle) may also be determined.

[0113] When the operator terminal 4 automatically assigns a driver or vehicle to an operation plan, if the departure point, boarding point, disembarking point, or destination in the operation plan is not within the operator's service area (area where driving is possible), the operator may perform processing not to assign a driver or vehicle to the operation plan.

[0114] Through the above-mentioned process, the operator terminal 4 refers to the driver and vehicle schedules, passenger information, driver information, vehicle information, etc., to determine the drivers and vehicles to be assigned to the operation plan, and displays them as defaults. The operation operator operates the driver display field 41 and the bus display field 42 to arbitrarily change the settings of the driver and vehicle assignments displayed as defaults.

[0115] Fig. 15 is an explanatory diagram showing an example of a display screen of driver information. In response to an operation input from the transportation company, the business operator terminal 4 switches and displays the list screen of Fig. 14 to a schedule screen of Fig. 15A or a profile screen of Fig. 15B.

[0116] The schedule screen is a display screen that displays a list of the work schedule (operation schedule) of each driver who is engaged in driving under the operation company in a time chart. In addition, for example, the schedule screen also displays the working hours of each driver. Upon receiving an output request for the schedule screen from the company terminal 4, the server 1 generates the schedule screen by referring to the operation plan DB 144, and delivers it to the company terminal 4 for display.

[0117] The profile screen is a display screen that displays a list of each driver's attribute information (languages ​​that can be spoken in FIG. 15B) in addition to bibliographical information such as the name and phone number of each driver. In response to an output request from the business operator terminal 4, the server 1 generates a profile screen and displays it on the business operator terminal 4.

[0118] In this embodiment, the description will be given assuming that only driver information is displayed, but for example, the business operator terminal 4 may be configured to display a list of vehicle information such as the operation schedule, number of passengers, loadable luggage amount, and vehicle model of each bus 3 owned by the business operator. This allows the business operator to grasp the vehicle information and easily assign the buses 3.

[0119] The schedule screen and profile screen allow the operator to easily check the schedule and profile (particularly the driver's attribute information) of each driver. Returning to FIG. 14, the operator operates the driver display field 41 and the bus display field 42 to input changes to the allocation of drivers and buses 3 that were automatically assigned by default. Through the above-mentioned process, the operator can correct the allocation of drivers and buses 3 that was automatically determined by the operator terminal 4, and make the operation plan more appropriate.

[0120] In this embodiment, the operator terminal 4 automatically sets the allocation of drivers and buses 3, and the operation company changes it manually, but the operator terminal 4 may not allocate drivers and buses 3, and the operation company may set (determine) them manually. In other words, it is sufficient that the operator terminal 4 is capable of determining the allocation of drivers and / or buses 3, and the operator terminal 4 may automatically determine the allocation of drivers and / or buses 3, or may determine the allocation of drivers and / or buses 3 based on the results of manual input.

[0121] In the above, a driver who has free time between the departure time and arrival time of the bus 3 is assigned to the operation plan based on the driver's work schedule, but conversely, the driver's work schedule (i.e., work shift) may be changed according to the operation plan. For example, the business operator terminal 4 refers to a table that holds each driver's monthly work hours, daily work hours, number of holidays required, maximum driving distance per day that can be driven (traveled), etc., and assigns the driver to the operation plan of each bus 3, generates a work schedule, and presents it to the operation business operator (or the driver) for approval. In this way, instead of making an assignment based on the driver's schedule, the driver's schedule may be changed so that it can be assigned to the operation plan.

[0122] Furthermore, when changing the driver's schedule, the schedule may be changed taking into consideration the demand information described in Modification 1. For example, the business operator terminal 4 determines whether the demand value of the bus 3 (the predicted number of users getting on and off) is equal to or greater than a certain value, and if it is determined that the demand value is equal to or greater than the certain value, the upper limit of the working hours, etc. is raised to generate a schedule. In this way, the driver's schedule may be changed taking into consideration the demand for the bus 3.

[0123] The explanation will continue with reference to Fig. 14. The business operator terminal 4 displays an approval button 43 corresponding to each operation plan. When an operation input to the approval button 43 is accepted, an operation menu of "Approve" and "Reject" is displayed in a pull-down as shown in Fig. 14, and an operation input as to whether or not to approve the operation plan is accepted. Note that for an operation plan that has already been approved, the approval button 43 is changed to display "Approved". In this case, the business operator terminal 4 notifies (outputs) the server 1 that the operation plan is approved.

[0124] For example, the server 1 cooperates with a plurality of transport operators and distributes (outputs) operation plans to the operator terminal 4 of each transport operator. For example, the server 1 may display the screen of FIG. 14 on all the operator terminals 4 and accept approval for each operator on a first-come-first-served basis. Alternatively, the server 1 may hold a table relating to the priority of each operator, display each operation plan to the operator with the highest priority in order, accept approval if approval is obtained, and if approval is not obtained, repeatedly display each operation plan to the operator with the next highest priority until approval is obtained. When approval is received from the operator terminal 4 of one transport operator, the server 1 erases the approved operation plan from the list screen displayed on the operator terminal 4 of the other transport operators.

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

[0126] In the above embodiment, the operation company has been described as to whether or not to approve each operation plan displayed on the operator terminal 4. However, the operation company may also aggregate multiple operation plans into one operation plan and approve it. In other words, if there are operation plans that are close in section and time and can be operated even after aggregation, the operation company selects the operation plans that can be aggregated and then selects to aggregate, and the aggregated operation plan is displayed on the operator terminal 4. The operation company can approve the aggregated operation plan using the operator terminal 4.

[0127] In the above, approval (order) of the operation plan is accepted on a first-come, first-served basis, but this embodiment is not limited to this. For example, the server 1 may decide which operation company to entrust the operation to depending on the order fee for which the operation company undertakes the operation plan. For example, when the operator terminal 4 accepts the operation input of "approve", it further accepts the input of the order fee for the operation plan and notifies the server 1. The server 1 receives a notification regarding the order fee from the operator terminal 4 of each operation company, and decides to entrust the operation to the operation company with the lowest order fee, for example. By deciding the operator to whom the operation plan is entrusted depending on the order fee, the shuttle service can be implemented appropriately.

[0128] In this case, it is preferable that the server 1 sets a time limit (for example, 5 minutes) from the distribution of the operation plan to the acceptance of the notification of the order fee. By setting a time limit, it is possible to promptly approve (accept) the operation plan.

[0129] In the above, the operator manually approves (receives) the operation plan, but the operator terminal 4 may automatically approve (receive) 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 (in this case, the driver and bus 3 may be assigned as a process including the approval process). The operator terminal 4 may automatically approve operation plans that satisfy predetermined conditions (for example, the distance between the departure point and the destination is equal to or greater than a predetermined distance, the number of passengers is equal to or greater than a predetermined number, etc.) among operation plans for which the driver and bus 3 have been assigned.

[0130] In addition, when server 1 receives the operational input of "Approve" from multiple operators, the method of determining an operator may be 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 that can fit, rank, etc.), order fee, etc.

[0131] When the server 1 receives approval of the operation plan from the business operator terminal 4, it notifies the user terminal 2 of an e-mail, short mail message, etc. (not shown) including the boarding time, boarding point, etc., as well as the operation company, type of bus 3, etc. In this case, for example, the server 1 generates an e-mail or the like with a request for confirmation of opening (viewing) and notifies the user terminal 2. When the notification is opened, the user terminal 2 automatically replies to the server 1 that the notification has been opened. When the server 1 receives the reply, it notifies the business 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 operator to act as an intermediary between the user and the operation company.

[0132] Even after the transportation company approves the operation plan, passengers who can be classified into the operation plan may be classified into the operation plan.

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

[0134] For example, the driver terminal 5 first displays a list of each operation plan (outbound or return trip) for which the driver is in charge on the day, as shown on the left side of Fig. 16. When each text showing an operation plan is tapped, the driver terminal 5 displays the boarding and alighting times and boarding and alighting points of each user in a pull-down menu.

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

[0136] For the sake of simplicity, the following description will only cover the outward journey in which the bus 3 departs from the departure point, picks up users at each stop, and travels to the destination.

[0137] The driver terminal 5 first displays the route to the boarding point of the first user. In addition to the route, the driver terminal 5 displays information such as the address of the boarding point and the name of the user who will board the vehicle at the bottom of the screen. For example, the driver terminal 5 also displays the estimated arrival time at the boarding point, the estimated departure time from the boarding point, the distance from the current position, the remaining operating time predicted from the current position, etc.

[0138] In addition, for example, the driver terminal 5 displays objects such as a call icon 161, a message icon 162, etc., at the bottom of the screen for contacting the user who will board the vehicle at the displayed boarding point. When an operation input to the call icon 161 or the message icon 162 is accepted, the driver terminal 5 makes a call or transmits a message to the user terminal 2 of the user via the server 1.

[0139] For example, the driver's terminal 5 switches the display at the bottom of the screen to the display on the right side of Fig. 16 in response to an operational input from the driver. Specifically, the driver's terminal 5 displays an arrival button 163 at the bottom of the screen for inputting arrival at the boarding point. Note that, for example, the driver's terminal 5 may automatically display the arrival button 163 in response to the distance between the current position of the bus 3 and the boarding point, etc.

[0140] When the bus 3 arrives at the boarding point, the driver taps the arrival button 163. When the driver terminal 5 receives an operation input to the arrival button 163, it determines that the bus 3 has arrived at the boarding point, and notifies the user terminal 2 that the bus 3 has arrived via the server 1. For example, the driver terminal 5 may notify the user by means of an email, a short mail message, or the like, or may make a call to the user terminal 2. This makes it possible to promptly notify the user that the bus 3 has arrived. Also, even if the driver does not tap the arrival button 163, when the driver terminal 5 determines that the bus 3 has arrived at the boarding point from the position information of the bus 3, the driver terminal 5 notifies the user terminal 2 that the bus 3 has arrived via the server 1.

[0141] When the user has boarded, the 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 receives an operation input from the driver to determine whether the user has boarded. Alternatively, the server 1 may determine whether the user has boarded based on the position information of the bus 3 and the user (user terminal 2), respectively. When the user has boarded, the driver's terminal 5 displays the route to the next user's boarding point and resumes operation.

[0142] If the user does not arrive at the boarding point even when it is time to board, i.e., if the user misses the boarding, the server 1 may cancel the user's boarding plan. For example, if the server 1 determines that the arrival button 163 has not been operated by the boarding time and that the user has not boarded, it inquires of the user terminal 2 whether or not to cancel the boarding. As in the above, the server 1 may automatically determine whether or not the user has boarded based on location information, etc. If the server 1 receives a response from the user terminal 2 in response to the inquiry that the cancellation is approved, the server 1 cancels the user's boarding plan and notifies the driver terminal 5 of that effect.

[0143] If the user misses the bus, the server 1 may have the user board another bus 3. For example, the server 1 identifies a bus 3 with an available seat among the buses 3 operating in the vicinity from the operation plan DB 144, and notifies the driver terminal 5 of the driver of the bus 3 to board the user.

[0144] Although the above describes a case where the user's arrival is delayed, the bus 3 may arrive late or early. In that case, the server 1 may change the bus 3 to which the user is to board depending on the operation status of each bus 3, 3, 3, .... For example, when the operation schedule of the bus 3 that the user plans to board is delayed (when the arrival time at each boarding and alighting point where each user plans to board and alight is later than the scheduled boarding and alighting time by a certain time or more), if the operation schedule of the following bus 3 (a bus 3 that has the same departure place and destination as the preceding bus 3 and has a later departure time than the preceding bus 3) is also delayed, the server 1 allows the user to board the following bus 3. Also, for example, when the operation schedule of the bus 3 that the user plans to board is earlier (when the arrival time at each boarding and alighting point where each user plans to board and alight is earlier than the scheduled boarding and alighting time by a certain time or more), if the operation schedule of the preceding bus 3 is also earlier, the server 1 allows the user to board the preceding bus 3. In this way, the server 1 may correct (update) the operation plan so as to change the bus 3 that the user boards depending on the operation status of the buses 3, 3, 3 . . .

[0145] When the server 1 confirms (determines) that a user has boarded at one boarding point, the server 1 may notify the user terminal 2 of the user who will board at the next boarding point that another user (previous passenger) has boarded at the previous boarding point and the estimated arrival time of the bus 3 at the next boarding point. This allows each user to accurately know the operating status of the bus, improving convenience.

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

[0147] In the case of the return trip, 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 an operation input to the arrival button 163, notifies each user's user terminal 2 that the bus 3 has arrived, and allows the user to board. The driver terminal 5 displays the route to each user's drop-off point according to the operation status of the bus 3, switches the operation route every time the bus passes a drop-off point, and provides route guidance so that the bus 3 heads to each drop-off point.

[0148] 17 is a flowchart showing an example of a processing procedure executed by the operator terminal 4. The processing contents executed by the operator terminal 4 will be described with reference to FIG. The business operator terminal 4 acquires from the server 1 a plurality of operation plans generated based on the usage requests (passenger information) from each user (step S301). The business operator terminal 4 determines the drivers and vehicles to be assigned to each operation plan based on the contents of the operation plan, the driver schedule, the vehicle schedule, the passenger information, the driver information, the vehicle information, etc. (step S302). The business operator terminal 4 displays a list of the acquired plurality of operation plans (step S303). In this case, the business operator terminal 4 displays a list of operation plans to which the drivers and vehicles determined in step S302 are assigned.

[0149] The business operator terminal 4, in accordance with the operation input from the operating company, displays a list of driver information for each driver engaged in driving the bus 3 under the operating company (step S304). For example, as illustrated in FIG. 15, the business operator terminal 4 displays a list of each driver's bus 3 operation schedule, each driver's profile including driver attribute information, etc. The business operator terminal 4 returns to the list screen of operation plans in accordance with the operation input from the operating company, and accepts setting input 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 the driver may also be decided, so it is not essential to receive input of vehicle information. Conversely, once a vehicle is decided, the driver who will drive the vehicle may also be decided, so it is not essential to receive input of driver information.

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

[0151] Although not shown in FIG. 17, the process of the server 1 after S307 will be described. When the server 1 receives a notification from the business operator terminal 4 that the operation company approves the operation plan, the server 1 performs a process of assigning the operation company (which may be a driver or vehicle of the operation company) to the operation plan based on the reception. In this way, even after the process of assigning the operation company to the operation plan, a passenger who has newly requested use may be classified into a cluster corresponding to the operation plan, and the operation plan may be modified. The modification of the operation plan may be made on the condition that the operation company approves the modified operation plan. In addition, such a modification of the operation plan may be made up to a predetermined time before the operation start time. Furthermore, the operation plan may be determined to be finalized at a time before the operation start time, and each user who is transported based on the operation plan may be notified of the boarding time of each user.

[0152] FIG. 17 has been described as a flowchart showing an example of the processing procedure executed by the business operator terminal 4. However, the processing from S301 to S305 may be performed by the server 1, and an operation plan in which the driver and vehicle are set may be transmitted to the business operator terminal 4, and the business operator terminal 4 may determine whether or not to approve the operation plan (step S306).

[0153] 18 is a flowchart showing an example of a processing procedure executed by the driver terminal 5. The processing contents executed by the driver terminal 5 will be described with reference to FIG. The driver terminal 5 acquires from the server 1 an operation plan generated based on a usage request (passenger information) from each user (step S321). For example, the driver terminal 5 acquires information on one or more operation plans that the driver plans to operate on that day. The driver terminal 5 displays the acquired one or more operation plans and accepts a selection input of an operation plan that displays an operation route (step S322).

[0154] The driver terminal 5 displays the operation route for each user for the selected operation plan (step S323). For example, in step S323, the driver terminal 5 first displays the route to the boarding point of the user who will be boarded first. For example, in addition to the route to the boarding point, the driver terminal 5 displays the scheduled arrival time at the boarding point, the scheduled departure time from the boarding point, the distance from the current position, the remaining operation time, etc. In addition, for example, the driver terminal 5 displays objects (such as a call icon 161 and a message icon 162) for contacting the user who will be boarded at the boarding point.

[0155] The driver terminal 5 judges whether to contact the user who is scheduled to board the vehicle in response to the operation input to the contact object (step S324). If it is judged that the user should be contacted (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 point via the server 1 (step S325).

[0156] After step S324 is NO or the process of step S325 is executed, the driver terminal 5 judges whether or not the bus 3 has arrived at the boarding point based on the operation input to the arrival button 163 (step S326). If it is judged that the bus 3 has not arrived (S326: NO), the driver terminal 5 returns the process to step S324. If it is judged that the bus has arrived (S326: YES), the driver terminal 5 notifies the user terminal 2 of the user corresponding to the boarding point via the server 1 that the bus 3 has arrived (step S327).

[0157] The driver terminal 5 judges whether or not a user has boarded the vehicle in response to an operation input from the driver (step S328). If it is judged that a user has not boarded the vehicle (S328: NO), the driver terminal 5 waits for processing. If it is judged that a user has boarded the vehicle (S328: YES), the driver terminal 5 judges whether or not all users have boarded the vehicle (step S329). If it is judged that all users have not boarded the vehicle (S329: NO), the driver terminal 5 switches to and displays a route to the boarding point of the next user (step S330), and returns processing to step S324. If it is judged that all users have boarded the vehicle (S329: YES), the driver terminal 5 displays a route to the destination (step S331), and ends the series of processing.

[0158] When the driver's terminal 5 reaches the destination, the driver's terminal 5 may notify the server 1 that the destination has been reached. When the server 1 reaches the destination, the driver's terminal 5 may notify the user that the destination has been reached and may perform a process related to the user's payment of the fare.

[0159] As described above, according to the third embodiment, it is possible to support the smooth execution of an operation plan that is automatically generated by the server 1.

[0160] The embodiments disclosed herein are illustrative in all respects and should not be considered as limiting. The scope of the present invention is defined by the claims, not by the above meaning, and is intended to include all modifications within the scope and meaning equivalent to the claims. [Explanation of symbols]

[0161] 1. Server (information processing device) 11 Control section 12 Main memory 13. Communications Department 14 Auxiliary storage P1 Program 141 User DB 142 Bus DB 143 Driver DB 144 Operation plan DB 2. User terminal 21 Control section 22 Main memory 23 Communications Department 24 Display section 25 Input section 26 Location information acquisition section 27 Auxiliary storage P2 Program 3. Bus (vehicle) 4. Operator terminal 5 Driver's terminal

Claims

1. an acquisition unit that acquires passenger information indicating a boarding point or an alighting point of a passenger using a vehicle and a boarding time or an alighting time of the passenger; a generation unit that generates an operation plan for the plurality of vehicles indicating a route for boarding or disembarking the passengers based on the passenger information, the acquisition unit acquires the passenger information including an allowable time between a boarding time or an alighting time desired by the passenger and a boarding time or an alighting time at which the vehicle boards or alights the passenger, The generation unit generates the operation plan in which the boarding time or the disembarking time is defined within the range of the allowed time, a setting unit that sets a boarding fare for the passenger in accordance with the allowable time when the boarding time or the alighting time of the passenger in the operation plan generated by the generation unit differs from the boarding time or the alighting time desired by the passenger; a reception unit that receives, from the passenger, an input of whether or not to approve the operation plan in which a difference between the boarding time or alighting time of the passenger and a boarding time or alighting time desired by the passenger is equal to or greater than the allowable time, When an input indicating that the operation plan is approved is received, the generation unit generates the operation plan in which the difference is equal to or greater than the permissible time.

23. An information processing apparatus comprising:

2. The vehicle is a vehicle in which a plurality of the passengers share a ride, A classification unit that classifies the passengers into a plurality of groups based on the passenger information, The generation unit generates the operation plan indicating a route for operating the vehicle by boarding or disembarking the plurality of passengers for each of the sets.

2. The information processing apparatus according to claim 1,

3. The acquisition unit acquires first passenger information indicating a boarding point or an alighting point of the passenger who has already reserved use of the vehicle by a predetermined time point and a boarding time or an 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 a boarding point or alighting point of a new passenger who has applied to use the vehicle after the predetermined time point and a boarding time or alighting time of the new passenger, When the second passenger information is acquired, the classification unit determines whether or not the new passenger should be classified into the set of passengers who have already made reservations based on the second passenger information; When it is determined that the new passenger should be classified into the group, the generation unit updates the already-generated operation plan so that the new passenger gets on or off the vehicle corresponding to the group, within a range in which the group to which the passenger who has already made a reservation belongs is not changed.

3. The information processing apparatus according to claim 2.

4. The acquisition unit acquires demand information related to a demand of the new passenger or supply information related to a supply of the vehicle, The generation unit generates the operation plan in which vacant seats are provided in the vehicle according to the demand information or the supply information.

4. The information processing apparatus according to claim 3.

5. The generation unit generates the operation plan by referring to the number of the vehicles waiting at a vehicle depot among the plurality of the vehicles.

5. The information processing device according to claim 1, wherein the information processing device is a computer.

6. The generation unit generates the operation plan to board the passenger at a boarding point different from a boarding point desired by the passenger when the operation time would be shorter if the passenger were to board the passenger at the different boarding point, A notification unit that notifies the passenger of the boarding point determined in the operation plan.

6. The information processing device according to claim 1,

7. The generation unit generates the operation plan for having the passenger board at a boarding point located in a lane opposite to a lane in which a boarding point desired by the passenger is located.

7. The information processing apparatus according to claim 6,

8. The generation unit generates the operation plan for having the passenger board at a point on a current operation route of the vehicle that is closest to a boarding point desired by the passenger.

7. The information processing apparatus according to claim 6,

9. Acquire passenger information indicating a boarding point or an alighting point of a passenger using the vehicle and a boarding time or an alighting time of the passenger; Based on the passenger information, an operation plan for the plurality of vehicles is generated, which indicates a route along which the passengers are to board or disembark. An information processing method in which a process is executed by a computer, comprising the steps of: Acquire the passenger information including an allowable time between a boarding time or alighting time desired by the passenger and a boarding time or alighting time at which the vehicle boards or alights the passenger; generating the operation plan in which the boarding time or the disembarking time is set within the range of the allowable time; If the boarding time or alighting time of the passenger in the generated operation plan differs from the boarding time or alighting time desired by the passenger, a boarding fare of the passenger is set according to the allowable time; Accept an input from the passenger as to whether or not to approve the operation plan in which a difference between the boarding time or alighting time of the passenger and a boarding time or alighting time desired by the passenger is equal to or greater than the allowable time; When an input indicating that the operation plan is approved is received, the operation plan is generated so that the difference is equal to or greater than the allowable time. An information processing method characterized in that the processing is executed by a computer.

10. Acquire passenger information indicating a boarding point or an alighting point of a passenger using the vehicle and a boarding time or an alighting time of the passenger; Based on the passenger information, an operation plan for the plurality of vehicles is generated, which indicates a route along which the passengers are to board or disembark. A program for causing a computer to execute a process, Acquire the passenger information including an allowable time between a boarding time or alighting time desired by the passenger and a boarding time or alighting time at which the vehicle boards or alights the passenger; generating the operation plan in which the boarding time or the disembarking time is set within the range of the allowable time; If the boarding time or alighting time of the passenger in the generated operation plan differs from the boarding time or alighting time desired by the passenger, a boarding fare of the passenger is set according to the allowable time; Accept an input from the passenger as to whether or not to approve the operation plan in which a difference between the boarding time or alighting time of the passenger and a boarding time or alighting time desired by the passenger is equal to or greater than the allowable time; When an input indicating that the operation plan is approved is received, the operation plan is generated so that the difference is equal to or greater than the allowable time. A program that causes a computer to execute a process.

Images