Taxi reservation support system

Abstract

To provide a taxi reservation support system that can facilitate matching in a supply-demand relationship between a taxi company and potential taxi users to raise an occupancy rate of taxi vehicles.SOLUTION: A taxi reservation support system has operation plan creation processing of collecting information on an actual result of use of created operation plans from taxi companies and storing the information, using the information on the operation plan resulted to be used a large number of times in creating a new operation plan, reflecting information on a time zone included in the operation plan having the actual result on departure time in the new operation plan, receiving constraint information designated by a taxi company, restricting a creation condition for a new operation plan, creating a new operation plan for a route designated in accordance with requests from users, and when an operation plan is settled through application from the users, automatically transmitting a request to allocate a vehicle having the plan to a taxi company.SELECTED DRAWING: Figure 9

Description

[Technical field]

[0001] The present invention relates to a taxi reservation support system, and more particularly to a technique for supporting the provision of new methods for using taxis. [Background technology]

[0002] Regarding the use of vehicles such as taxis, various non-traditional usage patterns, such as ride sharing, have been proposed. For example, Patent Document 1 discloses a monitoring system for promoting the use of car sharing. The management system includes a reservation receiving means for receiving a reservation procedure for car sharing from a user's mobile communication terminal via a communication network, and a communication means for transmitting a message to the mobile communication terminal suggesting the use of a taxi, a ride-sharing car, or a sharing bicycle that is expected to be used by the user to travel to the location of the reserved sharing car or to travel from the return location of the shared car, together with a discounted fare for the shared car.

[0003] Furthermore, Patent Document 2 discloses an information processing device that provides a service that is easy for elderly people and the like to use. The server supports the provision of a service in which the price paid for a flat-rate taxi to travel within a specified area with the user as a passenger is constant for the same user. The request reception unit receives requests for use of a flat-rate taxi from multiple users (requests include both advance reservations and requests for immediate boarding). The vehicle dispatch planning unit creates a plan for transportation by flat-rate taxi based on the content of the request from each of the multiple users and the category set for each of the multiple users. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2019-144654 A [Patent Document 2] JP 2020-46884 A Summary of the Invention [Problem to be solved by the invention]

[0005] There is a lot of potential demand for transportation, including taxis. For example, as a result of elderly people giving up their driver's licenses, they need an alternative means of transportation to replace their personal cars. As a result of young people moving away from cars, there are people who do not own their own cars and need some kind of transportation that they can use easily. In addition, people of child-rearing age who do not own their own cars need a means of transportation that they can use easily on a daily basis. Tourists visiting a particular area also need a means of transportation that they can use more easily within that area other than the current taxis, buses, and trains.

[0006] On the other hand, taxi companies and other operators are facing various challenges, such as rising labor costs, securing human resources, strengthening regulations, and annually declining operating revenues. Therefore, they want to increase the ratio of taxis that are actually in operation with passengers on board, and increase sales.

[0007] However, in reality, many taxis are parked in front of train stations and waiting in a row, or are driving around looking for customers. In other words, although there is a lot of potential demand for transportation such as taxis as described above, the number of people who actually use taxis is relatively small. The reason for this is thought to be that the service content of taxi companies that provide transportation and the supply and demand relationship with potential users who need transportation such as taxis are not well matched. For example, potential users are likely to give up on using taxis because the fare is too high even if they want to use them.

[0008] Therefore, if car sharing is used as described in Patent Document 1, the taxi fare per user can be reduced, which can increase the opportunities for potential users to use taxis. However, the current car sharing system does not take into consideration the convenience of taxi companies or the convenience of potential users.

[0009] In addition, to realize taxi ride sharing, it is necessary to find multiple users who wish to ride in the same taxi under the same conditions, and it is further necessary for these users to make reservations for the taxi service in advance.

[0010] Therefore, for example, it is assumed that a company providing taxi operation services will create an operation plan in advance and solicit users. However, if the created plan is significantly different from the conditions desired by the users, the users will not apply for this operation plan, and there is a high possibility that the operation plan will not be realized.

[0011] The present invention has been made in consideration of the above-mentioned circumstances, and its object is to provide a taxi reservation support system that can be used to easily match supply and demand between taxi companies and potential taxi users, thereby increasing the ratio of taxis that are in actual service. [Means for solving the problem]

[0012] In order to achieve the above-mentioned object, the taxi reservation support system according to the present invention has the following features (1) to (5). (1) A taxi reservation support system that supports a reservation procedure for the use of an operating taxi between one or more taxi operators capable of operating a taxi vehicle and any user who wishes to ride in the taxi vehicle, comprising: a first communication unit for communicating with a company terminal used by the operator, a second communication unit for communicating with a user terminal used by the user, and a server capable of providing communication services to the company terminal and the user terminal, The server, Route including at least the starting point and the destination Many users' comments about A route information accumulation function that collects and accumulates performance information from a plurality of the operators; A plan generation function that preferentially extracts information on a specific operation route that is used at least frequently based on the information on the operation route accumulated by the route information accumulation function, and generates an operation plan including at least a departure point and a destination using the extracted specific operation route; a service provider plan selection function that presents the contents of the plurality of operation plans to the service provider terminal and selects one or more of the plurality of operation plans as a service provider selected plan in response to an instruction from the service provider terminal; a user application receiving function for presenting the content of the selected trader-selected plan to the user terminal and specifying the plan selected in response to an instruction from the user terminal as a user-applied plan; A vehicle dispatch request function that determines the taxi operation of each plan according to the application status of the user-applied plan, transmits a vehicle dispatch request according to the corresponding plan to the operator of the confirmed plan, and transmits a reservation confirmation notification to the user terminal of the user who applied for the confirmed plan; A taxi reservation support system having the above.

[0013] (2) The route information accumulation function further accumulates time zone information representing the results of the time zone during which the route was operated as the information on the operation route, The plan generation function reflects the time zone information stored by the route information storage function in the departure time of the operation plan to be generated. The taxi reservation support system described in (1) above.

[0014] (3) The server further includes a restriction information acquisition unit that acquires restriction information that restricts at least one of a departure time period, a departure point, and a destination from each of the operators; The plan generation function generates an operation plan for each operator by reflecting the constraint information acquired by the constraint information acquisition unit. A taxi reservation support system according to (1) or (2) above.

[0015] (4) the server further includes a user request receiving unit that receives a plan request from the user terminal including at least information on a departure point and a destination; The plan generation function generates an operation plan for a route that satisfies the conditions of the departure point and destination of the plan request received by the user request receiving unit. A taxi reservation support system according to any one of (1) to (3) above.

[0016] (5) A taxi reservation support system that supports a reservation procedure for the use of an operating taxi between one or more taxi operators capable of operating a taxi vehicle and any user who wishes to ride in the taxi vehicle, comprising: a reservation management server including a first communication unit for communicating with a service provider terminal used by the service provider and a second communication unit for communicating with a user terminal used by the user, the reservation management server being capable of providing communication services to the service provider terminal and the user terminal, respectively; Route including at least the starting point and the destination Many users' comments about A performance management server that collects and accumulates performance information from a plurality of the vehicle operators, The reservation management server, A plan generation function of preferentially extracting information on a specific operation route that is used at least frequently based on the information on the operation route accumulated by the record management server, and generating an operation plan including at least a departure point and a destination using the extracted specific operation route. and, a service provider plan selection function that presents the contents of the plurality of operation plans to the service provider terminal and selects one or more of the plurality of operation plans as a service provider selected plan in response to an instruction from the service provider terminal; a user application receiving function for presenting the content of the selected trader-selected plan to the user terminal and specifying the plan selected in response to an instruction from the user terminal as a user-applied plan; A vehicle dispatch request function that determines the taxi operation of each plan according to the application status of the user-applied plan, transmits a vehicle dispatch request according to the corresponding plan to the operator of the confirmed plan, and transmits a reservation confirmation notification to the user terminal of the user who applied for the confirmed plan; A taxi reservation support system having the above.

[0017] According to the taxi reservation support system having the above configuration (1), the route of the operation plan generated by the plan generation function is based on a specific operation route that is used more frequently or more frequently among various operation routes on which operation services have actually been provided by a plurality of operators. In other words, operation plans for routes that are in high demand among taxi users are generated preferentially, so that operation plans for heading to specific popular destinations, for example, can be presented to taxi users. As a result, the possibility that taxi users will apply for the operation plans presented by the system increases, and the possibility that the operation plan will be realized increases. Therefore, it is possible to easily match the supply and demand relationship between the taxi company and potential taxi users, and to improve the ratio of taxi vehicles in actual vehicle status.

[0018] According to the taxi reservation support system having the above configuration (2), the operation plan generated by the plan generation function is based on a specific operation route that is actually used frequently and is limited to departures during a specific time period that is used frequently. In other words, operation plans for routes and time periods that are actually in high demand among taxi users are generated preferentially, so that it is possible to present taxi users with operation plans that operate during times that are convenient for daily shopping or travel for sightseeing, for example.

[0019] According to the taxi reservation support system of the above configuration (3), it becomes easy for taxi companies that actually provide taxi service to generate only operation plans that reflect their respective desires. For example, it becomes possible to restrict conditions so as to avoid time periods when each taxi company cannot provide taxi vehicles and drivers, or to restrict conditions so as to avoid departure points or destinations where it takes time to dispatch a vehicle due to distance or other factors. Therefore, each taxi company can specify conditions that are convenient for increasing the actual usage rate of taxi vehicles and increasing the total sales for all time periods.

[0020] According to the taxi reservation support system configured as in (4) above, even if the operation plans presented by the system do not include a plan for the route desired by the taxi user, it is possible to generate and present a new operation plan that reflects the taxi user's actual wishes, or to request the taxi company to publish the plan. Therefore, it is possible to provide a taxi operation service that attracts potential taxi users.

[0021] According to the taxi reservation support system of the above configuration (5), it is possible to easily match the supply and demand relationship between the taxi company and potential taxi users, and improve the ratio of actual taxi vehicles. In addition, by providing the result management function to the result management server and the reservation management function to the reservation management server, it becomes easier to distribute the load of the entire system and perform efficient processing, and it becomes possible to handle a large amount of demand. Therefore, for example, by comparing the upper and lower limit numbers of passengers for the plan with the number of users who applied, it is judged whether the number of applications from users exceeds or is the same as the minimum number of people for the event (recruitment). Effect of the Invention

[0022] According to the taxi reservation support system of the present invention, it is possible to easily match the supply and demand relationship between the taxi company side and potential taxi users, and to improve the ratio of actual taxi vehicles. In other words, since operation plans for routes that are actually in high demand among taxi users are generated preferentially based on the operation record, it is possible to present taxi users with operation plans for heading to a specific popular destination, for example.

[0023] The present invention has been briefly described above. Furthermore, the details of the present invention will be further clarified by reading the following description of the embodiment of the present invention (hereinafter, referred to as "embodiment") with reference to the accompanying drawings. [Brief description of the drawings]

[0024] [Figure 1] FIG. 1 is a block diagram showing an example of the overall configuration of a taxi reservation support system according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a sequence diagram showing an example of a main operation of the taxi reservation support system. [Diagram 3] FIG. 3(a) and FIG. 3(b) are front views showing specific examples of displaying an operation plan. [Figure 4] FIG. 4 is a flowchart showing a procedure for reservation management in the taxi reservation support system. [Diagram 5] FIG. 5 is a flowchart showing the procedure of the brokerage process in the taxi reservation support system. [Figure 6] FIG. 6 is a block diagram showing an example of the configuration of a taximeter on-board unit. [Figure 7] 7(a) and 7(b) are front views each showing an example of a screen display of an in-vehicle taximeter unit. [Figure 8] FIG. 8 is a schematic diagram showing an example of the configuration of main performance information included in the operation performance DB. [Figure 9] FIG. 9 is a flowchart showing the processing steps for generating an operation plan. [Figure 10] FIG. 10 is a flowchart showing a specific example of detailed processing in generating an operation plan. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0025] Specific embodiments of the present invention will be described below with reference to the accompanying drawings.

[0026] <System configuration example> FIG. 1 is a block diagram showing an example of the overall configuration of a taxi reservation support system 100 according to an embodiment of the present invention.

[0027] A taxi cloud service 10, which constitutes the core of the functions of the taxi reservation support system 100, is placed on a computer in a data center 50. In this embodiment, a Web server 11, a reservation management server 12, and an operation plan DB (database) 13 in the data center 50 fulfill the functions of the taxi cloud service 10. In addition, a performance management service 10B for managing performance information related to actual taxi operations is placed on the data center 51. In this embodiment, a Web server 15, a performance management server 16, and an operation performance DB 17 in the data center 51 fulfill the functions of the performance management service 10B.

[0028] Each of the taxi cloud service 10 and the performance management service 10B is composed of communication-capable computer hardware, the operating system (OS) required to operate as a server, and application software that realizes the operations required to provide the functions of these services.

[0029] Operators such as taxi companies capable of operating taxi vehicles can use the taxi cloud service 10 by accessing it using the operator terminals 20-1, 20-2, 20-3, etc. owned by each operator. The performance management service 10B can periodically collect necessary performance information at appropriate times from the operator terminals 20-1, 20-2, 20-3, etc. of multiple operators and the taxi meter on-board devices 40-1, 40-2, 40-3, etc. Note that the on-board devices 40-1, 40-2, etc. may not be taxi meters, but tablets or smartphones with equivalent functions can be used to provide and operate this service.

[0030] Each operator terminal 20-1, 20-2, 20-3, ... is a terminal equipped with a communication function, such as a general personal computer, and can connect to and communicate with the Web server 11 or the reservation management server 12 in the data center 50 via the Internet 21 using a public communication line. In addition, each operator terminal 20-1, 20-2, 20-3, ... is pre-installed with dedicated application software or a Web browser for using the taxi cloud service 10 and the performance management service 10B. In addition, the Web server 15 or the performance management server 16 of the performance management service 10B can connect a communication line between each operator terminal 20-1, 20-2, 20-3, ... and the Internet 21 to collect necessary information.

[0031] By using the taxi cloud service 10, operators such as taxi companies can select a desired operation plan from among operation plans prepared in advance by this service. In addition, they can receive a service to assist any user who will be a taxi passenger in making a reservation for the selected operation plan.

[0032] As described later, in order to provide an efficient operation plan, the contents of the operation plan generated by the taxi cloud service 10 are determined based on the performance information of taxi operations of each operator collected by the performance management service 10B.

[0033] On the other hand, each user who may become a passenger using a taxi as a means of transportation for various purposes can access the taxi cloud service 10 using his / her own user terminal 30-1, 30-2, 30-3, ... equipped with communication function, and use this service.

[0034] As the user terminals 30-1, 30-2, 30-3, etc., various terminals such as a smartphone, a mobile phone terminal, a notebook computer, a desktop computer, etc. When a user uses a portable user terminal 30, this user terminal 30 uses its wireless communication function to connect to any of the wireless base stations 22-1, 22-2, etc., and further connects to the Web server 11 or the reservation management server 12 in the data center 50 via the Internet 21, and can access the taxi cloud service 10.

[0035] By using the taxi cloud service 10, a taxi user can select a taxi operation service that can be used as a means of transportation when going out from a list of plans presented by the Web server 11. The user can also apply for a reservation for the selected plan. As will be described later, whether or not each plan is actually realized may change depending on the user's application status, etc.

[0036] The taximeter vehicle-mounted devices 40-1, 40-2, 40-3, etc. are mounted on each taxi vehicle managed by each operator such as a taxi company. Each taximeter vehicle-mounted device 40-1, 40-2, 40-3, etc. has a function required for using the taxi cloud service 10 and the performance management service 10B. That is, each taximeter vehicle-mounted device 40 has a wireless communication function, and can communicate with the taxi cloud service 10 at any time, and can use the service provided by the taxi cloud service 10. This realizes a service in which each taxi vehicle is dispatched according to the schedule of the plan determined by the taxi cloud service 10 and operates with each user who has made a reservation as a passenger. Note that the vehicle-mounted devices 40-1, 40-2, etc. may not be taximeters, but may be tablets or smartphones having equivalent functions to provide and operate this service.

[0037] <Examples of main system operations> FIG. 2 is a sequence diagram showing an example of a main operation of the taxi reservation support system 100. As shown in FIG. The taxi cloud service 10 included in the taxi reservation support system 100 has the functions of steps S11, S13, S15, S17, S19, and S20 shown in Fig. 2. Also, a person in charge of a taxi company or the like that can use the taxi cloud service 10 can execute steps S12 and S14 in Fig. 2 by operating the operator terminal 20. Also, any user that can use the taxi cloud service 10 can execute steps S16 and S18 in Fig. 2 by operating the user terminal 30.

[0038] On the other hand, the performance management service 10B collects performance information on the actual operation of taxi vehicles, for example, by communication with each terminal that is executed periodically or communication that is executed collectively during a specific time period.

[0039] The reservation management server 12 of the taxi cloud service 10 automatically generates various types of operation plans for services that transport passengers using taxi vehicles (S11). These operation plans are automatically generated based on performance information collected by the performance management service 10B, and are determined taking into consideration various demand forecasts and convenience. It is not yet decided whether the operators will actually adopt each operation plan generated by the taxi cloud service 10, and it is not yet confirmed whether each plan will be realized. In addition, data on boarding and alighting points recorded by the taxi meter vehicle-mounted device 40 may be collected in a database, and this data may be used when generating operation plans.

[0040] In addition, each taxi company can specify in advance information for restricting the conditions for generating the operation plan generated by the taxi cloud service 10, specifically, restrictions on the departure place, destination, time period, etc. Alternatively, the date and time of the selected plan can be adjusted at the discretion of the person in charge at the taxi company.

[0041] Each operation plan generated by the taxi cloud service 10 is registered and stored in the operation plan DB 13. Although details will be described later, each operation plan includes information indicating at least each point including a departure point and a destination, and information indicating a schedule of operation.

[0042] A person in charge at a taxi company or the like connects an operator terminal 20 to the taxi cloud service 10 via the Internet 21, and searches for and acquires the necessary information (S12). The taxi cloud service 10 presents information on the various operation plans generated in S11 to the connected operator terminal 20 (S13).

[0043] A person in charge of a taxi company or the like selects an appropriate operation plan that allows the operation service to be provided from among the many operation plan candidates presented by the taxi cloud service 10, while taking into consideration, for example, the availability of the company's taxi vehicles by date and time, the availability of each driver, and the cost of operating the taxi vehicles. At this time, the person in charge of the taxi company or the like can manually adjust the date and time, the minimum number of participants, etc., of the plan presented to the operator terminal 20. Then, the operator terminal 20 notifies the taxi cloud service 10 of information indicating the selected plan (S14).

[0044] Based on the information notified from the operator terminal 20, the taxi cloud service 10 registers the operation plan selected by the operator in the operation plan DB 13 as an operation plan that can be provided to the user (potential passenger) (S15).

[0045] Various users (passengers) can access the taxi cloud service 10 via the Internet 21 when necessary, using dedicated application software (app) installed in the user terminal 30 or a general web browser. For example, a user who wishes to use a taxi as a temporary means of transportation in daily life or as a means of transportation for various events such as travel performs a search for a desired operation plan on the user terminal 30 (S16).

[0046] In response to an access from the user terminal 30, the taxi cloud service 10 presents a list of operation plans that can be provided to the user (passenger) registered in S15 (S17).

[0047] The user searching on the user terminal 30 selects an appropriate plan from the list of operation plans presented by the taxi cloud service 10 while considering the departure point, destination, time zone, travel budget, etc. of his / her planned activities, and operates the user terminal 30 to apply for the plan (S18). As a result, the user terminal 30 transmits information for applying for the operation plan selected by the user to the taxi cloud service 10.

[0048] Although not shown in Figure 2, if the plan desired by the user (passenger) is not included in the list of presented operation plans, the user can also request a new plan from the taxi cloud service 10.

[0049] Based on the information transmitted from the user terminal 30, the taxi cloud service 10 starts accepting applications for the operation plan selected by the user (S19).

[0050] When the taxi cloud service 10 starts accepting applications for operation plans, it executes "reservation management" for example periodically (S20) in order to manage each operation plan for which applications from at least users have been accepted. Then, for an operation plan for which operation has been confirmed, it transmits a dispatch request C1 for that plan to the operator terminal 20 of the relevant company, or to a specific destination registered in advance. At the same time, it transmits a reservation confirmation notification C2 to the user terminal 30 of the specific user who applied for that plan, or to a specific destination registered in advance. Details of "reservation management" will be described later.

[0051] <Examples of operation plans> <Display example> 3(a) and 3(b) are front views showing specific examples of display of operation plans P1 and P2, respectively.

[0052] For example, when a user operates the user terminal 30 to search for candidate plans in step S16 of FIG. 2, the user can display and confirm information about one operation plan P1 as shown in FIG. 3(a) and information about one operation plan P2 as shown in FIG. 3(b) on the screen of the user terminal 30.

[0053] In the examples of Figures 3(a) and 3(b), each operation plan P1, P2 includes a representative image 61, plan name information 62, fare information 63, departure / destination information 64, schedule information 65, and recruitment condition information 66.

[0054] The representative image 61 is information such as a photo showing a typical landscape of the destination in the corresponding plan. The plan name information 62 is assigned a name that allows the user to easily understand the contents of the plan, such as the purpose or destination of the corresponding plan. The fare information 63 indicates the service fare per passenger or the service fare per application for the corresponding plan.

[0055] The departure / destination information 64 is information about the locations of the departure and destination, specifically, station names and store names that represent those locations. The schedule information 65 includes information about the operation date, departure time, arrival time, and duration at the destination (in the case of a round trip).

[0056] The recruitment condition information 66 consists of the minimum number of passengers and / or the minimum number of tickets required to realize the operation service of the corresponding plan, and the price per person and / or the price per ticket, for example, as shown in Figures 3(a) and 3(b).

[0057] <How to submit operation plans> As an example, we will set up a long-term matching period (crowdfunding format) to solicit donations. Here, for example, if there are not a certain level of applicants for a recruitment, the taxi operator may stop operation because it may become unprofitable. However, if there is economic support from the national or local government in addition to fare revenue, and the actual fare is not lower than the fare approved by the government, it is possible to operate the service even if there are not a certain level of applicants. In the case of a long-term matching period, reservations for the plan will be possible on a per-passenger basis or per-entry basis. In addition, one person will be able to make multiple reservations by paying multiple fees. In addition, when determining whether the operation plan is successful or not, if the number of users who have applied does not meet the minimum number of units to be recruited, the shortage of units may be allocated to users who have already applied. In such a recruitment method, the maximum fare per person is specified in the operation plan.

[0058] <Operation plan fees> A ride-sharing fee will be applied based on the assumption that multiple people will share the same taxi, making it possible to use the service at a lower unit price than regular taxis. The fare is confirmed in advance. It will also be possible to adopt a fare / fee system that reduces the unit price each time the upper limit on the number of people / units recruited increases.

[0059] <What should be specified and stipulated in the operation plan> Location: starting point, destination, end point, etc. Time: Scheduled departure time, scheduled arrival time at destination, duration of stay at destination, scheduled departure time, etc. Price: Fare per person / per unit Number of people / units: Maximum, minimum, etc. Regarding the amount, the fare per person for each number of people who ultimately applied may be listed.

[0060] <Operation plan submission period> The period during which users (passengers) can make reservations can be determined by the operator (taxi company, etc.) for each plan. For example, reservations can be accepted from about two months before the scheduled trip, and reservations can be closed one week before the trip, finalizing the plan.

[0061] <Reservation management processing procedure> Fig. 4 is a flowchart showing the procedure of reservation management in the taxi reservation support system 100. The reservation management server 12 that processes the reservation function of the taxi cloud service 10 executes, for example, the procedure shown in Fig. 4 before the end of the recruitment period for each plan in step S19 in Fig. 2. The procedure in Fig. 4 will be described below.

[0062] The reservation management server 12 compares the upper and lower limits of the number of people / units to be recruited (corresponding to the recruitment condition information 66) in each operation plan applied for by the user with the number of people / units to be applied for that plan that was actually accepted from the user (S21). If the number of people / units to be applied is within the range of both the upper and lower limits of the number of people / units to be recruited, the process proceeds from S21 to S28, and it is determined that the operation of that operation plan is established.

[0063] If the conditions of S21 are not met, the reservation management server 12 performs an intermediation process in the next S22 to adjust the number of people / lots with other similar operation plans. In other words, if the number of people / lots applied by the user who applied for the plan does not reach the lower limit of the number of people / lots available, the applicant for the similar plan is intermediated to make a re-reservation to switch to the plan. Conversely, the number of people / lots applied by the user who applied for the plan cannot exceed the upper limit of the number of people / lots available. If the upper limit is reached, the user who tried to apply for the plan is intermediated to another similar plan. A specific example of this intermediation process will be described later.

[0064] After the mediation process is completed in S22, the reservation management server 12 again compares the lower limit of the number of people / units to be recruited in the plan with the number of people / units actually accepted from users (S23). If the number of people / units to be recruited is within the range of the number of people / units to be recruited, the process proceeds from S23 to S28, and it is determined that the operation of the operation plan is established.

[0065] If the number of applicants / units is less than the lower limit of the number of applicants / units in S23, the reservation management server 12 executes a solicitation process in the next S24 to encourage users who have already applied for the operation plan to purchase additional units.

[0066] After the solicitation process is completed in S24, the reservation management server 12 again compares the lower limit of the number of people / units to be recruited in the plan with the number of people / units actually accepted from users (S25). If the number of people / units to be recruited is within the range of the number of people / units to be recruited, the process proceeds from S25 to S28, and it is determined that the operation of the operation plan is established.

[0067] If the number of applicants / lots is less than the lower limit of the number of applicants / lots in S25, the reservation management server 12 notifies the taxi company in the next S26 that the operation plan will be operated without reaching the lower limit of the application level.

[0068] The reservation management server 12 automatically identifies whether or not to implement the operation plan while the number of passengers who applied / the number of shares is less than the number of passengers / the number of shares offered. For example, when an operator such as a taxi company can receive subsidies from the national or local government as income other than the fare paid by passengers, or when other income is expected, the reservation management server 12 compares the total income with the cost of operation, and makes a decision while considering various conditions so that the operator will not incur a loss.

[0069] If the operation plan is to be implemented, the process proceeds from S27 to S28, and it is determined that the operation of the operation plan is established. If the operation plan is not to be implemented, the process proceeds from S27 to S29, and it is determined that the operation plan is not established.

[0070] When the reservation management server 12 determines in S28 that the operation of the operation plan is established, it transmits a request C1 for dispatching the plan to the operator terminal 20 of the operator such as a taxi company that applied for the operation plan, as shown in Fig. 2. It also transmits a notification C2 of reservation confirmation to the user terminal 30 of the user who applied for the reservation of the operation plan.

[0071] On the other hand, if it is determined in S29 that the operation plan has not been established, the reservation management server 12 notifies the taxi company that has applied for the operation plan and the user who has applied to make a reservation for the operation plan that the operation plan has not been established (not shown).

[0072] In addition to the reservation management shown in FIG. 4, the reservation management server 12 can also provide the following additional services. (1) When a user applies for each operation plan, the user can disclose to the user the attributes of other users who will be riding with him / her, such as age group, gender, etc., to the extent that personal information is protected, based on the information already registered. (2) It is possible to implement a service in which each user can post their desired operation plan in a specific location on the Internet so that other users can view it, and solicit passengers for the operation plan. Alternatively, each user can send a posting request for their desired operation plan to a taxi company. In this case, the posting request from the user is notified to the operator terminal 20. When the taxi company accepts the posting request and selects to post, the plan is posted in a specific location on the Internet so that other users can view it. (3) It is possible to provide a function that allows users to earn additional income by adding a section for posting any advertisements to the location where the information in (2) above is posted. (4) It is possible to provide a function for a user who has made a reservation through the taxi cloud service 10 to evaluate the taxi driver and other users after actually riding in a taxi according to the operation plan, and a function for the user to post numerical values ​​reflecting the evaluation results in a specific location on the Internet so that they can be viewed by various users. (5) It is also possible to provide a service that allows the use of commuter passes or multi-ride tickets as part of an operation plan that can be reserved by each user.

[0073] <Processing procedure for mediation> Fig. 5 is a flowchart showing the procedure of the mediation process (S22) in the taxi reservation support system 100. The mediation process in Fig. 5 will be described below.

[0074] The reservation management server 12 of the taxi cloud service 10 identifies one operation plan applied for by the user from among the many operation plans managed in the operation plan DB 13 (S31), and identifies the departure and destination areas for that operation plan (S32).

[0075] For example, the area may be an area corresponding to a place name or town name associated with the departure or destination point, or a range contained within an area such as a circle centered on each point and within a specified distance from the central position.

[0076] The reservation management server 12 searches for operation plans from among the numerous operation plans managed in the operation plan DB 13, whose departure point matches or is similar to the area of ​​the departure point identified in S32, and extracts all those that meet the conditions (S33).

[0077] The reservation management server 12 searches through the numerous operation plans managed in the operation plan DB 13 for operation plans whose destinations match or are similar to the area of ​​the destination identified in S32, and extracts all those that meet the conditions (S34).

[0078] The reservation management server 12 calculates a similarity indicating the degree to which the schedule and time period of each operation plan extracted in either S33 or S34 are similar to the applied plan in S31 (S35).

[0079] The reservation management server 12 outputs a list of the operation plans extracted in either S33 or S34 in a state in which the operation plans are arranged in order of decreasing similarity calculated in S35 (S36). This list of operation plans is displayed on the screen of the user terminal 30.

[0080] The reservation management server 12 accepts an input operation for a specific user who has applied for the operation plan being processed to switch from that plan to a reservation for another plan (S37). That is, if the number of applicants / number of units of the user who has reserved that plan is insufficient or the application has ended, the reservation management server 12 mediates the user to change the reservation from that plan to another similar plan, and attempts to adjust the number of applicants / number of units for each plan to be appropriate. Whether or not to actually change the reservation is decided at the discretion of each user. This mediation processing function can also be applied when the plan searched for by the user cannot be found in S16 of FIG.

[0081] <Example of taximeter on-board unit configuration> Fig. 6 is a block diagram showing a configuration example of the taximeter on-board device 40. The taximeter on-board device 40 shown in Fig. 6 is equipped with an additional function to implement a taxi operation service according to a reserved operation plan using the taxi cloud service 10 described above, in addition to the same functions as those of a taxi meter installed in a normal taxi vehicle.

[0082] 6 includes a control unit 41, a wireless communication unit 42, a display unit 43, and an operation unit 44. The control unit 41 also includes a cloud linking function 41a, a reservation status confirmation function 41b, an operation information display function 41c, and a passenger authentication function 41d.

[0083] The cloud linking function 41a connects to the taxi cloud service 10 on the Internet 21 via the wireless communication unit 42, and performs linking control so that the taxi meter in-vehicle device 40 can use various functions provided by the taxi cloud service 10. In addition, the cloud linking function 41a provides performance information to the performance management service 10B.

[0084] The reservation status confirmation function 41b has a function for managing the reservation status and reservation numbers of each passenger for the operation plans that are assigned to the taxi vehicle equipped with this on-board device by the predetermined dispatch procedure of the taxi company among the operation plans registered and reserved in the taxi cloud service 10. A reservation number is assigned to the user who has reserved each operation plan at the time of reservation, so the taxi meter on-board device 40 can obtain the number and display it on the screen of the display 43.

[0085] The operation information display function 41c has a function of automatically displaying the reservation details for the operation plan assigned to the taxi vehicle equipped with this on-board device at a timing of several hours to several tens of minutes before the reservation time. This display timing can be set for each taxi company. As a result, operation information such as the departure place, disbanding place, time, destination, and number of passengers are displayed on the screen of the display 43.

[0086] The passenger authentication function 41d has an authentication function for verifying the identity of the person who made the reservation when the driver of the taxi picks up a passenger in the taxi according to the reservation details. For example, the driver operates a numeric keypad that can be displayed on the screen of the display 43 to input the reservation number of each passenger, and the passenger authentication function 41d cooperates with the taxi cloud service 10 via the cloud cooperation function 41a to authenticate the person who made the reservation.

[0087] <Example of on-board device screen display> 7(a) and 7(b) are front views showing examples of screen displays of the taxi meter vehicle-mounted unit 40. Note that displays such as those in Fig. 7(a) and Fig. 7(b) may be displayed on a tablet terminal or a smartphone mounted in a taxi vehicle. For example, for an operation plan assigned to a taxi vehicle equipped with this on-board device, when it is several hours to several tens of minutes before the reservation time, a screen like that shown in Figure 7(a) is displayed on the display 43 under the control of the operation information display function 41c.

[0088] In the example of Fig. 7(a), the contents of a specific operation plan reserved to start in a few hours in a taxi vehicle equipped with the on-board device are displayed, including the plan name indicating the destination, the departure time, and the number of passengers. By displaying the screen of Fig. 7(a), passengers can also check the contents of the reserved plan.

[0089] When each passenger gets into a taxi vehicle, the passenger authentication function 41d displays a screen like that shown in Fig. 7(b) on the display 43. That is, the total fare for the plan, the amount to be paid by the passenger, the numeric keypad to be used for input, etc. are displayed on the screen. By inputting the reservation number, etc. using this numeric keypad, the identity of the passenger who made the reservation can be verified.

[0090] The displays shown in FIG. 7(a) and FIG. 7(b) may be displayed on a tablet terminal or a smartphone installed in a taxi vehicle.

[0091] <Example of performance information configuration> An example of the configuration of main performance information included in the operation performance DB 17 collected and managed by the performance management service 10B is shown in Fig. 8. In the example of Fig. 8, operation performance information 71, boarding and alighting point information 72, and user information 73 are managed in the operation performance DB 17 as performance information.

[0092] The operation record information 71 includes route information 71a, time period information 71b, number of uses information 71c, and fare / charge information 71d. The route information 71a is record data representing the departure point, destination, distance, and required time in each operation plan actually performed by each operator such as a taxi company and daily business results. The time period information 71b is record data representing the time period including the departure time and arrival time in each operation plan actually performed by each operator such as a taxi company and daily business results. The number of uses information 71c is record data representing the number of uses or frequency of use for each operation plan actually performed by each operator such as a taxi company and daily business results. The fare / charge information 71d is record data representing the fare / charge based on the operation plan actually performed by each operator such as a taxi company and the distance and time traveled during daily business (information of the route information 71a).

[0093] The boarding and alighting point information 72 compiles and manages useful information related to various boarding and alighting points (starting point, destination point) of each operation plan that has actually been operated, and includes transportation facility cooperation information 72a, new construction information 72b, facility information 72c, barrier-free information 72d, and event schedule information 72e. This information is updated to the latest information on an ongoing basis.

[0094] The transportation facility cooperation information 72a holds information necessary to identify whether the boarding and alighting points of each operation plan are points where time cooperation with transportation facilities other than taxis should be considered, such as stations and airports. The new establishment information 72b holds information (location, store name, type, opening date, etc.) that represents new facilities that can become new destinations, such as newly opened stores and newly opened theme parks, for each facility for a certain period (e.g., one month) from the time of opening / opening.

[0095] The facility information 72c holds information necessary to identify whether the destination is a place with a special facility such as a castle, park, museum, art gallery, or stadium, and the type of facility. The barrier-free information 72d holds information necessary to identify whether the destination facility is barrier-free. The event schedule information 72e holds information indicating the annual event schedule (dates for each event) at the destination facility.

[0096] The user information 73 manages performance information that indicates the characteristics of users who used each operation plan that was actually operated, and includes age group information 73a and gender information 73b. Therefore, the number of times each plan was used by each age group and the number of times each plan was used by each gender can be ascertained from the user information 73.

[0097] <Processing procedure for generating operation plans> The processing procedure for generating an operation plan is shown in Fig. 9. That is, when generating an operation plan in step S11 shown in Fig. 2, the Web server 11 or the reservation management server 12 of the taxi cloud service 10 executes the processing shown in Fig. 9. The processing in Fig. 9 will be described below.

[0098] The taxi cloud service 10 cooperates with the record management service 10B to acquire operation record information (see FIG. 8) stored in the operation record DB 17 (S41). Then, from a large amount of acquired operation record information, an operation plan for a route with a relatively large number of uses or frequency of use is extracted (S42).

[0099] That is, since the operation record information 71 managed by the record management service 10B includes route information 71a and number of uses information 71c as shown in Fig. 8, it is possible to extract the starting point and destination of a route with a relatively large number of uses or frequency of use by comparing the number of uses information 71c with, for example, a predetermined threshold value. In other words, destinations that are actually popular with taxi users can be identified as past records in S42.

[0100] In this embodiment, the taxi cloud service 10 can also generate an operation plan based on a request from the user (passenger) user terminal 30. When accepting a user request and executing the process of Fig. 9, the taxi cloud service 10 proceeds to the process from S43 to S44. Otherwise, the taxi cloud service 10 proceeds to the process from S43 to S46.

[0101] When a request from a user is accepted, the taxi cloud service 10 acquires information on the departure point and destination designated by the user (S44), and generates a new operation plan using the operation record information (S45). The operation plan generated here is a route connecting the designated departure point and destination, and other conditions, such as departure time, are determined according to the same or close times as those in the operation record information that is frequently used, or according to the conditions desired by the user.

[0102] On the other hand, when generating an operation plan based on something other than a request from a user, the operation plan can be generated by giving priority to the generation conditions (specific departure point, destination, restrictions on departure time, etc.) that each operator, such as a taxi company, has determined in advance.

[0103] If there are generation conditions specified by the taxi company to which the operation plan to be generated is provided, the taxi cloud service 10 proceeds to processing from S46 to S47 and reflects the generation conditions specified by the taxi company in the conditions of the new plan.

[0104] In addition, the taxi cloud service 10 reflects the results extracted in S42, i.e., the route of the existing operation plan with a large number of trips, in the route of the new plan (S48). However, if there are generation conditions for the route specified by the taxi company, the change is limited to the allowable range of the generation conditions. Alternatively, the taxi company can manually adjust the route.

[0105] In addition, the taxi cloud service 10 reflects the track record extracted in S42, i.e., the time period information 71b of the existing operation plan with a large number of trips, in the departure time of the new plan (S49). However, if there are generation conditions for the time period specified by the taxi company, the change is limited to within the allowable range of the generation conditions. Alternatively, the taxi company can manually adjust it.

[0106] The taxi cloud service 10 obtains permission (checks whether operation is possible) from each taxi company that is scheduled to provide operation services for the new plan created in S45 or S47 to S49 (S50). Then, it finalizes the contents of the new plan for which permission has been obtained (confirmation that operation is possible), and starts management of this operation plan on the Web server 11 and the reservation management server 12 so that users (passengers) can view and reserve it (S51).

[0107] In addition, when the reservation status of the user (passenger) satisfies a predetermined condition determined for each operation plan, the reservation management server 12 of the taxi cloud service 10 proceeds to the process from S52 to S53. Then, a dispatch request C1 is transmitted to a taxi company that provides the operation service of the corresponding operation plan (S53).

[0108] <Details of operation plan generation> A specific example of detailed processing in generating an operation plan is shown in Fig. 10. That is, when the taxi cloud service 10 executes the operation plan generation shown in Fig. 9, by further adding the processing shown in Fig. 10, it becomes possible to generate an operation plan under more optimized conditions in terms of potential demand and convenience of users. The processing shown in Fig. 10 will be explained below.

[0109] The taxi cloud service 10 can obtain information indicating various attributes related to the boarding and alighting points (starting point, destination) of the generated new plan from the boarding and alighting point information 72 shown in Fig. 8. For example, when cooperation with other transportation facilities is important at the boarding and alighting point, such as when the starting point or the destination is close to a station or an airport, the necessity of cooperation can be determined from the contents of the transportation facility cooperation information 72a included in the boarding and alighting point information 72.

[0110] Therefore, if the departure point or destination in the new plan is close to a station or an airport, the taxi cloud service 10 determines in S61 that collaboration is necessary based on the transportation facility collaboration information 72a and proceeds to the process of S62. Then, the departure time and arrival time of the new plan are automatically corrected so that the waiting time of the user (passenger) at the station or airport is appropriate according to the scheduled departure and arrival times of the linked train or plane. This makes it possible to provide an operation plan that is convenient for connecting transportation facilities.

[0111] On the other hand, for example, information such as the opening of a new store popular with users or the opening of a new theme park can be known from the new establishment information 72b of the boarding and alighting point information 72. Therefore, the taxi cloud service 10 refers to the new establishment information 72b in S63 to identify whether a new facility has opened, and if it has opened within one month, for example, proceeds to the processing of S64. Then, the frequency of generating new plans that have the newly opened facility (store, etc.) as a destination or an existing boarding and alighting point close to the newly opened facility as a destination is increased.

[0112] In other words, even if the operation plan to which the relevant route is assigned has a low usage history, the opening of a new store or theme park is likely to increase new demand for operations for at least a certain period of time, so the taxi cloud service 10 generates an operation plan for the relevant route as a priority.

[0113] On the other hand, whether or not a boarding / alighting point corresponds to a facility where some event may be held repeatedly, such as a castle, a park, a museum, an art gallery, or a stadium, can be known from facility information 72c of boarding / alighting point information 72. In addition, an annual event schedule for the facility is stored as event schedule information 72e.

[0114] Therefore, the taxi cloud service 10 refers to the contents of the facility information 72c and the event schedule information 72e in S65, and identifies whether or not an event is scheduled to be held at the boarding / alighting point. If an event is scheduled to be held, the taxi cloud service 10 increases the frequency of generating operation plans that assign the corresponding boarding / alighting point to a destination according to the event period (S66).

[0115] On the other hand, whether or not the boarding and alighting points are barrier-free facilities can be known from the barrier-free information 72d. Therefore, when the taxi cloud service 10 generates a new plan in response to a user request, if the user specifies the departure point and "barrier-free," the taxi cloud service 10 proceeds to the process from S67 to S68. Then, it is known from the barrier-free information 72d for each boarding and alighting point whether the conditions are met, and a travel plan is generated with the barrier-free boarding and alighting point as the destination.

[0116] On the other hand, the actual performance of users who have used each operation plan can be understood by age group using the age group information 73a of the user information 73. Therefore, for example, it is possible to distinguish between operation plans that are popular with elderly people and operation plans that are popular with young people.

[0117] Therefore, when the taxi cloud service 10 generates a new plan in response to a user request, if the user specifies the departure point, his / her age group, and / or gender, the taxi cloud service 10 proceeds to the process from S69 to S70 and generates a travel plan with destinations that are popular among the same age group as the user's specification.

[0118] In addition, the taxi cloud service 10 processes the utilization rate of the created plan so as to reflect it in the creation of future plans.

[0119] As described above, in the taxi reservation support system 100 according to the embodiment of the present invention, when the taxi cloud service 10 generates a new operation plan, it acquires performance information reflecting the results of actual operation from the performance management service 10B (S41). Furthermore, performance information of operation plans that are used frequently or frequently is extracted (S42) and used to create a new operation plan (S48). Therefore, it is possible to provide preferentially operation plans for operation routes that are actually in high demand or popular operation routes.

[0120] In addition, when the taxi cloud service 10 generates a new operation plan, it determines the departure time using the time period information for each route contained in the performance information (this can also be adjusted at the taxi company's discretion) (S49), so that it can generate operation plans with priority given to operations during time periods that tend to be convenient for the taxi company or many users.

[0121] In addition, the taxi cloud service 10 receives constraint information from the taxi company that limits the conditions for generating the plan (S46), and generates a new operation plan that reflects this constraint information (S47). Therefore, it is possible to provide an operation plan that is convenient for the taxi company. For example, it is possible to generate an operation plan that is useful for improving the utilization rate and increasing sales by taking into account the expected operating status of taxi vehicles and drivers.

[0122] Furthermore, the taxi cloud service 10 can receive requests from taxi users (S43) and generate a new operation plan for a route between a designated departure point and destination (S44, S45). Therefore, even if an operation plan for a route desired by a taxi user is not prepared in advance, an operation plan for a route that meets the user's desired conditions can be provided as necessary.

[0123] In the above description, the reservation management server 12 generates an operation plan with a fixed starting point and destination, but the starting point and destination of the operation plan may be specified by area. In this case, the reservation management server 12 allows the user terminal 30 to input the desired boarding point and disembarking point within the area. In addition, when a vehicle dispatch request is made, information specifying the order in which passengers are to board or disembark within the area may also be provided to the operator terminal 20. Specifying the starting point and destination of the operation plan by area can increase the possibility of the operation being established.

[0124] Here, the features of the taxi reservation support system according to the embodiment of the present invention described above will be briefly summarized and listed in the following [1] to [5]. [1] A taxi reservation support system (100) that supports a reservation procedure for the use of an operating taxi between one or more taxi operators capable of operating a taxi vehicle and any user who wishes to ride in the taxi vehicle, comprising: a first communication unit (S13, S15) for communicating with a service provider terminal (service provider terminal 20) used by the service provider, a second communication unit (S17, S19) for communicating with a user terminal (30) used by the user, and servers (Web server 11, reservation management server 12) capable of providing communication services to the service provider terminal and the user terminal, respectively; The server, A route information storage function (performance management service 10B) that collects and stores performance information of a route including at least a departure point and a destination from a plurality of operators; A plan generation function (S11, S42 to S49) that preferentially extracts information on a specific route that is used frequently or at least frequently based on the information on the route stored by the route information storage function, and generates an operation plan including at least a departure point and a destination using the specific route that is extracted; A taxi reservation support system having the above.

[0125] [2] The route information accumulation function further accumulates time period information (71b) representing the results of the time period during which the route was operated as information on the operating route, The plan generation function reflects the time zone information stored by the route information storage function in the departure time of the operation plan to be generated (S49). The taxi reservation support system described in [1] above.

[0126] [3] The server further includes a restriction information acquisition unit (S46) that acquires restriction information restricting at least one of a departure time zone, a departure point, and a destination from each of the operators; The plan generation function generates an operation plan for each operator by reflecting the constraint information acquired by the constraint information acquisition unit (S47). A taxi reservation support system according to the above [1] or [2].

[0127] [4] The server further includes a user request receiving unit (S43) that receives a plan request from the user terminal including at least information on a departure point and a destination, The plan generation function generates an operation plan for a route that satisfies the conditions of the departure point and destination of the plan request received by the user request receiving unit (S44, S45); A taxi reservation support system according to any one of [1] to [3] above.

[0128] [5] A taxi reservation support system that supports a reservation procedure for the use of an operating taxi between one or more taxi operators capable of operating a taxi vehicle and any user who wishes to ride in the taxi vehicle, comprising: a reservation management server (12) including a first communication unit for communicating with a service provider terminal used by the service provider and a second communication unit for communicating with a user terminal used by the user, the reservation management server being capable of providing communication services to the service provider terminal and the user terminal, respectively; and a performance management server (16) that collects and accumulates performance information of a route including at least a starting point and a destination from a plurality of operators. The reservation management server has a plan generation function (S11, S41 to S49) of preferentially extracting information on a specific operation route that is used at least frequently based on the information on the operation route accumulated by the result management server, and generating an operation plan including at least a departure point and a destination using the extracted specific operation route. Taxi reservation support system. [Explanation of symbols]

[0129] 10. Taxi Cloud Service 10B Performance Management Service 11 Web Server 12 Reservation Management Server 13 Operation plan DB 15 Web Server 16 Results Management Server 17 Operation record DB 20, 20-1, 20-2, 20-3 Operator terminal 21 Internet 22, 22-1, 22-2 Wireless base station 30, 30-1, 30-2, 30-3 User terminal 40, 40-1, 40-2, 40-3 Taximeter on-board unit 41 Control section 41a Cloud integration function 41b Reservation status confirmation function 41c Operation information display function 41d Passenger authentication function 42 Wireless Communication Section 43 Display 44 Control section 50,51 Data Center 61 Representative Image 62 Plan Name Information 63 Pricing Information 64 Origin / Destination Information 65 Schedule Information 66 Recruitment Conditions Information 71 Operational performance information 71a Route Information 71b Time zone information 71c Usage information 72 Boarding and alighting information 72a Transport linkage information 72b New information 72c Facility Information 72d Barrier-free information 72e Event Schedule Information 73 User information 73a Age Group Information 73b Gender information 100 Taxi reservation support system C1 Plan Ride Request C2 Confirmation of reservation P1, P2 Operation Plan

Claims

1. A taxi reservation support system that supports a reservation procedure for use of an operating taxi between one or more taxi operators capable of operating a taxi vehicle and any user who wishes to ride in the taxi vehicle, comprising: a first communication unit for communicating with a company terminal used by the operator, a second communication unit for communicating with a user terminal used by the user, and a server capable of providing communication services to the company terminal and the user terminal, The server, A route information storage function that collects and stores performance information of a large number of users regarding a route including at least a departure point and a destination from a plurality of operators; A plan generation function that preferentially extracts information on a specific operation route that is used at least frequently based on the information on the operation route accumulated by the route information accumulation function, and generates an operation plan including at least a departure point and a destination using the extracted specific operation route; a service provider plan selection function that presents the contents of the plurality of operation plans to the service provider terminal and selects one or more of the plurality of operation plans as a service provider selected plan in response to an instruction from the service provider terminal; a user application receiving function for presenting the content of the selected trader-selected plan to the user terminal and specifying the plan selected in response to an instruction from the user terminal as a user-applied plan; A vehicle dispatch request function that determines the taxi operation of each plan according to the application status of the user-applied plan, transmits a vehicle dispatch request according to the corresponding plan to the operator of the confirmed plan, and transmits a reservation confirmation notification to the user terminal of the user who applied for the confirmed plan; A taxi reservation support system having the above.

2. The route information accumulation function further accumulates time period information representing the results of the time period during which the route was operated, as the information on the operation route, The plan generation function reflects the time zone information stored by the route information storage function in the departure time of the operation plan to be generated. The taxi reservation support system according to claim 1.

3. The server further includes a restriction information acquisition unit that acquires restriction information that restricts at least one of a departure time period, a departure point, and a destination from each of the operators; The plan generation function generates an operation plan for each operator by reflecting the constraint information acquired by the constraint information acquisition unit.

3. A taxi reservation support system according to claim 1 or 2.

4. The server further includes a user request receiving unit that receives a plan request from the user terminal including at least information on a departure point and a destination, The plan generation function generates an operation plan for a route that satisfies the conditions of the departure point and destination of the plan request received by the user request receiving unit. The taxi reservation support system according to any one of claims 1 to 3.

5. A taxi reservation support system that supports a reservation procedure for use of an operating taxi between one or more taxi operators capable of operating a taxi vehicle and any user who wishes to ride in the taxi vehicle, comprising: a reservation management server including a first communication unit for communicating with a service provider terminal used by the service provider and a second communication unit for communicating with a user terminal used by the user, the reservation management server being capable of providing communication services to the service provider terminal and the user terminal, respectively; A performance management server that collects and accumulates performance information of a large number of users regarding a route including at least a starting point and a destination from a plurality of operators, The reservation management server, A plan generation function that preferentially extracts information on a specific operation route that is used at least frequently based on the information on the operation route accumulated by the record management server, and generates an operation plan including at least a departure point and a destination using the extracted specific operation route; a service provider plan selection function that presents the contents of the plurality of operation plans to the service provider terminal and selects one or more of the plurality of operation plans as a service provider selected plan in response to an instruction from the service provider terminal; a user application receiving function for presenting the content of the selected trader-selected plan to the user terminal and specifying the plan selected in response to an instruction from the user terminal as a user-applied plan; A vehicle dispatch request function that determines the taxi operation of each plan according to the application status of the user-applied plan, transmits a vehicle dispatch request according to the corresponding plan to the operator of the confirmed plan, and transmits a reservation confirmation notification to the user terminal of the user who applied for the confirmed plan; A taxi reservation support system having the above.

Images