Demand-responsive traffic management system

Abstract

This system provides a demand-responsive transportation management system that makes it easier to obtain user consent for the consolidation of boarding and alighting points, and enables efficient operation using the consolidated boarding and alighting points. [Solution] Up until the reservation deadline, the system accepts ride reservations from each user, which include the departure point, destination, at least one of the scheduled departure time from the departure point and the scheduled arrival time at the destination, and a walking range that specifies the area where walking is permitted. Based on the content of the ride reservations received from each user, the system aggregates the ride reservations into one or more reservation groups, provided that they do not exceed the walking range. For each reservation group, a common boarding and alighting point is selected from among multiple bus stops for each user who made a ride reservation included in that group, and the system determines the operation plan for the bus based on the aggregated content.

Description

Technical Field

[0001] The present invention relates to a demand-responsive traffic management system for performing operation management 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, instead of operating on a predetermined route or schedule, demand-responsive transport (DRT) is operated based on reservations from users. In such demand-responsive traffic, a plurality of users who have made reservations in advance share the same vehicle to 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 plurality of users.

[0003] Also, when determining an operation plan in the above demand-responsive traffic, it is more efficient to operate by aggregating the boarding and alighting points of users as much as possible. Therefore, for example, in Japanese Patent Application Laid-Open No. 2019-16290, for a plurality of users who wish to use demand-responsive traffic, users whose desired boarding and alighting points are close are aggregated, and boarding and alighting points shared by the plurality of users are set to aggregate the boarding and alighting points and improve the operation efficiency.

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] While Patent Document 1 discloses the consolidation of boarding and alighting points for multiple users, this requires users to tolerate a certain amount of walking between their departure point and the boarding point, or between their alighting point and their destination. However, some users do not mind long-distance walking, while others have poor health and find long-distance walking difficult. Patent Document 1 consolidates users' boarding and alighting points without considering the tolerance of such users for walking, making it difficult to obtain user consent for the consolidation of boarding and alighting points.

[0006] The present invention was made to solve the aforementioned problems of the conventional approach, and aims to provide a demand-responsive transportation management system that, in the operation management of such on-demand transportation, makes it easier to obtain user consent for the consolidation of boarding and alighting points by considering the user's tolerance for walking, and enables efficient operation using the consolidated boarding and alighting points. [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, wherein multiple bus stops are pre-installed in the area in which the shared vehicle operates, and the system includes: a reservation receiving means that receives reservations from each user until the reservation deadline, including a departure point, a destination, at least one of the scheduled departure time from the departure point and the scheduled arrival time at the destination, and a walking-permitted range that specifies the area in which walking is permitted; a boarding and alighting point determination means that, based on the content of the reservations received from each user by the reservation receiving means, aggregates the reservations into multiple reservation groups on the condition that they do not exceed the walking-permitted range, and for each reservation group, selects a common boarding and alighting point from among the multiple bus stops for each user who has made a reservation included in that group to board and alight the shared vehicle; and an operation plan determination means that determines the operation plan of the shared vehicle based on the content determined by the boarding and alighting point determination means. 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 route be taken). [Effects of the Invention]

[0008] According to the demand-responsive transportation management system of the present invention having the above configuration, in the operation management of demand-responsive transportation where shared vehicles are operated based on reservations from users, it becomes possible to consolidate user pick-up and drop-off points while taking into account the user's tolerance for walking. As a result, it becomes easier to obtain user consent for the consolidation of pick-up and drop-off points, and efficient operation using the consolidated pick-up and drop-off points becomes possible. [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 departure location input screen displayed on the screen. [Figure 6] This figure shows an example of the destination input screen displayed on the screen. [Figure 7] This figure shows an example of the display of the tolerance range input screen shown on the display. [Figure 8] This is a flowchart of the operation plan determination processing program according to this embodiment. [Figure 9] This is a flowchart of the sub-processing program for clustering. [Figure 10] This diagram explains how the boarding locations of users who have made a boarding reservation are aggregated. [Figure 11]This diagram illustrates how the drop-off locations of users who have made a reservation for a ride are aggregated. [Figure 12] This diagram shows a proposed clustering plan for consolidating boarding and alighting points. [Figure 13] This is a flowchart of the sub-processing program for the optimal path search process. [Figure 14] This diagram illustrates the method for searching for route paths for proposed clusters. [Figure 15] This diagram shows an example of the display of the train schedule information screen shown on the display. [Figure 16] This diagram compares the route planned using conventional technology with the route planned using this embodiment. [Modes for carrying out the invention]

[0010] Hereinafter, one embodiment of the demand-responsive traffic management system according to the present invention will be described in detail with reference to the drawings. First, the schematic configuration of the demand-responsive traffic management system 1 according to this embodiment will be described using Figures 1 and 2. Figure 1 is a schematic configuration diagram showing the demand-responsive traffic management system 1 according to this embodiment. Figure 2 is a block diagram showing the configuration of the demand-responsive traffic management system 1 according to this embodiment.

[0011] As shown in Figure 1, the on-demand transportation management system 1 according to this embodiment basically comprises a management server 3 located in a management center 2 that manages and operates on-demand transportation, a communication terminal 5 owned by a user 4 who is a user of on-demand transportation, and a vehicle (hereinafter referred to as a passenger vehicle 6) that operates on the on-demand transportation. Furthermore, the management server 3, the communication terminal 5, and the passenger vehicle 6 are configured to send and receive electronic data to and from each other via a communication network 7. Examples of communication terminals 5 include mobile phones, smartphones, tablet terminals, personal computers, etc.

[0012] Here, the management server 3 is a device that receives ride reservations from the communication terminal 5 and determines the operation plan of the shared vehicle 6 according to the content of the received ride reservation. Note that, unlike a taxi, the shared vehicle 6 is basically assumed to be used by multiple users sharing rides. Therefore, the management server 3 receives ride reservations from multiple users within a predetermined reservation acceptance period, and determines an operation plan to meet the demands of as many users as possible among the multiple users who have received ride reservations. Also, in this embodiment, the management server 3 also performs the aggregation of pick-up and drop-off locations among multiple users as described later when determining the operation plan, so as to formulate a more efficient operation plan. On the other hand, the operation plan finally determined by the management server 3 is transmitted to the shared vehicle 6, and the shared vehicle 6 operates according to the transmitted operation plan.

[0013] Here, as demand-responsive transportation, generally, 'Semi-demand' and 'Full-demand' are known. 'Semi-demand' is an operation mode somewhat similar to conventional public transportation, where the locations (bus stops) where the shared vehicle 6 can pick up and drop off passengers and the times when it can do so are determined to a certain extent. Also, the reservation acceptance period during which ride reservations are possible is predetermined, and an operation plan is determined to meet the demands of as many users as possible after referring to all the ride reservations received by users during the reservation acceptance period. On the other hand, 'Full-demand' basically allows users to board and alight at any location they desire, and they can freely select the boarding time and the alighting time. Also, there is basically no reservation acceptance period, and the operation plan is determined at any time, giving priority to users who have made reservations earlier.

[0014] Then, in the following description, an example will be given where the demand-responsive transportation operationally managed by the demand-responsive transportation management system is in the 'Semi-demand' operation mode. However, the invention of the present application is not limited to 'Semi-demand' and may also be 'Full-demand'.

[0015] In addition to the user directly making a ride reservation to the management server 3 via the communication terminal 5, the user can also request the operator 8 by phone, email, etc., and the operator 8 can perform the reservation operation by operating the information terminal 9 (such as a PC or a tablet terminal). Here, the operator 8 can be a natural person, who may be an employee of the management center 2 or a person who has concluded a contract with the management center 2. After grasping the reservation details from the user by phone, email, etc., the operator 8 performs the reservation operation on behalf of the user.

[0016] In addition, the shared vehicle 6 managed and operated by the demand traffic management system 1 is equipped with an in-vehicle device 10 such as a navigation device, for example, and the management server 3 is communicably connected to the in-vehicle device 10 such as a navigation device installed in the shared vehicle 6. When the management server 3 finally determines the operation plan of the shared vehicle 6, it distributes information regarding the operation plan to the shared vehicle 6 via the communicably connected in-vehicle device 10. The operation plan includes an operation route (which route to travel) and an operation schedule (at what time to travel). Furthermore, the in-vehicle device 10 is equipped with a display and a speaker, and guides the passengers about the operation plan via the display and the speaker. Also, when the in-vehicle device 10 is a navigation device, it is also possible to set the operation route as the guidance route of the navigation device according to the operation plan transmitted from the management server 3.

[0017] In addition to the manual driving operation where the shared vehicle 6 travels based on the driver's driving operation, the shared vehicle 6 can also be a vehicle capable of assisted driving by autonomous driving support where the vehicle automatically travels without depending on the driver's driving operation. And if it is a vehicle capable of assisted driving by autonomous driving support, for example, it can be an autonomous driving vehicle that automatically travels according to the operation plan transmitted from the management server 3. Also, the number of shared vehicles 6 managed and operated by the demand traffic management system 1 is not limited to one and may be a plurality.

[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, a sponsor information DB 16, and a server-side communication device 17.

[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) and the operation plan determination processing program (Figure 8) described later, and internal storage devices such as flash memory 24 that store 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 ride reservations from each user until the reservation deadline, including the departure point, destination, at least one of the scheduled departure time from the departure point and the scheduled arrival time at the destination, and a walking allowance range that specifies the area where walking is permitted. The boarding / alighting point determination means aggregates the boarding / alighting reservations received from each user by the reservation acceptance means into multiple reservation groups, provided that the group does not exceed the pedestrian-permissible area. For each reservation group, it selects a common boarding / alighting point from among multiple stops for each user who made a boarding / alighting reservation included in that group. The operation plan determination means determines the operation plan for the bus based on the information determined by the boarding / alighting point determination means. In other words, the control units provided in the server control unit 11 and the communication terminal 5 are examples of the reservation acceptance means, boarding / alighting point determination means, and operation plan determination 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 DB15 also stores stop data18 that identifies the location and name of stops where the passenger bus 6 stops in the area where the passenger bus operates, i.e., where the 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 the bus may stop only if the management server 3 selects them as boarding or alighting points based on the user's reservation. In other words, a stop can be said to be a place where the passenger bus 6 can stop and allow users to board or alight. In addition, stops may be set around stores operated by sponsors or facilities associated with sponsors, as described later, and such stops are stored in a way that allows them to be identified from other stops.

[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] Furthermore, the Sponsor Information DB16 is a database that stores information about sponsors (hereinafter referred to as "sponsors") of the on-demand transportation managed and operated by the Demand Transportation Management System 1. Specifically, for each sponsor, in addition to information that identifies the sponsor (company name, contact information), information such as the amount of sponsorship money invested by the sponsor, the stores operated by the sponsor, and facilities related to the sponsor are stored.

[0028] On the other hand, the server-side communication device 17 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.

[0029] 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.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] Furthermore, the display 38 is located on one side of the casing and uses a liquid crystal display or an organic EL display, etc. The display shows 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, the reservation screen for making online reservations for the passenger bus 6 and the notification screen for the operating schedule of the reserved passenger bus 6 are also displayed.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

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

[0040] The departure point input screen 51 displays a map image 52 of the area around the user's current location, as shown in Figure 5, along with a current location icon 53 indicating the user's current location. If there are bus stops within the map image 52, a bus stop icon 54 indicating the location of the bus stop is also displayed. Here, if the on-demand transport is "semi-demand," the locations and times where passengers can board and alight from the bus 6 are predetermined to some extent. More specifically, the locations where passengers can board and alight from the bus 6 are the bus stops stored in the bus stop data 18 (Figure 2) of the aforementioned map bus stop DB 15, and are predetermined by the management company to be locations with high demand for boarding and alighting (for example, hospitals, train stations, city halls, shopping malls, stores operated by sponsors, etc.). Therefore, the bus stop icon 54 indicates the location of a bus stop near the user's departure point where it is possible to board the bus 6.

[0041] Furthermore, as a consideration for sponsors, bus stops may be set up near stores operated by sponsors or facilities associated with sponsors. Such bus stops set up near stores operated by sponsors or facilities associated with sponsors, i.e., bus stops associated with sponsors, will be referred to as sponsored bus stops below. When sponsored bus stops are included in map image 52, it is desirable to display the name of the sponsor-operated store or facility associated with sponsor located near the sponsored bus stop, along with the bus stop icon 54. In addition, it may be possible to display the benefits (such as fare discounts) that can be received when using a sponsored bus stop as a boarding point for the bus 6. This will encourage the use of sponsored bus stops. Furthermore, for bus stops other than sponsored bus stops, it is possible for users to select a bus stop icon 54 to display information such as the name of the selected bus stop and the times when boarding is possible at that bus stop.

[0042] Then, on the departure point input screen 51, the user can set their current location (the location where the current location icon 53 is displayed) as the departure point. Alternatively, the user can select any location on the map image 52 and set the selected location as the departure point. For example, a departure point selection icon 55 can be displayed at any location selected by the user on the map image 52, and the user can be asked whether to set the location where the departure point selection icon 55 is displayed as the departure point. In addition to selecting using the map image 52 as shown in Figure 5, the departure point can also be set by specifying latitude and longitude, or by entering a facility name, location name, address, etc. Furthermore, it is also possible to select a bus stop as the departure point. If the user selects a bus stop as the departure point, the management server 3 can estimate that the user has difficulty walking long distances or has a strong desire to board at that bus stop, and can control the system to prevent the boarding point of the shared vehicle 6 from being any bus stop other than the designated departure point.

[0043] Then, once the user has finished entering their desired departure location (reservation details) on the departure location input screen 51, the destination input screen 61 shown in Figure 6 is displayed on the display 38. The destination input screen 61 is an input screen for the user to enter their desired destination (reservation details), and more specifically, it is an input screen for entering the destination and the planned (desired) arrival time at the destination. Then, in S2, the CPU 31 also inputs the reservation details regarding the destination based on the user's operation on the input operation unit 39.

[0044] On the destination input screen 61, for example, the user can select any point on the map image 52 to set the selected point as the destination. For example, a destination selection icon 56 can be displayed at any point selected by the user on the map image 52, and the user can be asked whether to set the point where the destination selection icon 56 is displayed as the destination. In addition to selecting using the map image 52 as shown in Figure 6, destinations can also be set by specifying latitude and longitude, or by entering facility names, place names, addresses, etc. Furthermore, it is also possible to select a bus stop as the destination. If the user selects a bus stop as the destination, the management server 3 can estimate that the user has difficulty walking long distances or has a strong desire to get off at that bus stop, and can control the system to ensure that the disembarking point from the bus 6 is not a bus stop other than the designated destination bus stop.

[0045] Furthermore, on the destination input screen 61, similar to the departure point input screen 51, if there are bus stops within the map image 52, a bus stop icon 54 indicating the location of the bus stop will also be displayed. If the map image 52 includes sponsored bus stops, it is desirable to display the name of the store or facility where the bus stop is located, along with the bus stop icon 54, at the location of the sponsored bus stop. In addition, it may be possible to display the benefits (such as fare discounts) that can be received when using a sponsored bus stop as a disembarking point from the bus 6. This will encourage the use of sponsored bus stops. Furthermore, for bus stops other than sponsored bus stops, it is possible to display information such as the name of the selected bus stop by having the user select a bus stop icon 54.

[0046] Furthermore, on the destination input screen 61, the user also enters the estimated arrival time, which is the time they plan (hope) to arrive at the destination. However, the estimated arrival time may be automatically calculated and entered by the management server 3 when the user selects a destination, based on the departure location and estimated departure time set by the user on the departure location input screen 51.

[0047] Furthermore, it is not always necessary to require users to input both the scheduled departure time and the scheduled arrival time. For example, a user who has only decided on the departure time can specify only the scheduled departure time, and similarly, a user who has only decided on the arrival time at their destination can specify only the scheduled arrival time. Alternatively, the destination input screen 61 can be displayed before the departure input screen 51, allowing the user to input the destination and scheduled arrival time before entering the departure location and scheduled departure time.

[0048] Then, once the user has finished entering their desired destination (reservation details) on the destination input screen 61, the display 38 will then show the acceptable range input screen 65 shown in Figure 7. The acceptable range input screen 65 is an input screen for the user to enter the acceptable range for the various information that has been set on the departure point input screen 51 and the destination input screen 61. More specifically, it is an input screen for entering the acceptable range for the scheduled departure time, the acceptable range for the scheduled arrival time, and the range for which walking (traveling on foot) is acceptable.

[0049] As shown in Figure 7, the tolerance range input screen 65 first displays the scheduled departure time set by the user on the departure location input screen 51. Below the scheduled departure time, an input field 67 is displayed for the user to enter the range within which changes to the set scheduled departure time are acceptable. The user enters the acceptable range (for example, within 10 minutes before or after) for the set scheduled departure time. This allows for a wider range of departure times to be set. The acceptable range for the scheduled departure time may be freely entered by the user, or it may be possible to select from multiple options.

[0050] Furthermore, the acceptable range input screen 65 also displays the estimated arrival time set by the user on the destination input screen 61. Below the estimated arrival time, an input field 68 is displayed for the user to enter the acceptable range of changes to the set estimated arrival time. The user enters the acceptable range of changes to the set estimated arrival time (for example, within 10 minutes before or after). This makes it possible to set a wider range for the estimated arrival time. Note that the acceptable range for the estimated arrival time may be freely entered by the user, or it may be possible to select from multiple options.

[0051] Furthermore, the tolerance range input screen 65 also displays an input field 69 for the user to input the range within which they are willing to walk (hereinafter referred to as the walking tolerance range). This walking tolerance range is the maximum distance the user is willing to travel from their starting point to the boarding point of the shared vehicle 6. It is also the maximum distance the user is willing to travel from the disembarking point of the shared vehicle 6 to their destination. Alternatively, it may be the total distance that is the sum of these two ranges. It is also desirable to display the recommended walking distance (or number of steps) per day, per week, etc., near the walking tolerance range input field 69. This will encourage the user to walk more actively.

[0052] Furthermore, in the example shown in Figure 7, the walking tolerance range is specified by the distance walked, but it may also be specified by the walking time or the number of steps. In addition, the walking tolerance range does not have to be entered by the user making the ride reservation, but may be determined by the system based on the attributes of the user making the ride reservation. These attributes may include, for example, gender, age, occupation, and health status (e.g., pregnant). Specifically, since user information is stored in the user DB13 of the management server 3, the management server 3 may be configured to automatically determine the walking tolerance range by considering the gender, age, occupation, and health status of the user who has made the ride reservation. In addition, the system may adjust the entered walking tolerance range based on external factors such as the weather on that day or the status of events being held.

[0053] Furthermore, the fare is also displayed on the tolerance range input screen 65. Note that the fare is determined by the combination of bus stops near the departure point that the user can select as their boarding point and bus stops near the destination that the user can select as their alighting point, so it is basically not an item that the user selects. Depending on the management company, the fare may be a fixed amount regardless of the combination of bus stops. In addition, users who set a large tolerance range for the scheduled departure time or arrival time (for example, 20 minutes or more) or a long walking tolerance range (for example, 300m or more) may be offered a discounted fare as a reward for cooperating in consolidating boarding and alighting points.

[0054] Please note that the input method for reservation details disclosed in Figures 5 to 7 is just one example, and other input methods can be adopted. For example, it may be possible to input conditions other than the departure point, scheduled departure time, destination, scheduled arrival time, and walking distance. Alternatively, it may be possible to require input of only either the scheduled departure time or the scheduled arrival time.

[0055] 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 destination, scheduled departure time (including acceptable range), destination, scheduled arrival time (including acceptable range), and walking range mentioned above, 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 (Figure 8).

[0056] 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 destination, the scheduled departure time (including the acceptable range), the destination, the scheduled arrival time (including the acceptable range), and the walking distance.

[0057] 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. If the on-demand transport is "semi-demand," there is a set reservation period during which ride reservations can be made. Reservations made after the reservation period will generally not be accepted, and a message will be displayed stating that the reservation could not be accepted and encouraging the user to make a reservation at a later date. However, if the passenger can be allowed to ride without significantly altering the already decided operating schedule, the CPU 21 may accept ride reservations even if they are made after the reservation period.

[0058] 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.

[0059] If reservations are received from multiple users, the reservation details are stored in the user DB13, separated by user. Furthermore, the received reservations are divided into multiple time slots based on the scheduled departure or arrival time. The time slots for classification correspond to the operating hours of each service of the shared vehicle 6, and are determined considering factors such as the size of the area where on-demand transportation is provided, the available operating hours, and the number of available services. For example, if a maximum of one shared vehicle 6 service is planned per hour, the service is classified into one-hour increments from 8:00 AM to 6:00 PM (services during time slots without reservations are cancelled). Then, the CPU 21 determines the operating plan for the shared vehicle 6 based on the reservation details for each user stored in the user DB13, as described later (Figure 8).

[0060] Next, the operation plan determination processing program executed on the management server 3 will be explained with reference to Figure 8. Figure 8 is a flowchart of the operation plan determination processing program according to this embodiment. Here, the operation plan determination processing program is a program that 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 8, 9 and 13 below are stored in the RAM 22, ROM 23, etc., of the management server 3 and are executed by the CPU 21.

[0061] 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.

[0062] 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 operation plan determination processing program is terminated.

[0063] In S22, CPU21 performs the clustering process described below (Figure 9). The clustering process aggregates the ride reservations received from each user in the reservation acceptance processing program (Figure 4) into multiple reservation groups, provided that the group does not exceed the pedestrian-permissible area. For each reservation group, it selects a common boarding and alighting point from among multiple bus stops for each user who made a reservation included in that group to board and alight the shared vehicle. If there are multiple methods for aggregating the reservation groups, a common boarding and alighting point is selected for each of the multiple methods, and the combinations are formulated as cluster proposals. CPU21 formulates proposals for all possible cluster proposals.

[0064] The explanation of the operation plan determination processing program will be temporarily interrupted below, and the sub-processes of the clustering process executed in S22 will be explained based on Figure 9. Figure 9 is a flowchart of the sub-processing program for the clustering process.

[0065] First, in S41, 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.

[0066] Next, in S42, the CPU 21 identifies, for each user who has made a reservation, the area that is within the walking distance set by the user from the departure point set by the user (hereinafter referred to as the "walkable area"). The walkable area 70 indicates the area that can be reached by walking from the user's departure point within the walking distance set by the user. Similarly, the CPU 21 also identifies the walkable area 70 that is within the walking distance set by the user from the user's destination.

[0067] Next, in S43, the CPU 21 refers to the pedestrian area 70 set in S42 for each user who has made a reservation to board a ride, and selects from the bus stops a boarding point (a boarding point for boarding the bus 6 and a disembarking point for disembarking from the bus 6) that can be used by multiple users.

[0068] The following explanation of the processes in S42 and S43 will use the example shown in Figure 10, where bus stops "A" to "Ke" are set up and users A to E have made reservations. In S42, as shown in Figure 10, a circle with the walking range set by user A as the radius, centered on user A's departure point, is identified as the walkable area 70. Similarly, circles with the walking range set by users B to E as the radius, centered on users B to E's departure points, are identified as the walkable area 70. In the example shown in Figure 10, the walkable area 70 is identified using a circle centered on the user's departure point, but for example, the walkable area 70 could also be identified by plotting points along the surrounding roads radially from the user's departure point, at a distance equal to the walking range, and connecting the plotted points.

[0069] As a result, the pedestrian area 70 overlaps for users C and D, and bus stops "Ku" and "Ko" are located within the overlapping area. Therefore, in S43, bus stops "Ku" and "Ko" are selected as common boarding points for the combination of users C and D. However, a condition for selecting bus stop "Ku" as a common boarding point may be that the time periods during which users C and D can reach bus stop "Ku" when they depart at their respective scheduled departure times overlap. Similarly, a condition for selecting bus stop "Ko" as a common boarding point may be that the time periods during which users C and D can reach bus stop "Ko" when they depart at their respective scheduled departure times overlap. In that case, the wider the acceptable range for scheduled departure times, the easier it becomes to select common boarding points.

[0070] Similarly, for users C and E, the pedestrian areas 70 overlap, and bus stop "Ka" is located within the overlapping area. Therefore, in S43, bus stop "Ka" is selected as a common boarding point for the combination of users C and E. However, a condition for selecting bus stop "Ka" as a common boarding point may be that the time periods during which users C and E can reach bus stop "Ka" when they depart at their respective scheduled departure times overlap. On the other hand, for users A and D, the pedestrian areas 70 overlap, but there is no bus stop located within the overlapping area. Therefore, in S43, no common boarding point is selected for the combination of users A and D.

[0071] Subsequently, the same process is performed for the user's destination. If the pedestrian areas 70 overlap for multiple users and a bus stop exists within the overlapping area, that bus stop is selected as a common disembarking point for that combination of users. For example, in the example shown in Figure 11, the pedestrian areas 70 overlap for users A, C, D, and E, and bus stop "O" exists within the overlapping area. Therefore, in S43, bus stop "O" is selected as a common disembarking point for the combination of users A, C, D, and E. However, a condition for selecting bus stop "O" as a common disembarking point may also be that the time periods during which users A, C, D, and E need to depart from bus stop "O" in order to arrive at their respective destinations at their scheduled arrival times overlap. In that case, the wider the acceptable range of scheduled arrival times, the easier it becomes to select a common disembarking point.

[0072] Next, in S44, the CPU 21 derives all possible patterns for combinations of boarding and alighting points for each user (hereinafter referred to as cluster proposals) in order to make boarding and alighting points common among multiple users (to aggregate the boarding and alighting points of users), based on the boarding and alighting points that can be shared among multiple users as discovered in S43.

[0073] For example, Figure 12 shows a list of cluster options derived when bus stops 'A' to 'Ke' are set up as shown in Figures 10 and 11, and users A to E have made reservations for the ride. For example, in the example shown in Figure 12, a total of 15 cluster options are derived. For example, in Pattern 1, user A boards at bus stop 'A' and alights at bus stop 'O'. For user B boards at bus stop 'B' and alights at bus stop 'E'. For user C boards at bus stop 'Ko' and alights at bus stop 'O'. For user D boards at bus stop 'Ko' and alights at bus stop 'O'. For user E boards at bus stop 'Ka' and alights at bus stop 'O'. Therefore, in Pattern 1, the boarding locations for users C and D are consolidated at bus stop 'Ko', and the alighting locations for users A, C to E are consolidated at bus stop 'O'. Similarly, boarding and alighting locations are consolidated in the other patterns as well.

[0074] In the cluster proposals for patterns 1 to 15 shown in Figure 12, each user's ride reservation is consolidated into one or more reservation groups, and for each reservation group, a common boarding and alighting point is selected from the available bus stops for each user who made a reservation within that group. For example, in pattern 1, the ride reservations of users C and D are consolidated into one reservation group, and bus stop 'Ko' is selected as the common boarding point. The remaining reservations of users A, B, and E are in separate reservation groups, and each is assigned a different bus stop as its boarding point. In other words, boarding points are consolidated into four reservation groups. Similarly, regarding alighting points, the ride reservations of users A, C to E are consolidated into one reservation group, and bus stop 'O' is selected as the common alighting point. The remaining user B's ride reservation is in a separate reservation group, and a different bus stop is assigned as its alighting point. In other words, alighting points are consolidated into two reservation groups. Then, as will be described later, when searching for a route for the cluster plan (S52), the search will focus on routes connecting common boarding and alighting points set for each reservation group.

[0075] Then, the CPU 21 writes all the cluster proposals calculated in S44 to the flash memory 24. Then, processing from S23 onwards is performed for each cluster proposal.

[0076] Returning to Figure 8, the process from S23 onwards in the operation plan determination processing program is explained as follows: Processing from S23 to S28 is performed for all cluster proposals derived in the aforementioned clustering process (Figure 9). For example, if cluster proposals patterns 1 to 15 shown in Figure 12 are derived, processing from S23 to S28 is performed for each of the cluster proposals from patterns 1 to 15, and then the program proceeds to S29.

[0077] First, in S23, CPU21 performs the optimal route search process (Figure 13) described later. The optimal route search process searches for the optimal route for the passenger vehicle 6 to pick up and drop off each user who has made a reservation, according to the cluster plan being processed.

[0078] The explanation of the operation plan determination processing program will be temporarily interrupted below, and the sub-process of the optimal route search process executed in S23 will be explained based on Figure 13. Figure 13 is a flowchart of the sub-process program of the optimal route search process.

[0079] First, in S51, CPU21 sets the starting point for the passenger vehicle 6. For example, the hangar or parking lot for passenger vehicle 6 may be the starting point. It is assumed that the starting point is predetermined by the management company, but it may be changed for each trip.

[0080] Next, in S52, the CPU 21 searches for the optimal route for the passenger vehicle 6 to pick up and drop off each user who has made a reservation according to the cluster proposal being processed.

[0081] The process described in S52 above will be explained in more detail below. CPU 21 first searches for a route from the starting point of the passenger bus 6 to the first stop (hereinafter referred to as the starting stop), and selects the searched route as part of the route. The starting stop is basically fixed, but a different stop may be designated as the starting stop for each trip. For example, stop 'A' may be designated as the starting stop. Subsequently, the route to travel via the bus stops is determined by considering the scheduled departure time (including acceptable range) and scheduled arrival time (including acceptable range) included in the user's ride reservation, and is then determined using a solution to a transportation route problem also known as the Pickup and Delivery Problem (PDP). Details of the algorithm are omitted. However, bus stops not designated as destinations for the user's boarding and alighting are generally excluded from the route. Since the combinations of bus stops to which the user will board and alight have been pre-extracted using the cluster plan shown in Figure 12, step S52 searches for the optimal route to travel between the extracted destination bus stops by comparing costs. The CPU 21 then selects the route with the lowest cost from each candidate if there are multiple possible routes from the starting stop via the stops where the user will board or alight, as the optimal route for the passenger vehicle 6. Route searching using stops as intermediate points is based on conventional methods such as Dijkstra's algorithm or the A-STAR algorithm. The cost used for route searching can be calculated by multiplying distance and traffic congestion information, as used in conventional navigation systems, or it may also take fuel consumption into consideration. Furthermore, the cost may be calculated by considering clustering coefficients and sponsor coefficients, as shown in equation (1) below. The criteria for calculating the cost are selected according to the operational policy of the transportation management company. For example, Figure 14 illustrates an example of searching for the optimal route using cluster pattern 1 from the cluster options shown in Figure 12. In the example shown in Figure 14, the next candidate destination stop from the starting stop 'A' is one of 'B', 'F', or 'J', which are designated as the user's boarding point. Then, the travel cost to stop 'I' is 5, the travel cost to stop 'Ka' is 9.5, and the travel cost to stop 'Ko' is 9. In this way, the travel cost between stops from the starting point to the final destination is calculated, and the optimal route for the passenger vehicle 6 is selected by comparing the sum of these costs.

[0082] In this embodiment, the clustering process in S22 aggregates each user's ride reservation into one or more reservation groups, and a common boarding and alighting point is set for each reservation group (see Figure 12). Therefore, in S52, the cost of the routes connecting the common boarding and alighting points set for each reservation group is calculated, and the route with the lowest cost is selected.

[0083] The CPU 21 then terminates the route search when it has found a route that allows all users who have made reservations to board and alight (S53: YES). Then, in S54, the CPU 21 identifies the route found in S52 as the optimal route for the passenger vehicle 6 to transport each user who has made a reservation according to the cluster proposal to be processed, and stores it in the flash memory 24.

[0084] Returning to Figure 8, and explaining the operation plan determination process program from S24 onwards, in S24, the CPU 21 determines whether or not a comparison of cluster plans has been performed at least once in the past in S27, which will be described later.

[0085] If it is determined that a comparison of cluster proposals has been performed at least once in S27 (S24: YES), the process proceeds to S26. Conversely, if it is determined that a comparison of cluster proposals has never been performed in S27 (S24: NO), the process proceeds to S25.

[0086] In S25, the CPU 21 stores the proposed cluster for processing and the optimal route searched in S23 for that cluster in the flash memory 24 as the most recommended route at this time.

[0087] Meanwhile, in S26, the CPU 21 reads the cluster plan and route currently stored in the flash memory 24. The cluster plan read in S26 is the most recommended cluster plan among those processed up to that point, and the optimal route for that cluster plan that was searched for in S23.

[0088] Next, in S27, CPU21 compares the costs of the cluster proposal for the current processing and the cluster proposal read in S26 to determine which is recommended.

[0089] The following provides a more detailed explanation of the process in S27. Specifically, the cost of the cluster proposal to be processed is calculated using the following equation (1). Equation (1) is expressed by letting f(x) be the sum of the costs between each node (stop). That is, given the distance between stops d, the clustering coefficient c, the sponsor coefficient s (0≦c≦9 and 0≦s≦9), and the case of passing through n stops, the sum of the costs between each node (stop) from the starting point to the ending point of the on-demand transport, f(x), is expressed by the following equation (1).

number

[0090] In equation (1) above, c is the clustering coefficient. The clustering coefficient is calculated by subtracting the cost between stops to reach a stop that can be shared by multiple people. The coefficient ranges from 0 to 9, with 1 added for each person who shares the stop. In other words, the more users who get on and off at a stop, the larger the clustering coefficient and the smaller the cost between stops to reach that stop. Therefore, cluster routes that pass through stops that consolidate many users will have lower costs.

[0091] On the other hand, 's' in equation (1) above is the sponsor coefficient. In some regions, on-demand transportation is operated with the support of sponsoring companies, and in such cases, passengers are expected to stop at stores operated by the sponsor or facilities associated with the sponsor. Therefore, a value greater than 0 is set as the sponsor coefficient to preferentially propose sponsored stops located near stores operated by the sponsor or facilities associated with the sponsor as boarding and alighting points, and the cost between stops to that stop is reduced. The sponsor coefficient may also be defined by the amount of sponsorship money. For example, by setting a larger sponsor coefficient for sponsored stops associated with sponsors who provide large amounts of sponsorship money, it is possible to further reduce the cost between stops to that stop. The amount of sponsorship money is stored in the sponsor information DB16.

[0092] In equation (1) above, by calculating the cost f(x) considering both the clustering coefficient and the sponsor coefficient, it becomes possible to prioritize the common boarding and alighting points for each user who has made a reservation, from among multiple bus stops, and then prioritize the determination that these common boarding and alighting points become sponsored bus stops.

[0093] Subsequently, in S28, the CPU 21 compares the cost f(x) calculated by equation (1) above for the cluster plan to be processed this time and the cluster plan read in S26. If the cost of the cluster plan to be processed this time is smaller, the CPU 21 stores the optimal route searched in S23 for the cluster plan to be processed this time and the optimal route for the cluster plan to be processed this time in the flash memory 24 as the most recommended route at this time. If the cost of the cluster plan read in S26 is smaller, no overwriting occurs.

[0094] Then, after executing the processes S23 to S28 above for all cluster proposals derived in the aforementioned clustering process (Figure 9), the process proceeds to S29.

[0095] In S29, the CPU 21 reads the cluster plan and route currently stored in the flash memory 24. The items read in S24 are the most recommended cluster plan and the optimal route searched in S23 for that cluster plan, out of all the cluster plans derived in the aforementioned clustering process (Figure 9). The CPU 21 then determines the route read from the flash memory 24 as the route for the passenger vehicle 6. Once the route is determined, the boarding and alighting points for each user who has made a reservation according to the cluster plan are also determined.

[0096] Furthermore, CPU21 also determines an operating schedule that specifies the arrival and departure times at each stop that the passenger vehicle 6 will pass through, based on the determined operating route, the departure time from the starting point of the operation, and the cluster proposal (the boarding and alighting points of each user). It is desirable that the operating schedule be determined by referring to traffic information obtained from an external server. Also, the method of determining the operating route of the passenger vehicle 6 described in S22 to S29 above is just one example, and the operating route of the passenger vehicle 6 may be determined by other methods. Even when using other methods, the boarding and alighting points of users will be aggregated, and an operating route will be searched that allows as many users who have made reservations as possible to board the passenger vehicle 6 according to their wishes.

[0097] Subsequently, in S30, the CPU 21 transmits the operation plan, including the route and schedule of the passenger vehicle 6 determined in S29, to the communication terminals 5 of all users who have made a reservation. 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, users can not only confirm that their reservation is complete but also understand the schedule on which the passenger vehicle 6 will operate. If there are users who have made a reservation but are unable to board with their current reservation, alternative options for boarding may be suggested, or they may be informed that they are unable to board with their current reservation.

[0098] Figure 15 shows the route plan guidance screen 71 displayed on the display 38 of the communication terminal 5 to which the route plan of the passenger bus 6 was transmitted in S30. As shown in Figure 15, the route plan guidance screen 71 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 route plan guidance screen 71 may also display the entire route of the provisionally determined passenger bus 6, and may display the arrival and departure times of bus stops other than those where the user boards and alights. In addition, regarding the fare, for example, if a sponsored bus stop is designated as a boarding and alighting point for the passenger bus 6, a discounted fare may be offered. Similarly, users who set a larger tolerance for departure or arrival times (for example, 20 minutes or more) or a longer walking distance (for example, 300 meters or more) may be offered discounted fares as a reward for their cooperation in consolidating boarding and alighting points.

[0099] According to the operation plan determination processing program of this embodiment, while searching for an operation route that allows users who have made a reservation to board the shared vehicle 6 according to their wishes, just as in the conventional method, it becomes possible to formulate an efficient operation plan by aggregating the user's boarding and alighting points. For example, Figure 16 is a diagram comparing an operation route formulated using the conventional method without aggregating the user's boarding and alighting points with an operation route formulated using the method of this embodiment. As shown in Figure 16, the operation route formulated using this embodiment has a shorter operating distance compared to the operation route formulated using the conventional method, and the operating costs can also be reduced. Therefore, it is expected that sustainable operation will be possible even in sparsely populated areas with few users. In addition, although users will be required to walk, the movement will be within the user's walking tolerance range, so users will not be forced to walk unnecessarily, and it can also contribute to the promotion of users' health.

[0100] 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 accept ride reservations from each user up until the reservation deadline (S12), which include the departure point, destination, at least one of the scheduled departure time from the departure point and the scheduled arrival time at the destination, and a walking allowance range that specifies the area where walking is permitted. Based on the content of the ride reservations received from each user, the reservations are aggregated into one or more reservation groups, provided that they do not exceed the walking allowance range. For each reservation group, a common boarding and alighting point is selected from among multiple stops for each user who has made a ride reservation included in that reservation group to board and alight the bus (S22). Based on the aggregated content, the bus operation plan is determined (S23-S29). Therefore, in the operation management of demand traffic where buses are operated based on reservations from users, it is possible to aggregate users' boarding and alighting points while taking into account the user's acceptable range for walking. As a result, it becomes easier to obtain user consent for the aggregation of boarding and alighting points, and efficient operation using the aggregated boarding and alighting points becomes possible. Furthermore, it is possible to set a wider range for the scheduled departure or arrival time for passenger reservations. By considering this range of scheduled departure or arrival times when consolidating reservation groups, it becomes possible to consolidate users' boarding and alighting locations as much as possible while taking into account the user's tolerance for time. Furthermore, the walking tolerance range is determined by the time spent walking, the distance walked, or the number of steps taken. This range is either entered by the user making the reservation or determined by the user's attributes, making it possible to aggregate user boarding and alighting points while considering the user's tolerance range for walking. Additionally, if the user is required to input the walking tolerance range, they can arbitrarily set it. On the other hand, if it is determined by the user's attributes, the system can set a walking tolerance range that does not burden the user, without requiring any input from the user. Furthermore, the system calculates the cost of routes connecting common boarding and alighting points selected for each reservation group and selects the route with the lowest cost (S24-S28). Based on the selected route, the system determines the boarding and alighting points for each user who has made a reservation (S29). This allows for the aggregation of users' boarding and alighting points and enables the search for recommended routes for aggregation.

[0101] [Note] The embodiments described above also disclose the following inventions. In the following description, the names and expressions of corresponding components in the embodiments, as well as the reference numerals used in the drawings, are indicated in parentheses for reference. However, the components of each invention are not limited to these indications.

[0102] (Invention A) A demand-responsive transportation management system (1) that manages the operation of a shared vehicle (6) used by multiple users who have made a reservation in advance, Multiple bus stops are pre-installed in the area where the aforementioned passenger bus operates. Among the aforementioned multiple stops are sponsored stops associated with the sponsors of on-demand transportation, A reservation acceptance means (11) that accepts ride reservations from each user until the reservation deadline, including the departure point, destination, at least one of the scheduled departure time from the departure point and the scheduled arrival time at the destination, and a walking range that specifies the area where walking is permitted, A boarding and alighting point determination means (11) determines the boarding and alighting points of each user who has made a boarding reservation from among the multiple bus stops, prioritizing the use of the sponsored bus stops, provided that the bus stops do not exceed the pedestrian-permissible area, based on the content of the boarding reservation received from each user in the aforementioned reservation acceptance means. A demand-responsive transportation management system comprising: an operation plan determination means (11) that determines an operation plan for a passenger vehicle based on the contents of passenger reservations received from each user in the reservation acceptance means and the contents determined by the boarding / alighting point determination means.

[0103] According to this, when on-demand transportation is operated with the support of sponsoring companies, it becomes possible to decide on a route plan that prioritizes stops located near stores operated by the sponsor or facilities associated with the sponsor as boarding and alighting points.

[0104] (Invention B) The boarding / alighting point determination means (11) is, A demand-responsive transportation management system (1) according to Invention A, which prioritizes standardizing the boarding and alighting points of each user who has made a ride reservation among multiple users from among the multiple bus stops, and then prioritizes determining that the standardized boarding and alighting points become the sponsored bus stops.

[0105] According to this, in the operation management of on-demand transportation, where shared vehicles are operated based on reservations from users, it becomes possible to determine an operation plan that prioritizes stops located near stores operated by sponsors or facilities related to sponsors as boarding and alighting points, in addition to consolidating users' boarding and alighting points.

[0106] (Invention C) The boarding / alighting point determination means (11) is, Based on the details of the boarding reservations received from each user in the aforementioned reservation acceptance means, multiple cluster proposals are generated that allow the boarding and alighting points of users who have made boarding reservations to be shared among multiple users. After evaluating whether the boarding and alighting points for each of the generated cluster proposals become the sponsored bus stops, the most recommended cluster proposal is selected. A demand-responsive traffic management system according to Invention B, which determines the boarding and alighting points of each user who has made a ride reservation according to the selected cluster plan.

[0107] According to this, in the operation management of on-demand transportation, where shared vehicles are operated based on reservations from users, it becomes possible to determine an operation plan that prioritizes stops located near stores operated by sponsors or facilities related to sponsors as boarding and alighting points, in addition to consolidating users' boarding and alighting points.

[0108] 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, an example of applying the communication terminal 5 to a smartphone has been described, but 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]

[0109] 1...Demand-responsive traffic management system, 2...Management center, 3...Management server, 4...User, 5...Communication terminal, 6...Passenger vehicle, 11...Server control unit (reservation acceptance means, boarding / alighting point determination means, operation plan determination means), 13...User DB, 14...Vehicle DB, 15...Map stop DB, 16...Sponsor information DB, 18...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, Multiple bus stops are pre-installed in the area where the aforementioned passenger bus operates. A reservation acceptance means that accepts ride reservations from each user up until the reservation deadline, including the departure point, destination, at least one of the scheduled departure time from the departure point and the scheduled arrival time at the destination, and a walking range that specifies the area where walking is permitted. Based on the content of the ride reservations received from each user in the reservation acceptance means, the ride reservations are consolidated into one or more reservation groups, provided that they do not exceed the pedestrian-permissible range, and for each reservation group, a common boarding and alighting point is selected from among the multiple bus stops for each user who made a ride reservation included in that reservation group to board and alight the bus. A demand-responsive traffic management system comprising: an operation plan determination means for determining the operation plan of a passenger vehicle based on the content determined by the boarding / alighting point determination means.

2. The aforementioned boarding reservation can be set with a wider range for the scheduled departure time or the scheduled arrival time. The demand-responsive traffic management system according to claim 1, wherein the means for determining the boarding / alighting point aggregates the reservation groups taking into consideration the range of the scheduled departure time or the scheduled arrival time.

3. The aforementioned permissible walking range is determined by the time spent walking, the distance walked, or the number of steps taken. The pedestrian permissible range is entered by the user making the ride reservation, or determined by the attributes of the user making the ride reservation, according to claim 1.

4. The aforementioned means for determining the operation plan is: The cost of the routes connecting the common boarding and alighting points selected for each reservation group is calculated, and the route with the lowest cost is selected. A demand-responsive transportation management system according to any one of claims 1 to 3, which determines the boarding and alighting points of each user who has made a ride reservation according to the selected route.

Images