Demand-responsive traffic management system

Abstract

We provide a demand-responsive traffic management system that enables efficient vehicle operation. [Solution] Up until the reservation deadline, the system accepts reservations from each user that include the desired boarding and alighting points from a predetermined number of stops to a designated bus, and the desired boarding and alighting times, specifying the times for at least one of the boarding and alighting points. Based on the content of the reservations received from each user, the system provisionally determines the operating schedule for the bus 6. For users who have made reservations but whose boarding or alighting is not possible according to the provisionally determined operating schedule, the system proposes alternative options for boarding the bus.

Description

Technical Field

[0001] The present invention relates to a demand-responsive traffic management system for managing the operation of demand-responsive traffic.

Background Art

[0002] Conventionally, in sparsely populated areas where public transportation such as buses and trains is not sufficiently developed, as a means for users to move, demand-responsive transport (DRT) is operated based on reservations from users rather than operating on a predetermined route and schedule. In such demand-responsive traffic, a plurality of users who have made reservations in advance will share the same vehicle and move, and an operation plan (such as an operation route and an operation schedule) is determined each time based on the reservation details of those multiple users.

[0003] For example, Japanese Unexamined Patent Application Publication No. 2021-15379 discloses that when receiving a provisional reservation specifying a boarding location, a destination, a desired boarding time, a desired alighting time, etc. from a plurality of users who wish to use demand-responsive transport, an operation plan that can meet the demands of the most users during the usage time period is determined, and the operation is carried out according to the determined operation plan.

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] In Patent Document 1, the operating schedule is determined to accommodate the requests of as many users as possible who have made a provisional reservation. However, a considerable number of users who have made a provisional reservation will not be able to board or alight according to their desired reservation details. In Patent Document 1, such users are notified that their reservation could not be made or are notified to change their reservation details, but this operation does not adequately address the needs of users who were unable to make a reservation. Furthermore, in order to operate on-demand transportation efficiently, it was also desired to increase the number of passengers as much as possible.

[0006] The present invention was made to solve the aforementioned problems of the conventional system, and aims to provide a demand-responsive transportation management system that enables sufficient care for users who are unable to board or alight according to their reservations in the operation management of on-demand transportation, and enables efficient operation by maximizing the number of passengers. [Means for solving the problem]

[0007] To achieve the above objective, the demand-responsive traffic management system according to the present invention is a demand-responsive traffic management system that manages the operation of a shared vehicle used by multiple users who have made a reservation in advance, and includes a reservation acceptance means that accepts reservations from each user until the reservation deadline, which include a desired boarding and alighting point from a predetermined number of candidate points and a desired boarding and alighting time that specifies the desired time for at least one of boarding and alighting from the shared vehicle; a provisional operation plan determination means that provisionally determines an operation plan for the shared vehicle based on the content of the boarding reservations accepted by each user in the reservation acceptance means; and an alternative proposal means that proposes an alternative plan for riding the shared vehicle to users who are unable to ride, who are users whose reservations cannot be made according to the provisionally determined operation plan. Here, the "operation plan" includes at least one of the following: the route (what route will be taken) and the schedule (what times will the train run). [Effects of the Invention]

[0008] According to the on-demand transportation management system of the present invention having the above configuration, in the operation management of on-demand transportation in which shared vehicles are operated based on reservations from users, it becomes possible to adequately care for users who are unable to board or alight the vehicle as reserved by proposing alternative options for boarding the shared vehicle. On the other hand, it also becomes possible to operate efficiently by maximizing the number of passengers. [Brief explanation of the drawing]

[0009] [Figure 1] This is a schematic diagram showing the demand traffic management system according to this embodiment. [Figure 2] This is a block diagram showing the configuration of the demand traffic management system according to this embodiment. [Figure 3] This is a block diagram showing the configuration of the communication terminal according to this embodiment. [Figure 4] This is a flowchart of the reservation acceptance processing program according to this embodiment. [Figure 5] This diagram shows an example of the display of the passenger request input screen shown on the display. [Figure 6] This figure shows an example of the display screen for passengers requesting to disembark. [Figure 7] This is a flowchart of the provisional operation plan determination processing program according to this embodiment. [Figure 8] This is a flowchart of the provisional operation plan determination processing program according to this embodiment. [Figure 9] This diagram shows an example of a bus stop layout. [Figure 10] This diagram shows examples of when a user is set to a "boarding available" flag and when they are set to a "boarding unavailable" flag. [Figure 11] This is a diagram for explaining a method of searching for an operation route of a shared vehicle. [Figure 12] This is a diagram showing an example display of a provisional operation plan guidance screen displayed on a display. [Figure 13] This is a flowchart of a sub - processing program for boarding adjustment processing. [Figure 14] This is a diagram for explaining an alternative plan to change the boarding position to another stop. [Figure 15] This is a diagram for explaining an alternative plan to change the boarding position to a virtual stop. [Figure 16] This is a flowchart of a sub - processing program for position adjustment processing. [Figure 17] This is a diagram showing an example display of an alternative plan guidance screen displayed on a display. [Figure 18] This is a flowchart of a sub - processing program for time adjustment processing. [Figure 19] This is a diagram showing an example display of an alternative plan guidance screen displayed on a display. [Figure 20] This is a flowchart of an operation plan addition / modification processing program according to this embodiment. [Figure 21] This is a flowchart of an operation plan confirmation processing program according to this embodiment.

Mode for Carrying Out the Invention

[0010] Hereinafter, an embodiment in which the demand traffic management system according to the present invention is embodied will be described in detail with reference to the drawings. First, the schematic configuration of the demand traffic management system 1 according to this embodiment will be described using FIGS. 1 and 2. FIG. 1 is a schematic configuration diagram showing the demand traffic management system 1 according to this embodiment. FIG. 2 is a block diagram showing the configuration of the demand traffic management system 1 according to this embodiment.

[0011] As shown in FIG. 1, the demand traffic management system 1 according to the present embodiment basically includes a management server 3 provided in a management center 2 that manages and operates demand traffic, a communication terminal 5 possessed by a user 4 who is a user of demand traffic, and a vehicle (hereinafter referred to as a shared vehicle 6) that operates in demand traffic. Further, the management server 3, the communication terminal 5, and the shared vehicle 6 are configured to be able to transmit and receive electronic data to and from each other via a communication network 7. Note that examples of the communication terminal 5 include a mobile phone, a smartphone, a tablet terminal, a personal computer, and the like.

[0012] Here, the management server 3 is a device that accepts a ride reservation from the communication terminal 5 and determines an operation plan for the shared vehicle 6 according to the content of the accepted ride reservation. Note that, unlike a taxi, the shared vehicle 6 is basically assumed to be used by a plurality of users sharing a ride. Therefore, the management server 3 accepts ride reservations from a plurality of users within a predetermined reservation acceptance period, and determines an operation plan to satisfy the requests of as many users as possible among the plurality of users who have accepted the ride reservation. Further, in the present embodiment, the management server 3 also proposes an alternative for the user 4 who cannot board or alight from the shared vehicle 6 according to the reserved content, as will be described later. On the other hand, the operation plan finally determined in the management server 3 is transmitted to the shared vehicle 6, and the shared vehicle 6 operates according to the transmitted operation plan.

[0013] In the context of on-demand transportation, two types are generally known: "semi-demand" and "full-demand." "Semi-demand" operates somewhat similarly to conventional public transportation, with designated boarding and alighting locations (stops) and times for shared vehicles. There is also a predetermined reservation period, during which reservations can be made. The service plan is determined by reviewing all reservations received during this period to accommodate as many users as possible. On the other hand, "full-demand" allows users to board and alight at virtually any point of their choice, with the time of boarding and alighting freely selected. There is also generally no reservation period, and the service plan is determined on a case-by-case basis, prioritizing users who have made reservations first.

[0014] In the following explanation, the on-demand transportation managed by the Demand Transportation Management System 1 will be described using the example of a "semi-demand" operation. However, the invention of this application is not limited to "semi-demand" but may also be applicable to "full-demand" transportation.

[0015] In addition to users directly making reservations for rides on the management server 3 via the communication terminal 5, users can also request reservations from operator 8 via telephone or email, and operator 8 will then operate an information terminal 9 (such as a PC or tablet). Operator 8 is a natural person and may be an employee of the management center 2 or a person who has a contract with the management center 2. Operator 8 will understand the reservation details from the user via telephone or email and then perform the reservation operation on behalf of the user.

[0016] Furthermore, the passenger vehicles 6 managed and operated by the demand traffic management system 1 are equipped with on-board devices 10, such as navigation systems, and the management server 3 is connected to the on-board devices 10 installed in the passenger vehicles 6 in a communication-enabled manner. When the management server 3 has finalized the operation plan for the passenger vehicles 6, it distributes information about the operation plan to the passenger vehicles 6 via the communication-enabled on-board devices 10. The operation plan includes the route (what route will be taken) and the schedule (what times will be traveled). In addition, the on-board devices 10 are equipped with displays and speakers, and the operation plan is communicated to the passengers via the displays and speakers. Furthermore, if the on-board devices 10 are navigation systems, it is also possible to set the route to be the navigation system's guided route according to the operation plan transmitted from the management server 3.

[0017] Furthermore, the passenger vehicle 6 may be capable of not only manual driving based on the driver's input, but also assisted driving through automated driving assistance, where the vehicle drives automatically without driver input. And, if the vehicle is capable of assisted driving through automated driving assistance, it may be an automated driving vehicle that drives automatically according to a route plan transmitted from the management server 3, for example. Also, the number of passenger vehicles 6 managed and operated by the demand traffic management system 1 is not limited to one; there may be multiple vehicles.

[0018] On the other hand, the communication terminal 5 is an information terminal owned by the user 4 and equipped with functions such as connecting to a web server and navigation functions, such as a mobile phone, smartphone, tablet terminal, or personal computer. In particular, if the communication terminal 5 is a terminal capable of running applications such as a smartphone, an application program is installed that enables online reservations for rides on the shared vehicles 6 managed and operated by the demand traffic management system 1. These functions for making online reservations for the shared vehicles 6 may be part of the navigation function that provides directions to the destination, or they may be executed by an application program separate from the navigation function.

[0019] Furthermore, the communication network 7 includes numerous base stations located throughout the country and communication companies that manage and control each base station, and is constructed by connecting the base stations and communication companies to each other via wired (optical fiber, ISDN, etc.) or wireless connections. Here, each base station has a transceiver (transceiver) and an antenna that communicates with the communication terminals 5. In addition to conducting wireless communication between communication companies, the base stations also serve as the end of the communication network 7 and have the role of relaying communications between the communication terminals 5 within the range (cell) of the base station's radio waves and the management server 3.

[0020] Next, the configuration of the management server 3 in the demand traffic management system 1 will be explained in more detail using Figure 2. As shown in Figure 2, the management server 3 comprises a server control unit 11, a user DB 13 stored in an information recording means connected to the server control unit 11, a vehicle DB 14, a map stop DB 15, and a server-side communication device 16.

[0021] The server control unit 11 is a control unit (MCU, MPU, etc.) that controls the entire management server 3, and is equipped with a CPU 21 as an arithmetic unit and control device, RAM 22 used as working memory when the CPU 21 performs various arithmetic processing, a ROM 23 that stores control programs as well as the reservation acceptance processing program (Figure 4), the provisional operation plan determination processing program (Figures 7 and 8), the operation plan addition and modification processing program (Figure 20), the operation plan finalization processing program (Figure 21), etc., and a flash memory 24 that stores programs read from the ROM 23. The server control unit 11, together with the control unit of the communication terminal 5, has various means as processing algorithms. For example, the reservation acceptance means accepts reservations from each user until the reservation deadline, including the desired boarding and alighting locations from a predetermined list of candidate locations, and the desired boarding and alighting times, which specify the desired times for at least one of boarding and alighting from the vehicle. The provisional operation plan determination means provisionally determines the operation plan for the passenger bus based on the content of the passenger reservation received from each user by the reservation acceptance means. The alternative proposal means proposes alternative plans for passengers who are unable to board or alight the passenger bus according to the provisionally determined operation plan, to users who are unable to board according to the content of their reservation, among the users whose reservations have been accepted by the reservation acceptance means. The operation plan modification means modifies the provisionally determined operation plan according to the alternative plan as necessary, if an unable passenger who has been offered an alternative plan by the alternative proposal means agrees to the alternative plan. The passenger guidance means provides passenger guidance to each user, including the unable passenger who has agreed to the alternative plan, based on the operation plan modified by the operation plan modification means. In other words, the control units provided by the server control unit 11 and the communication terminal 5 are examples of reservation acceptance means, provisional operation plan determination means, alternative proposal means, operation plan modification means, and passenger guidance means.

[0022] Furthermore, User DB13 is a database that stores information about User 4, who is a user of the on-demand transportation service. Prior registration is generally required to use the on-demand transportation service. User 4, as a user of the on-demand transportation service, enters their information in advance using a communication terminal 5 or paper registration application forms, and this information entered by User 4 is stored in User DB13. Information stored in User DB13 includes, for example, the user's name, address, contact information, and payment method for the usage fee. Additionally, when a ride reservation is received from a registered User 4, the reservation details are also stored in User DB13, linked to the information of the corresponding User 4.

[0023] Furthermore, the vehicle DB14 is a database that manages information about the passenger buses 6 that are managed and operated by the demand-responsive transport management system 1. Specifically, for each passenger bus 6 under management, the database stores the vehicle type (such as the maximum number of passengers it can carry), the vehicle's current location, and, if it is in operation, its route and schedule. If multiple passenger buses 6 are being managed, this information is stored for each of the multiple passenger buses 6.

[0024] On the other hand, the map stop DB15 is a storage means that stores map information registered based on external input data and input operations. Here, the map information consists of various types of information necessary for route searching, route guidance, and map display, including road networks. For example, it consists of network data including nodes and links that show the road network, link data related to roads (links), node data related to node points, intersection data related to each intersection, location data related to locations such as facilities, map display data for displaying maps, search data for searching for routes, search data for searching for locations, etc.

[0025] Furthermore, the map stop database 15 also stores stop data 17 that identifies the locations and names of stops (candidate locations) where the passenger bus 6 stops in the area where the passenger bus operates, i.e., where user 4 boards or alights from the passenger bus 6. However, in on-demand transport, stops are not necessarily places where the passenger bus 6 stops, but rather places where it may only stop when a user requests to board or alight. In other words, a stop is a place where the passenger bus 6 can stop and allow users to board or alight. In addition, as described later, the management server 3 may temporarily set up virtual stops at locations that are not originally designated stops in order to allow users 4 who are unable to board or alight as per their reservations to board, and information about these virtual stops is also stored in the map stop database 15. Details of virtual stops will be described later.

[0026] Furthermore, bus stops are used as stopping points for the passenger vehicles 6 when the on-demand service is "semi-demand." When the on-demand service is "fully on-demand," bus stops generally do not exist, although bus stops may be set up even in the case of "fully on-demand" service. In addition, the user database 13, vehicle database 14, and map bus stop database 15 may be provided by external servers other than the management server 3, and the management server 3 may obtain them from these external servers via communication.

[0027] On the other hand, the server-side communication device 16 is a communication device for communicating with the communication terminal 5 via the communication network 7. In addition to the communication terminal 5, it is also possible to receive traffic information consisting of various types of information such as congestion information, regulation information, and traffic accident information transmitted from the Internet network and traffic information centers, such as VICS (registered trademark: Vehicle Information and Communication System) centers. Furthermore, it is possible to receive information on surrounding events and weather information in addition to traffic information from external servers other than traffic information centers. As mentioned above, the management server 3 is also connected to the information terminal 9 operated by the operator 8 and the in-vehicle unit 10 of the passenger vehicle 6.

[0028] Next, the general configuration of the communication terminal 5 will be explained using Figure 3. Figure 3 is a schematic block diagram showing the control system of the communication terminal 5 according to this embodiment. In the following explanation, we will use the case where the communication terminal 5 is a smartphone as an example.

[0029] As shown in Figure 3, the communication terminal 5 is configured such that a CPU 31, a memory 32 storing user information (user ID, name, etc.) about the user 4 who possesses the communication terminal 5, a transceiver circuit (RF) 33 that transmits and receives signals to and from base stations of the communication network 7, a baseband processing unit 34 that converts RF (Radio Frequency) signals received by the transceiver circuit 33 into baseband signals and converts baseband signals into RF signals, an input / output unit 37 which is an interface with a microphone 35 and a speaker 36, a display 38 made of a liquid crystal display panel, an input operation unit 39 made of a touch panel and hard buttons, a GPS 40, and a camera 41 are connected to the data bus BUS.

[0030] Here, the CPU 31 built into the communication terminal 5 is a control means for the communication terminal 5 that performs various operations according to the operation program stored in the memory 32, and together with the memory 32, constitutes the communication terminal control unit 42. Furthermore, the various processing contents of the communication terminal control unit 42 are displayed on the display 38 as needed.

[0031] Furthermore, memory 32 is a storage medium that stores user information (user ID, name, etc.) related to user 4 who possesses the communication terminal 5. It also stores various application programs, including the reservation acceptance processing program (Figure 4) described later, for making online reservations for rides on the shared vehicle 6. Map information may also be stored in memory 32. Memory 32 may also be composed of a hard disk, memory card, etc.

[0032] Furthermore, the display 38 is located on one side of the casing and uses a liquid crystal display or an organic EL display, etc. It displays the top screen for running various applications installed on the communication terminal 5, screens related to the running application (internet screen, email screen, etc.), and various information such as images and videos. In particular, in this embodiment, it displays a reservation screen for making online reservations for the passenger bus 6, a notification screen for the operation schedule of the reserved passenger bus 6, and alternative options proposed by the management server 3 if the desired reservation cannot be made.

[0033] Furthermore, the input operation unit 39 is composed of a touch panel located on the front of the display 38 and hard buttons located on the casing. The communication terminal control unit 42 controls the system to perform various operations based on electrical signals output when the touch panel or hard buttons are pressed. In this embodiment, it is also operated when making an online reservation for the passenger vehicle 6. The input operation unit 39 can also be composed of various keys such as number / character input keys, cursor keys to move a cursor for selecting displayed content, and a confirmation key to confirm the selection.

[0034] Furthermore, the GPS 40 can detect the current location and current date and time of the communication terminal 5 (i.e., user 4) by receiving radio waves generated by artificial satellites. In addition to the GPS 40, the system may also be configured to include other devices (such as a gyro sensor) for detecting the current location and orientation of the communication terminal 5.

[0035] Furthermore, the camera 41 is a small imaging device consisting of a camera using a solid-state image sensor such as a CCD, and is built into the back of the communication terminal 5. With a dedicated application program running, the user can capture images of the surrounding area by operating the input operation unit 39. The images captured by the camera 41 are stored in the memory 32.

[0036] Next, the reservation acceptance processing program executed on the management server 3 and communication terminal 5 having the above configuration will be described with reference to Figure 4. Figure 4 is a flowchart of the reservation acceptance processing program according to this embodiment. Here, the reservation acceptance processing program is executed after a predetermined application program for making reservations for rides on the shared vehicle 6 is started on the communication terminal 5, and is a program that accepts ride reservations from users. The program shown in the flowchart in Figure 4 below is stored in the memory 32 of the communication terminal 5 or in the RAM 22 or ROM 23 of the management server 3, and is executed by the CPU 31 or CPU 21.

[0037] First, we will explain the reservation acceptance processing program that is executed on the communication terminal 5. In step 1 (hereinafter abbreviated as S), the CPU 31 launches a predetermined application program (hereinafter referred to as the "ride reservation app") for making online reservations for the shared vehicle 6. Note that the ride reservation app can be launched not only by the user 4 performing a predetermined operation on the communication terminal 5, but also, for example, by selecting a link on the management company's website or by scanning a QR code in an advertisement with the communication terminal 5. It is assumed that the ride reservation app has been downloaded from a web server or the like and installed on the communication terminal 5 beforehand.

[0038] When the ride reservation application is launched on the communication terminal 5, the display 38 first outputs the ride request input screen 51 shown in Figure 5. As shown in Figure 5, the ride request input screen 51 displays an input screen for the user to input their ride request details (reservation details) when making a reservation for the shared vehicle 6. Specifically, it is an input screen for entering the desired boarding location and the desired boarding time for the shared vehicle 6. Then, in S2, the CPU 31 first inputs the reservation details based on the user's operation of the input operation unit 39.

[0039] In the case of "semi-demand" on-demand transportation, the locations and times where passengers can board and alight from the shared bus 6 are predetermined to some extent. More specifically, the locations where passengers can board and alight from the shared bus 6 are the bus stops stored in the bus stop data 17 (Figure 2) of the aforementioned map bus stop DB 15, and these are predetermined by the management company, targeting locations with high demand for boarding and alighting (for example, hospitals, train stations, city halls, shopping malls, etc.). Therefore, users select a bus stop as their desired boarding location for the shared bus 6.

[0040] The boarding request input screen 51 displays, for example, the names of bus stops near the user's current location or registered home, and the available boarding times for each stop. Alternatively, the user may register their walking distance in advance, and the boarding request input screen 51 may display only bus stops within walking distance from the user's current location or registered home. When the user selects one of the bus stops displayed on the boarding request input screen 51, the selected bus stop is entered as the desired boarding point for the bus 6. Furthermore, the available boarding times set for the selected bus stop are entered as the desired boarding times for the bus 6. Additionally, the user can switch between a list view and a map image view, and bus stops can be selected from either display screen. In the map image view, as shown in Figure 5, icons 52 are displayed at the locations of bus stops on the map image. When the user selects an icon 52, the name of the bus stop corresponding to the selected icon 52 and the available boarding times for that stop are displayed.

[0041] In the example shown in Figure 5, selecting a bus stop as the desired boarding location automatically determines the desired boarding time as well. However, it is also possible to allow users to select a desired boarding time from multiple options for each bus stop. Alternatively, users may be allowed to freely input their desired boarding time. Furthermore, it is also possible to allow users to select a desired boarding time within a certain range (for example, 13:00 to 13:15). In addition, if there are many bus stops, it is possible to sort them. It should be noted that the desired boarding time entered by the user in S2 is only a rough estimate and is not necessarily the actual boarding time. After the management server 3 determines the operation plan, the actual boarding time may differ from the entered desired boarding time.

[0042] Then, once the user has finished entering their boarding preferences (reservation details) on the boarding preference input screen 51, the display 38 then shows the alighting preference input screen 53 shown in Figure 6. The alighting preference input screen 53 is an input screen for the user to enter their alighting preferences (reservation details), and more specifically, it is an input screen for entering the desired alighting location and the desired alighting time from the bus 6. Then, in S2, the CPU 31 also inputs the reservation details regarding alighting based on the user's operation on the input operation unit 39.

[0043] As mentioned above, when the on-demand transport is "semi-on-demand," the locations where passengers can board and alight from the shared vehicle 6 are pre-designated as bus stops. Therefore, just as with the boarding location, users select a bus stop as their desired disembarking point from the shared vehicle 6.

[0044] The disembarkation request input screen 53 displays, for example, bus stops near a destination previously entered by the user, along with the available disembarkation times for each stop. The location of the destination is indicated by a destination icon 54. Alternatively, the user may register their walking distance in advance, and the disembarkation request input screen 53 may display bus stops within walking distance of the user's destination. When the user selects one of the bus stops displayed on the disembarkation request input screen 53, the selected bus stop is entered as the desired disembarkation point from the bus 6. Furthermore, the available disembarkation times set for the selected bus stop are entered as the desired disembarkation times from the bus 6. In addition, the user can switch between a list display and a map image display, and bus stops can be selected from either display screen. When using the map image display, icons 52 are displayed at the locations of bus stops on the map image, as shown in Figure 6. When the user selects an icon 52, the name of the bus stop corresponding to the selected icon 52 and the available disembarkation times at that bus stop are displayed.

[0045] Furthermore, if the user has not entered a destination, for example, if the user boards at a bus stop entered as the desired boarding point, all possible disembarking stops may be displayed on the disembarking request input screen 53.

[0046] Additionally, the fare is displayed on the drop-off request input screen 53. Note that the fare is determined by the combination of the boarding and alighting stops selected, and is therefore not something the user typically chooses. Depending on the management company, the fare may be a fixed rate regardless of the stop combination.

[0047] Furthermore, it is not always necessary to enter both the desired boarding time and the desired alighting time. For example, a user who has only decided on a departure time can specify only the desired boarding time, and similarly, a user who has only decided on an arrival time at their destination can specify only the desired alighting time. Alternatively, the alighting request input screen 53 can be displayed before the boarding request input screen 51, allowing the user to enter the desired alighting and alighting locations before entering the desired boarding and alighting locations.

[0048] Furthermore, in the example shown in Figure 6, selecting a bus stop as the desired disembarkation point automatically determines the desired disembarkation time as well. However, it is also possible to allow users to select a desired disembarkation time from multiple options for each bus stop. Alternatively, users may be allowed to freely input their desired disembarkation time. It is also possible to allow users to select a desired disembarkation time within a certain range (for example, 13:30 to 13:45). Additionally, if there are many bus stops, sorting is also possible. It should be noted that the desired disembarkation time entered by the user in S2 is only a rough estimate and is not necessarily the actual disembarkation time. After the management server 3 determines the operation plan, the actual disembarkation time may differ from the entered desired disembarkation time.

[0049] Please note that the input method for reservation details disclosed in Figures 5 and 6 is just one example, and other input methods can be adopted. For example, users may be allowed to freely specify their desired pick-up and drop-off times. Other conditions besides the desired pick-up location, pick-up time, drop-off location, and drop-off time may also be input. Furthermore, if the on-demand transport is "fully on-demand," it is possible to input any location other than a bus stop (such as the user's current location or home) as the desired pick-up and drop-off locations.

[0050] Next, in S3, the CPU 31 transmits the reservation details of the passenger reservation entered in S2 to the management server 3. The reservation details of the passenger reservation include the desired boarding location, desired boarding time, desired alighting location, and desired alighting time, as well as the user ID that identifies the sending user and the current location of the sending communication terminal 5 (i.e., the user's current location). Upon receiving the reservation details of the passenger reservation, the management server 3 accepts the reservation and determines the operation plan for the passenger vehicle 6, as described below (Figures 7 and 8).

[0051] Next, we will describe the reservation acceptance processing program that is executed on the management server 3. First, in S11, the CPU 21 receives the reservation details of the ride reservation transmitted from the communication terminal 5. The reservation details of the ride reservation include the user ID that identifies the user who sent the reservation, the current location of the communication terminal 5 (i.e., the user's current location), the desired boarding location, the desired boarding time, the desired alighting location, and the desired alighting time.

[0052] Subsequently, in S12, the CPU 21 stores the reservation details of the ride reservation received in S11 in the user DB 13, linked to the user who made the reservation. This allows the CPU to accept ride reservations from users. Note that if the on-demand transport is "semi-demand," there is a set reservation acceptance period during which ride reservations can be made, but reservations made after the reservation acceptance period will still be accepted. However, reservations made after the reservation acceptance period are processed differently from reservations made within the reservation acceptance period, as described later (Figure 20). Details will be described later.

[0053] Furthermore, as mentioned above, in addition to users directly making reservations for the shared vehicle 6 via the communication terminal 5, users can also request reservations from the operator 8 via telephone or email, and the operator 8 will make the reservation by operating the information terminal 9 (such as a PC or tablet). Therefore, in S12, the CPU 21 accepts reservations entered by the operator 8 operating the information terminal 9, in addition to reservations made from the communication terminal 5.

[0054] Furthermore, if reservations are received from multiple users, the reservation details for each user are stored in the user DB13. The CPU21 then determines the operation plan for the passenger vehicle 6 based on the reservation details for each user stored in the user DB13, as described below (Figures 7 and 8).

[0055] Next, the provisional operation plan determination processing program executed on the management server 3 will be explained with reference to Figures 7 and 8. Figures 7 and 8 are flowcharts of the provisional operation plan determination processing program according to this embodiment. Here, the provisional operation plan determination processing program is a program that provisionally determines the operation plan of the passenger vehicle 6 based on the passenger reservations received from each user in the aforementioned reservation acceptance processing program (Figure 4). The programs shown in the flowcharts in Figures 7, 8, 13, 16, 18, 20, and 21 are stored in the RAM 22, ROM 23, etc., of the management server 3 and are executed by the CPU 21.

[0056] First, in S21, the CPU21 determines whether the deadline for reservations (hereinafter referred to as the reservation deadline) has passed. The reservation deadline is set, for example, 30 minutes before the scheduled departure time of the passenger vehicle 6, but this time can be changed as appropriate. If the passenger vehicle 6 operates multiple times a day, a reservation deadline will be set for each operation.

[0057] If it is determined that the reservation deadline has arrived (S21:YES), the process proceeds to S22. Conversely, if it is determined that the reservation deadline has not arrived (S21:NO), the provisional operation plan determination processing program is terminated.

[0058] In S22, the CPU21 reads the reservation details of the passenger boarding reservations stored in the user DB13 up to that point. The user DB13 stores the reservation details of the passenger boarding reservations received by the aforementioned reservation acceptance processing program (Figure 4), separated by user. In other words, what is read in S22 are the passenger boarding reservations of all users that were accepted within the reservation acceptance period.

[0059] Next, in S23, the CPU21 sets the starting stop for the passenger bus 6. For example, the starting stop could be a bus depot or a bus stop near the management company. The starting stop is predetermined by the management company, but it may be changed for each trip. For users whose desired boarding point is the starting stop, users who set their desired boarding time before the passenger bus 6's start time will have the boarding availability flag set (S28), while users who set their desired boarding time after the start time will have the boarding non-available flag set (S29).

[0060] Next, in S24, the CPU21 searches for a route from the starting stop (hereinafter referred to as the starting stop) to the stop closest to it. For the search for a recommended route, for example, the well-known Dijkstra's algorithm is used, and the route with the smallest total cost value is selected as the recommended route. The search data contained in the map information stored in the map stop DB15 is used to calculate the cost value. Traffic information obtained from an external server is also used. The search data stores cost calculation data used to calculate node costs (intersection costs), which quantify the degree of appropriateness of a route to an intersection, and link costs, which quantify the degree of appropriateness of a route to links that make up a road. Therefore, for example, among the routes that can make up a route from the starting stop to the stop closest to it, the route with the smallest sum of link cost and node cost is identified as the recommended route.

[0061] The process in S24 will be explained using, for example, an area where bus stops A to F are set, as shown in Figure 9. In the example shown in Figure 9, the starting bus stop is bus stop A, so in S24, the route from bus stop A to the nearest bus stop B is first searched for.

[0062] Next, in S25, the CPU 21 determines whether the bus stop that is the end point of the route searched in S24 (bus stop B in the example shown in Figure 9) is a bus stop selected by any user as a desired boarding point (hereinafter referred to as the desired boarding stop). The determination process in S25 is made based on the contents of the boarding reservation read from the user DB 13 in S22.

[0063] Then, if it is determined that the stop at the end of the route searched in S24 is the desired boarding stop (S25: YES), the process proceeds to S26. On the other hand, if it is determined that the stop at the end of the route searched in S24 is not the desired boarding stop (S25: NO), the process proceeds to S30.

[0064] In S26, the CPU 21 calculates the estimated arrival time when the passenger vehicle 6 will reach its final stop (stop B in the example shown in Figure 9) if it travels along the route discovered in S24. The estimated arrival time is calculated using the departure time from the starting stop, the route length, and traffic information obtained from an external server. Furthermore, the CPU 21 also determines whether the calculated estimated arrival time is sufficient to reach the boarding time requested by the user who has booked that stop as their boarding point.

[0065] Then, if it is determined that the scheduled arrival time of the passenger vehicle 6 at the final stop of its route can be reached by the boarding time requested by the user who has reserved that stop as their boarding point (S26: YES), the route searched in S24 is provisionally set as part of the passenger vehicle 6's route (S27). If there are multiple users who have reserved the final stop of the route as their boarding point, the system determines it to be YES if it can reach the boarding time requested by at least one user. Furthermore, the CPU 21 sets a boarding availability flag for users who have reserved the final stop of the route as their boarding point (S28). The boarding availability flag is linked to the user and stored in the user DB 13. The system then proceeds to S33.

[0066] On the other hand, if it is determined that the scheduled arrival time of the passenger vehicle 6 at the final stop of its route cannot be reached by the boarding time requested by the user who has reserved that stop as their boarding point (S26: NO), the route searched in S24 is not provisionally set as part of the passenger vehicle 6's route. The CPU 21 then sets a boarding unavailable flag for the user who has reserved the final stop of the route as their boarding point (S29). The boarding unavailable flag is stored in the user DB 13, associated with the user. The process then proceeds to S33. If there are multiple users who have reserved the final stop of the route as their boarding point, and some users can reach the stop by the boarding time while others cannot, a boarding available flag is set for users who can reach the stop by the boarding time, and a boarding unavailable flag is set for users who cannot reach the stop by the boarding time.

[0067] The processes described in S26 to S29 will be explained using, for example, an area where bus stops A to F are set, as shown in Figure 10. As shown in Figure 10, if a route 55 from bus stop A to bus stop B is searched in S24, and the estimated arrival time at bus stop B is 13:13, and there is a user a whose desired boarding point is bus stop B, and user a's desired boarding time is 13:15, then route 55 will be provisionally set as part of the route of the bus 6, and a boarding availability flag will be set for user a. On the other hand, if user a's desired boarding time is 13:10, then route 55 will not be provisionally set as part of the route of the bus 6, and a boarding unavailable flag will be set for user a.

[0068] On the other hand, in S30, the CPU 21 determines whether the stop that is the end point of the route searched in S24 (stop B in the example shown in Figure 9) is a stop that has been selected as a desired disembarking point by any user who currently has a boarding flag set (i.e., a user who is already on board when the bus 6 reaches that stop) (hereinafter referred to as the desired disembarking stop). The determination process in S30 is made based on the contents of the boarding reservation read from the user DB 13 in S22.

[0069] Then, if it is determined that the stop at the end of the route searched in S24 is the desired disembarking stop (S30: YES), the process proceeds to S31.

[0070] In S31, the CPU 21 determines that the final stop on the route is the stop where the passengers will disembark, and therefore provisionally sets the route explored in S24 as part of the route of the passenger vehicle 6 (S31). After that, the process proceeds to S32. In the example shown in Figure 7, it is not determined whether the passenger vehicle 6 can reach the stop by the time the passengers wish to disembark. However, after calculating the estimated arrival time of the passenger vehicle 6 at the stop, it may be determined whether the passenger vehicle 6 can reach the stop by the time the passengers wish to disembark. If it is determined that the passenger vehicle 6 cannot reach the stop by the time the passengers wish to disembark, the route explored in S24 may not be provisionally set as part of the route of the passenger vehicle 6, and a "cannot board" flag may be set for the passengers whose desired disembarkation point is that stop.

[0071] On the other hand, if it is determined that the stop at the end of the route searched in S24 is neither the desired boarding stop nor the desired alighting stop (S30: NO), then the route from the starting stop to the next closest stop to the starting stop is searched (S32). For example, in the example shown in Figure 9, the route from stop A to the nearest stop B is searched first. If it is determined that stop B is neither the desired boarding stop nor the desired alighting stop, then the route to stop C, which is closest to stop A, is searched next. Then, the processing from S25 onwards is executed again for the route from stop A to stop C. If it is determined that stop C is neither the desired boarding stop nor the desired alighting stop, then the route to stop D, which is closest to stop A, is searched next.

[0072] Subsequently, in S33, CPU21 determines the desired boarding and alighting stops for all users who made a reservation during the reservation period, as described in S25-S32, and also determines whether either the boarding flag or the boarding ineligible flag has been set.

[0073] If the result in S33 is NO, the CPU 21 changes the endpoint of the currently provisionally set route to a new starting point and searches for a route from the starting stop (hereinafter referred to as the starting stop) to the stop closest to the starting stop (S36). For example, as shown in Figure 11, if a route 55 from stop A to stop B has already been provisionally set, the starting stop is stop B, so in S36, the route from stop B to the nearest stop C is searched. Then, the processing from S25 onwards is executed again for the route from stop B to stop C. The starting stop switches in the same manner from stop C → stop D → stop E → ... and so on, and this is repeated until the judgment condition in S33 is met.

[0074] On the other hand, if the answer in S33 is YES, it means that the route provisionally set up to this point passes through the stops that all users with the boarding availability flag have requested as their boarding point, and also passes through the stops that all users who have boarded have requested as their alighting point. Therefore, the CPU 21 provisionally decides the provisionally set route as the route for the passenger bus 6 (S34). The CPU 21 also decides on an operating schedule that specifies the arrival and departure times for each stop that the passenger bus 6 will pass through, based on the provisionally decided operating route, the departure time of the starting stop, and the boarding and alighting times of all users with the boarding availability flag. It is desirable that the operating schedule be determined by referring to traffic information obtained from an external server. The operating schedule should be designed to accommodate the requests of as many users as possible. However, the operating route and operating schedule provisionally decided in S34 are only provisional and may be modified later as needed. Furthermore, the method for determining the route of the passenger vehicle 6 described in S22-S33 above is just one example, and the route of the passenger vehicle 6 may be determined by other methods. Even when using other methods, the search for a route will be conducted in such a way that as many users who have made reservations as possible can ride the passenger vehicle 6 according to their preferences.

[0075] Subsequently, in S35, the CPU 21 transmits the operation plan, including the route and schedule of the passenger vehicle 6 which were provisionally determined in S34, to the communication terminals 5 of all users who have the boarding availability flag set. The communication terminals 5 that receive the operation plan then display the operation plan on the display 38 and provide guidance on boarding the passenger vehicle 6. As a result, all users who have the boarding availability flag set can not only confirm that their boarding reservation is complete but also understand the schedule on which the passenger vehicle 6 will operate. The process then proceeds to S37.

[0076] Figure 12 shows the provisional route plan guidance screen 61 displayed on the display 38 of the communication terminal 5 to which the route plan of the passenger bus 6 was transmitted in S35. As shown in Figure 12, the provisional route plan guidance screen 61 displays the name of the bus stop where the user will board and the boarding time (the time when the passenger bus 6 departs from that stop), the name of the bus stop where the user will alight and the alighting time (the time when the passenger bus 6 arrives at that stop), and the fare. The boarding and alighting times are determined from the route schedule. The boarding and alighting times are basically the boarding and alighting times requested by the user when making a reservation, but there may be cases where the boarding time is later than the requested boarding time, or the alighting time is earlier than the requested alighting time. In addition, the provisional route plan guidance screen 61 may also display the entire route of the provisionally determined passenger bus 6, or display the arrival and departure times of bus stops other than the boarding and alighting stops.

[0077] Next, in S37, CPU21 reads the reservation details of the passenger reservations stored in user DB13 for users who have made passenger reservations and for whom the passenger reservation flag was set in S29, that is, users who cannot board or alight according to the provisionally determined operating plan (hereinafter referred to as passenger reservation users).

[0078] Subsequently, in S38, the CPU21 performs the passenger adjustment process described later (Figure 13). The passenger adjustment process proposes alternative options for passengers who are unable to board the bus 6, and if the passengers who are unable to board agree to the alternative option, it modifies the operation plan provisionally decided in S34 as necessary to allow boarding and alighting using the alternative option.

[0079] Next, in S39, the CPU 21 determines whether or not it has performed the boarding adjustment process in S38 for all users who are ineligible to board. If it is determined that the boarding adjustment process in S38 has been performed for all users who are ineligible to board (S39: YES), the process proceeds to S40. The process also proceeds to S40 if there are no users who are ineligible to board. On the other hand, if it is determined that the boarding adjustment process in S38 has not been performed for all users who are ineligible to board (S39: NO), the process returns to S37.

[0080] In S40, the CPU 21 transmits the operation plan, including the route and schedule of the passenger transport vehicle 6 modified in the passenger adjustment process in S38 (Figure 13), to the communication terminals 5 of all users who have the "available to board" flag set. The communication terminals 5 that receive the operation plan then display the operation plan on their displays 38 and provide guidance on boarding the passenger transport vehicle 6. As a result, all users who have the "available to board" flag set will be able to understand what schedule the passenger transport vehicle 6 will operate on after the operation plan has been modified. Note that the content displayed on the display 38 of the communication terminal 5 is the same as the provisional operation plan guidance screen 61 (Figure 12) that has already been described, so no further explanation is given. However, if there are no users who are unable to board or if the operation plan was not modified in the passenger adjustment process in S38 (Figure 13), the process in S40 may be omitted.

[0081] Next, the subprocessing of the passenger adjustment process performed in S38 will be explained with reference to Figure 13. Figure 13 is a flowchart of the subprocessing program for the passenger adjustment process.

[0082] First, in S41, the CPU21 performs the position adjustment process (Figure 16) described later. The position adjustment process proposes an alternative to boarding the shared vehicle 6 to users who are unable to board by changing their boarding position.

[0083] Next, in S41, the CPU21 performs the time adjustment process (Figure 18) described later. The time adjustment process proposes an alternative to users who are unable to board the bus, by changing the boarding time to the next available bus or later bus.

[0084] Subsequently, in S43, the CPU 21 determines whether an alternative option of boarding the shared vehicle 6 was proposed to the user who was unable to board in S41 or S42, and whether the user agreed to either of the alternative options.

[0085] Then, if an alternative plan to ride the passenger vehicle 6 is proposed to the user who is unable to board in S41 or S42, and the user agrees to either alternative plan (S43: YES), the process proceeds to S44. On the other hand, if an alternative plan to ride the passenger vehicle 6 is proposed to the user who is unable to board in S41 or S42, but the user does not agree to any of the alternative plans (S43: NO), the process proceeds to S39 without modifying the operation plan that was provisionally decided in S34.

[0086] Subsequently, in S44, the CPU21 determines whether the user has agreed to an alternative plan specifically for boarding the current flight. The alternative plans offered to users who are unable to board in S41 or S42 include a first alternative plan, which allows the user to board the shared vehicle 6 by changing the boarding location from the user's preferred boarding location at the time of booking to another location, and a second alternative plan, which allows the user to give up on boarding the current flight and board a future flight. In S44, the CPU21 determines whether the user has agreed to the first or second alternative plan.

[0087] Then, if the user who is unable to board in S41 or S42 agrees to the first alternative (S44: YES), which is to allow them to board the shared vehicle 6 by changing their boarding location from the desired boarding location at the time of booking to another location, the process proceeds to S45. On the other hand, if the user who is unable to board in S41 or S42 agrees to the second alternative (S44: NO), which is to allow them to board on a later service, the process proceeds to S47.

[0088] In S45, CPU21 modifies the operation plan provisionally decided in S34 as necessary. Specifically, if a user who is unable to board agrees to an alternative plan, and it becomes necessary to stop at a new stop, the operation route is modified to include the new stop. Furthermore, the operation schedule is also modified in conjunction with the modification of the operation route.

[0089] For example, consider a scenario where a route 63 passing through stops A, B, D, and F has been tentatively determined, as shown in Figure 14. When user b made a reservation, they requested to board at stop E. However, it is determined that they cannot board at stop E at their desired time. As an alternative, they are offered to board at stop C along route 63, and the user agrees to this alternative. In the example shown in Figure 14, since it is now necessary to stop at stop C, which was previously a stop that the bus would pass through, route 63 is changed to a route that stops at stop C (only the number of stops increases; the shape of the route itself does not change). Additionally, the subsequent operating schedule is also changed as a result of stopping at stop C.

[0090] As another example, consider a scenario where a provisional route 63 is set, passing through stops A, B, D, and F, as shown in Figure 15. When user b made a reservation, they requested to board at stop E. However, it is determined that they cannot board at stop E at their desired time. As an alternative, they are offered to board at a newly established virtual stop G along route 63, and the user agrees to this alternative. In the example shown in Figure 15, since the bus needs to stop at the newly established virtual stop G on the previously bypassed route, route 63 is changed to a route that stops at virtual stop G (only the number of stops increases; the shape of the route itself does not change). Furthermore, the subsequent schedule is also changed as a result of stopping at stop G. Details about virtual stops will be described later.

[0091] Next, in S46, the CPU 21 sends a notification to the communication terminal 5 of the user who agreed to the alternative plan but was unable to board, informing them that the boarding reservation has been completed. In addition to the completion of the boarding reservation, the revised operating plan may also be sent. In that case, the communication terminal 5 that received the operating plan displays the operating plan on the display 38 and provides guidance on boarding the bus 6. As a result, the user who agreed to the alternative plan but was unable to board will be able to understand the schedule on which the bus 6 will operate. Furthermore, as will be described later, a discounted fare lower than the regular fare will be applied to the user who agreed to the alternative plan but was unable to board (S56), so it is desirable to display the amount of the discounted fare along with the operating plan. Note that the content displayed on the display 38 of the communication terminal 5 is the same as the provisional operating plan guidance screen 61 (Figure 12) that has already been explained, so the explanation will be omitted.

[0092] Meanwhile, in S47, CPU21 executes the reservation acceptance processing program shown in Figure 4. As mentioned above, this program accepts user reservations for boarding, and CPU21 specifically makes reservations for users who are unable to board, targeting alternative routes such as the next available flight, which have been agreed upon by the user. Boarding reservations are made according to the alternative route agreed upon by the user, and the desired boarding location, boarding time, desired alighting location, and desired alighting time are entered. Although the management server 3 will basically make the alternative boarding reservations automatically, it may also be possible to have the user enter this information.

[0093] Next, the subprocessing of the position adjustment process performed in S41 will be explained with reference to Figure 16. Figure 16 is a flowchart of the subprocessing program for the position adjustment process.

[0094] First, in S51, the CPU 21 determines whether the current location of a user who is unable to board, or the boarding location that the user wished to board, is within a predetermined distance from the route provisionally determined in S34. The predetermined distance may be a fixed value (for example, 300m), or it may be a walking distance registered in advance by the user.

[0095] Then, if it is determined that the current location of a user who cannot board or the boarding location requested by the user who cannot board is within a predetermined distance from the route provisionally determined in S34 (S51: YES), the process proceeds to S52. On the other hand, if it is determined that the current location of a user who cannot board or the boarding location requested by the user who cannot board is not within a predetermined distance from the route provisionally determined in S34 (S51: NO), the process proceeds to S42 without proposing an alternative plan, as it is deemed difficult to propose an alternative plan to change the boarding location.

[0096] In S52, the CPU 21 searches for bus stops that are within a predetermined distance from the current location of the user who is unable to board or from the boarding point that the user wished to board, and that the bus will stop at or pass through in the route plan provisionally determined in S34.

[0097] Next, in S53, the CPU 21 determines whether there are any stops that the bus will stop at or pass through according to the route plan provisionally determined in S34, within a predetermined distance from the current location of the user who is unable to board or from the boarding point that the user wished to board.

[0098] If it is determined that there is a stop within a predetermined distance from the current location of the user who is ineligible to board or from the boarding point the user wishes to board (S53: YES), the process proceeds to S54. Conversely, if it is determined that there is no stop within a predetermined distance from the current location of the user who is ineligible to board or from the boarding point the user wishes to board (S53: NO), the process proceeds to S55.

[0099] In S54, the CPU 21 selects an alternative boarding location from among the stops that the bus will stop or pass through in the route plan provisionally determined in S34, which is closest to the current location of the user who is unable to board or to the boarding location the user wishes to board. Furthermore, it selects the time when the bus 6 will arrive at the stop closest to the boarding location as the alternative boarding time. For example, in the example shown in Figure 14, there is a stop C that will be passed through on the route 63 within a predetermined distance from the current location of user b, who is unable to board, so stop C is selected as the alternative boarding location. In addition, 13:20, the time when the bus 6 will arrive at stop C, is selected as the alternative boarding time.

[0100] On the other hand, in S55, the CPU 21 sets a virtual stop on the route provisionally determined in S34 at the point closest to the current location of the user who is unable to board or the boarding point the user wished to board, and selects the virtual stop as the alternative boarding location. Furthermore, it selects the time when the passenger vehicle 6 arrives at the virtual stop as the alternative boarding time. Note that the virtual stop is a stop that is set temporarily for this service only, separate from the pre-set stops. However, if the virtual stop is set at the point closest to the current location of the user who is unable to board or the boarding point the user wished to board, there is a possibility that the virtual stop will be set at a location where the user cannot board (for example, near an intersection). Therefore, it is desirable to set a candidate range with some width before and after the point closest to the current location of the user who is unable to board or the boarding point the user wished to board, and set the virtual stop at a location within the candidate range where the user can easily board. For example, in the example shown in Figure 15, since there are no bus stops within a predetermined distance from the current location of user b, who is ineligible to board, a virtual bus stop G is set at the point closest to user b's current location on the route 63, and virtual bus stop G is selected as the alternative boarding location. In addition, 13:33, the time when the bus 6 arrives at virtual bus stop G, is selected as the alternative boarding time.

[0101] Subsequently, in S56, CPU21 sets the fare for users who were unable to board but agreed to the alternative. Since users who agreed to the alternative are being forced to board in a way that differs from their original preference, a discounted fare lower than the normal fare is applied. The discount amount may be a fixed amount (for example, 20% off), or it may be set according to the walking distance to the alternative boarding location. Specifically, the discount amount may be set so that the longer the walking distance, the cheaper the fare, for example, 10% off for within 300m, 20% off for within 1km, and 50% off for beyond that. However, setting a discounted fare is not always necessary, and the normal fare may be set even for the alternative.

[0102] In S57, the CPU 21 sends an alternative plan based on the new boarding location and boarding time set in S54 and S55 to the communication terminal 5 of the user who is unable to board. Then, it asks the user who is unable to board whether or not they agree to the alternative plan.

[0103] For example, Figure 17 shows the alternative guidance screen 65 displayed on the display 38 of the communication terminal 5 to which the alternative was transmitted in S57. As shown in Figure 17, the alternative guidance screen 65 displays the new boarding location (stop C in the example shown in Figure 17) set in S54 and S55 on a map image, as well as the distance to the new boarding location, the boarding time to board at the new boarding location, and the discounted fare set in S56. Furthermore, the new boarding time is the time when the bus 6 arrives at the new boarding location. In other words, the alternative plan proposes that the user who is unable to board move to the new boarding location by the time the bus 6 arrives there and board the bus 6 at that location. Figure 17 shows the case where the new boarding location proposed in the alternative plan is a bus stop. However, if the new boarding location proposed in the alternative plan is a virtual bus stop, it is desirable to indicate the location of the virtual bus stop on the map image with a pointer and also guide the user to any nearby landmark buildings. The alternative plan guidance screen 65 displays icons 66 to be operated when the user agrees to the alternative plan and icons 67 to be operated when the user does not agree. When the user operates either icon, the operation result is sent to the management server 3. The CPU 31 then determines whether the user who is unable to board has agreed to the alternative plan based on the operation result of the icon sent from the communication terminal 5. If the user who is unable to board has agreed to the alternative plan, the operation plan is modified as necessary to enable boarding and alighting using the alternative plan, as described above (S45).

[0104] In the above explanation of the position adjustment process (Figure 16), we described the case where the "unable to board" flag is set because the user who is unable to board is unable to alight at their desired boarding location at their desired boarding time. However, it is also possible to propose an alternative plan in the same way when the user who is unable to board is unable to alight at their desired alighting location at their desired alighting time. In that case, in S51, the CPU 21 determines whether or not there is a desired alighting location within a predetermined distance from the route provisionally determined in S34. Also in S54, the CPU 21 selects the stop closest to the desired alighting location of the user who is unable to board from among the stops that the bus will stop or pass through in the route provisionally determined in S34 as the alternative alighting location. On the other hand, in S55, the CPU 21 sets a virtual stop on the route provisionally determined in S34 at the point closest to the desired alighting location of the user who is unable to board, and selects the virtual stop as the alternative alighting location. Furthermore, in S57, the CPU 21 displays the new drop-off location set in S54 and S55 on the map image, and also displays the distance traveled from the new drop-off location to the user's destination, as well as the time of drop-off when the user gets off at the new drop-off location.

[0105] Next, the subprocessing of the time adjustment process executed in S42 will be explained based on Figure 18. Figure 18 is a flowchart of the subprocessing program for the time adjustment process.

[0106] First, in S61, CPU21 determines whether there are any scheduled bus services (bus service 6) that operate after the service for which the user deemed ineligible to board was determined to be ineligible.

[0107] Then, if it is determined that there is a scheduled bus service 6 operating after the bus service for which the user who is ineligible to board was determined to be ineligible (S61:YES), the process proceeds to S62. On the other hand, if it is determined that there is no scheduled bus service 6 operating after the bus service for which the user who is ineligible to board was determined to be ineligible (S61:NO), the process proceeds to S43 without proposing an alternative service, as it is deemed difficult to propose an alternative service for the user to board.

[0108] In S62, CPU21 searches for flights that are available to the user who was deemed ineligible to board, specifically those flights that are available to the user who was deemed ineligible to board, at the boarding and alighting locations specified by the user when making the reservation.

[0109] Next, in S63, CPU21 determines whether there are any scheduled buses 6 that allow passengers to board and alight at the boarding and alighting points specified by the passengers when making their reservation, after the bus for which the passengers were determined to be ineligible to board.

[0110] Then, if it is determined that there is a bus service 6 that allows boarding and alighting at the boarding and alighting points specified by the user when making a reservation, after the bus service in which the user was determined to be ineligible to board (S63:YES), the process proceeds to S64. On the other hand, if it is determined that there is no bus service 6 that allows boarding and alighting at the boarding and alighting points specified by the user when making a reservation, after the bus service in which the user was determined to be ineligible to board (S63:NO), the process proceeds to S43 without proposing an alternative, as it is deemed difficult to propose an alternative bus service.

[0111] In S64, CPU21 selects as an alternative bus service 6 for users who are unable to board a bus, if the service is later than the one for which the user was determined to be unable to board, and the bus service allows the user to board and alight at the designated boarding and alighting points specified when making the reservation. Generally, a service on the same day as the service that was deemed ineligible is selected, but services on different days may also be included. Furthermore, if there are multiple applicable services, all applicable services may be designated as alternative services, or only the earliest service may be designated as an alternative service.

[0112] Subsequently, in S65, CPU21 sets the fare for users who are unable to board but have agreed to the alternative. Since users who are unable to board but have agreed to the alternative will be forced to board in a way that differs from their original preference, a discounted fare lower than the normal fare will be applied. The discount amount may be a fixed amount (for example, 20% off), or it may be set according to the time difference between the flight the user originally wanted to book and the alternative flight. Specifically, the discount amount should be set so that the greater the time difference, the cheaper the fare, for example, 10% off for less than 1 hour, 20% off for less than 2 hours, and 50% off for more than that. However, setting a discounted fare is not always necessary, and the normal fare may be set even for the alternative flight.

[0113] In S66, the CPU 21 sends an alternative plan for boarding the flight set in S64 to the communication terminal 5 of the user who is unable to board. Then, it asks the user who is unable to board whether or not they agree to the alternative plan.

[0114] For example, Figure 19 shows the alternative option guidance screen 65 displayed on the display 38 of the communication terminal 5 to which the alternative option was sent in S66. As shown in Figure 19, the alternative option guidance screen 65 displays the boarding location, boarding time, and discounted fare set in S65 for the bus set in S64. If there are multiple buses set as alternatives in S64, it is desirable to display all buses and allow the user to select the bus they wish to board. The boarding location for the alternative option is basically the same bus stop that the user who was unable to board specified as their desired boarding location in the bus reservation that was determined to be unavailable. The alternative option guidance screen 65 also displays an icon 66 to be operated when the user agrees to the alternative option and an icon 67 to be operated when the user does not agree to the alternative option. When the user operates either icon, the operation result is sent to the management server 3. The CPU 31 then determines whether the user who was unable to board has agreed to the alternative option based on the operation result of the icon sent from the communication terminal 5. Furthermore, if a user who is unable to board agrees to an alternative, the reservation processing program shown in Figure 4 is executed as described above, and a boarding reservation is made for the user for a future flight (S47).

[0115] Next, the operation plan addition and modification processing program executed on the management server 3 will be explained with reference to Figure 20. Figure 20 is a flowchart of the operation plan addition and modification processing program according to this embodiment. Here, the operation plan addition and modification processing program is executed after the deadline for accepting reservations for ride reservations has passed and the operation plan for the passenger bus 6 has been provisionally determined by the aforementioned operation plan provisional determination processing program (Figures 7 and 8). The program proposes alternative options for boarding the passenger bus 6 to users who have made additional ride reservations after the reservation deadline has passed, and if the user who has been offered an alternative option agrees to the alternative, it modifies the provisionally determined operation plan as necessary so that boarding and alighting are possible using the alternative option.

[0116] First, in S71, the CPU 21 determines whether or not a new passenger reservation has been accepted by the reservation processing program (Figure 4) after the reservation deadline, which is the deadline for accepting reservations within the predetermined reservation period. However, this is conditional on the fact that the final deadline (for example, 5 minutes before the scheduled start time of the passenger vehicle 6), which is the final time when the operation plan can be modified, has not yet passed.

[0117] If it is determined that a new reservation has been received from a new user after the reservation deadline (S71:YES), the process proceeds to S72. Conversely, if it is determined that no new reservation has been received from a new user (S71:NO), the program for adding or modifying the operation plan is terminated.

[0118] In S72, the CPU 21 reads the reservation details of the new ride reservation stored in the user DB 13. Specifically, the reservations read in S72 are ride reservations made by users who made reservations after the reservation acceptance period had expired (hereinafter referred to as additional reservation users).

[0119] Next, in S73, CPU21 performs the aforementioned passenger adjustment process (Figure 13). However, it performs the passenger adjustment process (Figure 13) after replacing users who are unable to board with additional reservation users.

[0120] In S74, the CPU 21 transmits the operation plan, including the route and schedule of the passenger transport vehicle 6 modified in the passenger adjustment process in S73 (Figure 13), to the communication terminals 5 of all users who have booked the relevant service (including users who are unable to board but have agreed to an alternative). The communication terminals 5 that receive the operation plan then display the operation plan on the display 38 and provide boarding instructions for the passenger transport vehicle 6. As a result, all users who have booked the relevant service will be able to understand what the schedule will be like after the operation plan is modified due to a new passenger booking. Note that the content displayed on the display 38 of the communication terminal 5 is the same as the provisional operation plan guidance screen 61 (Figure 12) already described, so no further explanation is given. However, if the operation plan is not modified in the passenger adjustment process in S73 (Figure 13), the process in S74 may be omitted.

[0121] Next, the operation plan confirmation processing program executed on the management server 3 will be explained with reference to Figure 21. Figure 21 is a flowchart of the operation plan confirmation processing program according to this embodiment. Here, the operation plan confirmation processing program is executed after the deadline for the reservation acceptance period in which ride reservations can be made has passed and the operation plan of the passenger bus 6 has been provisionally determined by the aforementioned operation plan provisional determination processing program (Figures 7 and 8), and is a program that confirms the operation plan of the passenger bus 6.

[0122] First, in S81, the CPU 21 determines whether the final deadline (for example, 5 minutes before the scheduled start time of the bus 6) has passed, which is the final time at which the bus 6's operation plan can be modified.

[0123] If it is determined that the final deadline has passed (S81:YES), the process proceeds to S82. Conversely, if it is determined that the final deadline has not passed (S81:NO), the operation plan confirmation processing program is terminated.

[0124] In S82, the CPU21 finalizes the operation plan for the passenger bus 6, which was provisionally decided in S34 (or the revised operation plan if it was revised in S45), as the operation plan for the passenger bus 6.

[0125] Subsequently, in S83, the CPU 21 transmits the operation plan, including the route and schedule of the passenger vehicle 6 determined in S82, to the communication terminals 5 of all users who have booked the relevant service (including users who are unable to board due to agreeing to the alternative plan, and additional users who have also agreed to the alternative plan). The communication terminals 5 that receive the operation plan then display the operation plan on their displays 38 and provide boarding instructions for the passenger vehicle 6. As a result, all users who have booked the relevant service will be able to understand the schedule by which the passenger vehicle 6 will operate. Note that the content displayed on the display 38 of the communication terminal 5 is the same as the provisional operation plan guidance screen 61 (Figure 12) already described, so no further explanation is provided.

[0126] As described in detail above, the demand traffic management system 1, management server 3, and computer program executed on the management server 3 according to this embodiment receive ride reservations from each user (S12) up until the reservation deadline, which include the desired boarding and alighting points from a predetermined number of stops to a designated bus, and the desired boarding and alighting times, which specify the desired times for at least one of boarding and alighting from the bus. Based on the content of the ride reservations received from each user, a provisional operation plan for the bus 6 is determined (S22-S34). For users who have made reservations but whose boarding or alighting is not possible according to the provisional operation plan, an alternative plan for boarding the bus is proposed (S57, S66). In this way, in the operation management of demand traffic where buses are operated based on user reservations, it is possible to adequately care for users who are unable to board or alight according to their reservations by proposing an alternative plan for boarding the bus. On the other hand, it also becomes possible to increase the number of passengers as much as possible to operate the train more efficiently. Furthermore, if a user who is unable to board the bus and for whom an alternative plan has been proposed agrees to the alternative plan, the provisionally decided operating plan will be revised according to the alternative plan as necessary (S45), and boarding information will be provided to each user, including the user who is unable to board the bus but has agreed to the alternative plan, based on the revised operating plan (S40, S46). Therefore, even if the operating plan is revised to allow users who are unable to board or alight as per their reservations to board the bus, appropriate operation management of the on-demand transport will be possible based on the revised operating plan. Furthermore, for users who are unable to board the bus according to their reservations based on the provisionally determined operating schedule, an alternative is proposed (S57) in which the user moves to the stop closest to their current location or desired boarding point among the stops where the bus 6 stops or passes in the provisionally determined operating schedule, and boards the bus 6 at that stop. Similarly, for users who are unable to alight according to their reservations based on the provisionally determined operating schedule, an alternative is proposed in which the user alights at the stop closest to their desired alighting point among the stops where the bus stops or passes in the provisionally determined operating schedule, and then moves to that alighting point (S57). Thus, even users who are unable to board or alight according to their reservations can be allowed to board the bus 6 by encouraging them to change their boarding or alighting location. This also makes it possible to increase the number of passengers as much as possible and operate the service efficiently. Furthermore, for users who are unable to board according to their reservations based on the provisionally determined operating schedule, an alternative is proposed (S57) in which the user moves to the point closest to their current location or desired boarding location on the route the bus travels according to the provisionally determined operating schedule, and boards the bus at that point. Similarly, for users who are unable to alight according to their reservations based on the provisionally determined operating schedule, an alternative is proposed in which the user alights at the point closest to their desired alighting location on the route the bus travels according to the provisionally determined operating schedule, and then moves to that alighting location (S57). Thus, even users who are unable to board or alight according to their reservations can be allowed to board the bus 6 by setting up virtual stops and encouraging them to change their boarding or alighting locations. This also makes it possible to increase the number of passengers as much as possible and operate the service efficiently.

[0127] It should be noted that the present invention is not limited to the embodiments described above, and various improvements and modifications are possible without departing from the spirit of the invention. For example, in this embodiment, when a user makes a reservation, they input both the desired boarding time for boarding the bus 6 and the desired disembarking time for disembarking from the bus 6. However, they may input only one of these. Even if a desired boarding time is not entered, when the operation plan is tentatively or finalized, the communication terminal 5 held by the user will be notified of the boarding time for boarding the bus 6 specified according to the operation plan. Similarly, even if a desired disembarking time is not entered, when the operation plan is tentatively or finalized, the communication terminal 5 held by the user will be notified of the disembarking time for disembarking from the bus 6 specified according to the operation plan.

[0128] Furthermore, when making a reservation, the user may enter the time they plan to leave their home instead of the desired departure time. Similarly, instead of the desired alighting time, the user may enter the time they wish to arrive at their destination. In this case, the management server 3 can determine the desired departure time by deriving the route from the user's home to the bus stop from the time they plan to leave their home and the map information. The management server 3 can also determine the desired alighting time by deriving the route from the bus stop to the destination from the time the user wishes to arrive at their destination and the map information.

[0129] Furthermore, although this embodiment describes an example where the communication terminal 5 is applied to a smartphone, it can also be applied to other types of communication terminals as long as they can communicate with the management server 3 and have the function of making online reservations. For example, it can be applied to mobile phones, tablet terminals, personal computers, etc. [Explanation of symbols]

[0130] 1...Demand-responsive traffic management system, 2...Management center, 3...Management server, 4...User, 5...Communication terminal, 6...Passenger vehicle, 11...Server control unit (example of reservation acceptance means, provisional operation plan determination means, alternative suggestion means, operation plan modification means, passenger guidance means), 13...User DB, 14...Vehicle DB, 15...Map stop DB, 17...Stop data, 21...CPU, 22...RAM, 23...ROM, 38...Display

Claims

1. A demand-responsive transportation management system that manages the operation of shared vehicles used by multiple users who have made reservations in advance, A reservation system that accepts reservations from each user up until the reservation deadline, including the desired boarding and alighting locations from a predetermined list of candidate locations for a designated shared vehicle, and the desired boarding and alighting times, specifying the times for at least one of the boarding and alighting points. The aforementioned reservation acceptance means provisionally determines the operation plan for the passenger transport vehicle based on the contents of the passenger transport reservations received from each user, A demand-responsive transportation management system comprising: an alternative suggestion means for proposing alternative options for boarding a shared vehicle to users who, among those who have made reservations through the aforementioned reservation acceptance means, are unable to board or alight according to the provisionally determined operating plan; and such users.

2. If the user who is unable to board the train, for whom the alternative plan has been proposed by the alternative proposal means, agrees to the alternative plan, the operation plan modification means modifies the provisionally determined operation plan according to the alternative plan as necessary, The demand traffic management system according to claim 1, further comprising: a passenger guidance means that provides passenger boarding guidance to each user, including the passenger who is unable to board but has agreed to the alternative plan, based on the operational plan modified by the operational plan modification means.

3. The aforementioned alternative proposed means is, For users who are unable to board the bus according to their reservation in the provisionally determined operating plan, the alternative plan proposed is that the user travel to the candidate location closest to their current location or desired boarding location among the candidate locations where the bus stops or passes in the provisionally determined operating plan, and board the bus at that location by the time the bus reaches that location. The demand-responsive traffic management system according to claim 1 or 2, wherein for users who are unable to board the vehicle in the provisionally determined operating plan and are therefore unable to disembark at the time of their reservation, the system proposes as an alternative that the user disembark at the candidate location closest to their desired disembarking point among the candidate locations where the vehicle stops or passes in the provisionally determined operating plan, and then travel to that desired disembarking point.

4. The aforementioned alternative proposed means is, For users who are unable to board according to their reservations in the aforementioned provisional operating plan, the alternative proposed is that they travel along the route the bus will travel according to the provisional operating plan to the point closest to their current location or desired boarding point by the time the bus reaches that point, and then board the bus at that point. The demand-responsive transportation management system according to claim 1 or 2, wherein for users who are unable to board the vehicle in the provisionally determined operating plan and are therefore unable to disembark at the time of their reservation, the system proposes as an alternative that the user disembark at the point closest to their desired disembarking point on the route the vehicle travels in the provisionally determined operating plan, and that the user then travel to that disembarking point.

Images