JP7601598B2 - Taxi reservation support system - Google Patents

Description

The present invention relates to a taxi reservation support system, and in particular to technology for supporting the provision of new ways to use taxis.

With regard to 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 sharing car, together with a discounted fare for the sharing car.

Patent Document 2 also 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 the 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 classification set for each of the multiple users.

JP 2019-144654 A JP 2020-46884 A

There is a lot of potential demand for transportation, including taxis. For example, as elderly people give up their driver's licenses, they need an alternative means of transportation to replace their personal cars. As young people move away from cars, some people do not own their own cars and therefore need some form of transportation that they can use easily. Furthermore, people of child-rearing age who do not own a car 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.

On the other hand, taxi companies and other operators of taxis are faced with a variety of issues, including rising labor costs, securing personnel, strengthening regulations, and annually declining operating profits. For this reason, they would like to increase the proportion of taxis that are actually in operation with passengers on board, and increase sales.

However, in reality, taxis are often parked in large numbers in front of train stations and waiting in a queue, or they are often driving around looking for customers. In other words, despite the fact that there is a lot of potential demand for taxis and other means of transportation as described above, the number of people who actually use taxis is relatively low. The reason for this is thought to be that the service provided by taxi companies that provide transportation means is not well matched with the supply and demand relationship between potential users who need transportation means such as taxis. For example, potential users are likely to give up on using a taxi even if they want to because the fare is too high.

For this reason, if car sharing is used, as 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 the taxi companies or the convenience of potential users.

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 also necessary for these users to make reservations for the taxi service in advance.

For example, a company providing taxi operation services may create an operation plan in advance and solicit users. However, if the created plan significantly differs from the conditions desired by the user, the user will not apply for this operation plan, and there is a high possibility that the operation plan will not be realized.

The present invention was made in consideration of the above-mentioned circumstances, and its purpose 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, and to increase the ratio of taxis that are in actual service.

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,
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 operation of each route during a time period as the information of 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.

(3) The server further includes a restriction information acquisition unit that acquires restriction information that restricts at least one of a departure time slot, a departure point, and a destination from each of the vehicle 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.

(4) The server further includes a user request receiving unit that receives a plan request from the user terminal, the plan request 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.

(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;
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.

According to the taxi reservation support system configured as in (1) above, 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 multiple 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, taxi users are more likely to apply for the operation plans presented by the system, and the possibility of the operation plan being realized increases. Therefore, it is possible to easily match the supply and demand relationship between taxi companies and potential taxi users, and to improve the ratio of taxi vehicles in actual vehicle condition.

According to the taxi reservation support system configured as in (2) above, 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 specific time periods that are used frequently. In other words, operation plans for routes and time periods that are actually in high demand among taxi users are generated with priority, so that taxi users can be presented with operation plans that operate during times that are convenient for daily shopping or for traveling for sightseeing, for example.

The taxi reservation support system with the above configuration (3) makes it easy for taxi companies and other parties that actually provide taxi operation services to generate only operation plans that reflect their individual desires. For example, it is possible to restrict conditions to avoid time periods when each taxi company cannot afford to provide taxi vehicles and drivers, or to avoid departure points or destinations where dispatching takes a long time due to distance or other factors. As a result, each taxi company can specify conditions that are convenient for increasing the actual usage rate of taxi vehicles and increasing total sales for all time periods.

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.

The taxi reservation support system configured as in (5) above makes it easy to match supply and demand between taxi companies and potential taxi users, and improves the ratio of actual taxi vehicles. In addition, by providing the performance management server with a performance management function and the reservation management server with a reservation management function, the load on the entire system is distributed and efficient processing is facilitated, making it possible to handle large volumes of demand. Therefore, for example, the upper and lower limit numbers of passengers for a plan are compared with the number of users who have applied, and it is determined whether the number of applications from users exceeds or is the same as the minimum number of people required for the event to be held (recruited).

The taxi reservation support system of the present invention makes it easy to match supply and demand between taxi companies and potential taxi users, and can improve the ratio of taxi vehicles in actual operation. In other words, operation plans for routes that are in high demand among taxi users are generated preferentially based on operation records, so that operation plans for heading to specific popular destinations, for example, can be presented to taxi users.

The present invention has been briefly described above. The details of the present invention will become clearer by reading the following description of the embodiment of the invention (hereinafter referred to as "embodiment") with reference to the attached drawings.

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. FIG. 2 is a sequence diagram showing an example of a main operation of the taxi reservation support system. 3(a) and 3(b) are front views showing specific examples of displaying an operation plan. FIG. 4 is a flowchart showing the procedure of reservation management in the taxi reservation support system. FIG. 5 is a flowchart showing the procedure of the mediation process in the taxi reservation support system. FIG. 6 is a block diagram showing an example of the configuration of a taximeter in-vehicle unit. 7(a) and 7(b) are front views showing examples of screen displays of an in-vehicle taxi meter unit. FIG. 8 is a schematic diagram showing an example of the configuration of main performance information included in the operation performance DB. FIG. 9 is a flowchart showing the processing steps for generating an operation plan. FIG. 10 is a flowchart showing a specific example of detailed processing in generating an operation plan.

Specific embodiments of the present invention are described below with reference to the drawings.

<Example of overall system configuration>
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.

The taxi cloud service 10, which is the core of the functions of the taxi reservation support system 100, is located on a computer in a data center 50. In this embodiment, the functions of the taxi cloud service 10 are performed by a web server 11, a reservation management server 12, and an operation plan DB (database) 13 in the data center 50. In addition, a performance management service 10B for managing performance information related to actual taxi operations is located on the data center 51. In this embodiment, the functions of the performance management service 10B are performed by a web server 15, a performance management server 16, and an operation performance DB 17 in the data center 51.

The taxi cloud service 10 and performance management service 10B each consist of communication-enabled 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.

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

Each operator terminal 20-1, 20-2, 20-3, ... is a terminal equipped with communication functions, such as a general personal computer, and can connect to and communicate with the web server 11 or reservation management server 12 in the data center 50 via the Internet 21 using public communication lines. 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 performance management server 16 of the performance management service 10B can connect to each operator terminal 20-1, 20-2, 20-3, ... via the Internet 21 and collect necessary information.

By using the taxi cloud service 10, operators such as taxi companies can select a desired operation plan from among the operation plans prepared in advance by this service. In addition, they can receive a service that supports the reservation of the selected operation plan by any user who will be a taxi passenger.

As described below, 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 taxi operation performance information of each operator collected by the performance management service 10B.

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 a communication function, and can use this service.

Various types of terminals can be used as user terminals 30-1, 30-2, 30-3, etc., such as smartphones, mobile phone terminals, notebook computers, and desktop computers. When a user uses a portable user terminal 30, this user terminal 30 uses its wireless communication function to connect to one of the wireless base stations 22-1, 22-2, etc., and further connects to the web server 11 or reservation management server 12 in the data center 50 via the Internet 21, and can access the taxi cloud service 10.

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 explained later, whether or not each plan is actually realized may vary depending on the user's application status, etc.

The taximeter vehicle-mounted devices 40-1, 40-2, 40-3, ... 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, ... has the functions necessary to use 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 services provided by the taxi cloud service 10. This allows each taxi vehicle to be dispatched according to the schedule of the plan determined by the taxi cloud service 10, and a service can be realized in which each user who has made a reservation is on board as a passenger. Note that the vehicle-mounted devices 40-1, 40-2, ... do not have to be taximeters, but can be tablets or smartphones with equivalent functions to provide and operate this service.

<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.
The taxi cloud service 10 included in the taxi reservation support system 100 has the functions of each 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 each of 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 each of steps S16 and S18 in Fig. 2 by operating the user terminal 30.

On the other hand, the performance management service 10B collects performance information regarding the actual operation of taxi vehicles, for example, through communication with each terminal on a regular basis or through communication conducted collectively during a specific time period.

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 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 onboard unit 40 may be collected in a database, and this data may be used when generating operation plans.

In addition, each taxi company can specify in advance information that restricts the conditions for generating operation plans generated by the taxi cloud service 10, specifically restrictions on the departure point, destination, time period, etc. Alternatively, the date and time of the selected plan can be adjusted at the discretion of the taxi company staff.

Each operation plan generated by the taxi cloud service 10 is registered and stored in the operation plan DB 13. Details will be described later, but each operation plan includes information that represents at least each point including the departure point and destination, and information that represents the operation schedule, etc.

A person in charge at a taxi company or the like connects the 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).

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, taking into consideration, for example, the availability of the company's own taxi vehicles by date and time, the availability of each driver, and the cost of operating the taxi vehicles. At this time, the plan presented to the operator terminal 20 can be manually adjusted by the person in charge of the taxi company or the like, such as the date and time and the minimum number of participants. The operator terminal 20 then notifies the taxi cloud service 10 of information indicating the selected plan (S14).

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).

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 traveling performs a search for the desired operation plan on the user terminal 30 (S16).

In response to 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).

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 period, and travel budget of the user's 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.

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

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

When the taxi cloud service 10 starts accepting applications for operation plans, it performs "reservation management" for example periodically in order to manage each operation plan for which applications have been accepted from at least users (S20). Then, for an operation plan for which operation has been confirmed, it sends 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 sends 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.

<Examples of operation plans>
<Display example>
3A and 3B are front views showing specific examples of display of operation plans P1 and P2, respectively.

For example, when a user operates the user terminal 30 to search for plan candidates 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.

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 conditions information 66.

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 clearly indicates the operating fare per passenger for the corresponding plan, or the operating fare per application.

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 date of operation, departure time, arrival time, and duration at the destination (in the case of a round trip).

The recruitment condition information 66 is composed 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, as shown in Figures 3(a) and 3(b), for example.

<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 the number of users who have applied is less than the minimum number of units to be recruited at the time of judging whether the operation plan is successful or not, the shortage of units may be allocated to users who have already applied. In the case of such a recruitment method, the maximum fare per person is clearly stated in the operation plan.

<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/number of units recruited increases.

<What should be specified and clarified in the operation plan>
Location: departure point, destination, disbanding point, etc. Time: scheduled departure time, scheduled arrival time at destination, time spent at destination, scheduled disbanding time, etc. Amount: fare per person/per share Number of people/number of shares: maximum, minimum, etc. Regarding the amount, it is also possible to list the fare per person for each number of people who ultimately applied.

<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, and the plan can be finalized.

<Reservation management processing procedure>
Fig. 4 is a flowchart showing the procedure for 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.

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

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 users who applied for the plan does not reach the lower limit of the number of people/lots available, the applicants of the other similar plans are intermediated to make a new reservation to switch to the plan. Conversely, the number of people/lots applied by users who applied for the plan cannot exceed the upper limit of the number of people/lots available. If the upper limit has been reached, the user who attempted to apply for the plan is intermediated to another similar plan. A specific example of this intermediation process will be described later.

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 applicants/units actually accepted from users (S23). If the number of applicants/units 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.

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 step S24 to encourage users who have already applied for the operation plan to purchase additional units.

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 applicants/units actually accepted from users (S25). If the number of applicants/units 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.

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

The reservation management server 12 automatically identifies whether or not to implement the operation plan while the number of passengers who have applied/the number of shares is less than the number of people/the number of shares offered. For example, if an operator such as a taxi company can receive subsidies from the national or local government as income other than the fares paid by passengers, or if other revenues are expected, the reservation management server 12 compares the total income with the costs of operation and makes a decision taking into account various conditions so that the operator does not incur a loss.

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.

When the reservation management server 12 determines in S28 that the operation plan will be completed, 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 reservation confirmation notification C2 to the user terminal 30 of the user who applied to reserve the operation plan.

On the other hand, if it is determined in S29 that the operation plan will not be established, the reservation management server 12 notifies the taxi company that applied for the operation plan and the user who applied to reserve the operation plan that the operation plan will not be established (not shown).

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, it is possible to disclose to the user the attributes of other users who will be riding with them, such as age group and gender, 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 advertisement 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 posting 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 operation plans that can be reserved by each user.

<Processing procedure for mediation>
Fig. 5 is a flow chart 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.

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 point and destination areas for that operation plan (S32).

For example, the area may be an area corresponding to a place name or town name associated with a departure point or a destination point, or a range that is included within an area such as a circle centered on each point and within a specified distance from the center position.

The reservation management server 12 searches through the numerous operation plans managed in the operation plan DB 13 for operation plans 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).

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 destination area identified in S32, and extracts all that meet the conditions (S34).

The reservation management server 12 calculates the degree of similarity (S35) of each operation plan extracted in either S33 or S34 to the applied plan in S31 in terms of schedule and time period.

The reservation management server 12 outputs a list of the operation plans extracted in either S33 or S34, sorted in order of decreasing similarity calculated in S35 (S36). This list of operation plans is displayed on the screen of the user terminal 30.

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 the plan is insufficient or the application has ended, the reservation management server 12 mediates the user to change the reservation from the 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 is not found in S16 of FIG.

<Example of the configuration of a taximeter on-board unit>
Fig. 6 is a block diagram showing a configuration example of the taxi meter on-board unit 40. The taxi meter on-board unit 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.

The taximeter vehicle-mounted unit 40 shown in FIG. 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.

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 vehicle-mounted device 40 can use the various functions provided by the taxi cloud service 10. The cloud linking function 41a also provides performance information to the performance management service 10B.

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

The operation information display function 41c has a function to automatically display the reservation details for the operation plan assigned to the taxi vehicle equipped with this onboard device 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 location, disbanding location, time, destination, and number of passengers are displayed on the screen of the display 43.

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 links with the taxi cloud service 10 via the cloud linking function 41a to authenticate the person who made the reservation.

<Example of on-board device screen display>
7(a) and 7(b) are front views showing examples of screen displays of the taxi meter in-vehicle 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 onboard 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.

In the example of Figure 7(a), the contents of a specific operation plan that is scheduled to start in a few hours in a taxi vehicle equipped with the onboard device are displayed, including the plan name indicating the destination, the departure time, and the number of passengers. By displaying the screen of Figure 7(a), passengers can also check the contents of the reserved plan.

When each passenger gets into a taxi vehicle, the passenger authentication function 41d displays a screen like that shown in Figure 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 used for input, etc. are displayed on the screen. The identity of the passenger who made the reservation can be verified by inputting the reservation number, etc. using this numeric keypad.

Note that displays such as those shown in Figures 7(a) and 7(b) may also be displayed on a tablet terminal or smartphone installed inside a taxi vehicle.

<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 as performance information in the operation performance DB 17.

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 that indicates the departure point, destination, distance, and required time in each operation plan and daily business results actually performed by each operator such as a taxi company. The time period information 71b is record data that indicates the time period including the departure time and arrival time in each operation plan and daily business results actually performed by each operator such as a taxi company. The number of uses information 71c is record data that indicates the number of uses or frequency of use for each operation plan and daily business results actually performed by each operator such as a taxi company. The fare/charge information 71d is record data that indicates 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).

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

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

Facility information 72c holds information necessary to identify whether the destination is a location with a special facility, such as a castle, park, museum, art gallery, or stadium, and the type of facility. Barrier-free information 72d holds information necessary to identify whether the destination facility is barrier-free. Event schedule information 72e holds information that represents the annual event schedule (dates for each event) at the destination facility.

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 user information 73.

<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.

The taxi cloud service 10 cooperates with the performance management service 10B to acquire operation performance information (see FIG. 8) stored in the operation performance DB 17 (S41). Then, from the large amount of operation performance information acquired, an operation plan for a route that is used a relatively large number of times or is used frequently is extracted (S42).

In other words, the operation record information 71 managed by the record management service 10B includes route information 71a and usage count information 71c as shown in FIG. 8, so by comparing the usage count information 71c with, for example, a predetermined threshold, it is possible to extract the starting point and destination of a route with a relatively high usage count or frequency. In other words, destinations that are actually popular with taxi users can be identified as past records in S42.

In this embodiment, the taxi cloud service 10 can also generate an operation plan based on a request from the user terminal 30 of the user (passenger). 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. In other cases, the taxi cloud service 10 proceeds to the process from S43 to S46.

When a user request is accepted, the taxi cloud service 10 acquires information on the departure point and destination specified 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 specified 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 with the highest frequency of use, or according to the conditions desired by the user.

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

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.

The taxi cloud service 10 also reflects the track record 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 changes are limited to the allowable range of the generation conditions. Alternatively, the taxi company can make manual adjustments.

The taxi cloud service 10 also 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 specified by the taxi company for the time period, the changes are limited to within the allowable range of the generation conditions. Alternatively, the taxi company can make manual adjustments.

The taxi cloud service 10 obtains permission from each taxi company that is scheduled to provide the operation service of the new plan created in S45 or S47 to S49 (checks whether operation is possible) (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 reservation management server 12 so that users (passengers) can view and reserve it (S51).

When the reservation status of the user (passenger) meets the predetermined conditions 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, it transmits a dispatch request C1 to the taxi company that provides the operation service of the corresponding operation plan (S53).

<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 described below.

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, if cooperation with other transportation facilities is important at the boarding and alighting point, such as when the starting point or destination is close to a station or 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.

Therefore, if the departure point or destination in the new plan is close to a station or airport, the taxi cloud service 10 determines in S61 that collaboration is necessary based on the transportation collaboration information 72a and proceeds to processing in S62. The departure time and arrival time of the new plan are then automatically corrected to match the scheduled departure and arrival times of the linked train or plane so that the waiting time of users (passengers) at the station or airport is appropriate. This makes it possible to provide an operation plan that is convenient for connecting transportation modes.

On the other hand, information such as the opening of a new store that is 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 the last 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.

In other words, even if the operation plan to which the corresponding route is assigned has a low usage record, the taxi cloud service 10 generates the operation plan for the corresponding route with priority, since it is expected that new demand for operations will increase for at least a certain period of time due to the opening of a new store or theme park.

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

Therefore, in S65, the taxi cloud service 10 refers to the contents of the facility information 72c and the event schedule information 72e to identify 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 as a destination according to the event period (S66).

On the other hand, whether or not the boarding and alighting points are barrier-free facilities can be ascertained 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 processing from S67 to S68. Then, it ascertains from the barrier-free information 72d for each boarding and alighting point whether the conditions are met, and generates an operation plan with a barrier-free boarding and alighting point as the destination.

On the other hand, the actual usage of each operation plan by users can be understood by age group based on the age group information 73a in 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.

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 their own age group and gender, the taxi cloud service 10 proceeds to processing from S69 to S70. Then, it generates an operation plan with a destination that is a popular boarding and disembarking point for the same age group as specified by the user.

The taxi cloud service 10 also processes the utilization rate of the created plan so that it is reflected in the creation of future plans.

As described above, when the taxi cloud service 10 generates a new operation plan, the taxi reservation support system 100 according to the embodiment of the present invention obtains 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, operation plans for operation routes that are actually in high demand or popular operation routes can be provided preferentially.

In addition, when the taxi cloud service 10 generates a new operation plan, it uses the time zone information for each route included in the performance information to determine the departure time (this can also be adjusted at the taxi company's discretion) (S49), so it can generate operation plans with priority given to operating during times that tend to be convenient for the taxi company or many users.

The taxi cloud service 10 also accepts constraint information from taxi companies that restricts the conditions for generating the plan (S46), and generates a new operation plan that reflects this constraint information (S47). This allows for operation plans that are convenient for taxi companies to be provided. For example, operation plans that take into account the expected operating status of taxi vehicles and drivers can be generated to improve the utilization rate and increase sales.

The taxi cloud service 10 can also receive requests from taxi users (S43) and generate a new operation plan for a route between a specified 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 needed.

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

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,
a first communication unit (S13, S15) for communicating with a company terminal (operator terminal 20) used by the operator, 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 company 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 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 taxi reservation support system having the above.

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

[3] The server further includes a restriction information acquisition unit (S46) that acquires restriction information that restricts 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).
The taxi reservation support system according to the above [1] or [2].

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

[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 departure 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 operation route information 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.

10 Taxi cloud service 10B Performance management service 11 Web server 12 Reservation management server 13 Operation plan DB
15 Web server 16 Record 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 Taxi meter vehicle unit 41 Control unit 41a Cloud linking function 41b Reservation status confirmation function 41c Operation information display function 41d Passenger authentication function 42 Wireless communication unit 43 Display 44 Operation unit 50, 51 Data center 61 Representative image 62 Plan name information 63 Fare information 64 Departure/destination information 65 Schedule information 66 Recruitment conditions information 71 Operation record information 71a Route information 71b Time period information 71c Number of uses information 72 Boarding and alighting points information 72a Transport facility linking information 72b New establishment 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 dispatch request C2 Notification of reservation confirmation P1, P2 Operation plan

Claims (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 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. 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. 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. The taxi reservation support system according to claim 1 or 2. 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. 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;
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