Taxi reservation support system
The taxi reservation support system addresses the mismatch between taxi supply and demand by facilitating shared services and dynamic pricing, improving vehicle utilization and customer satisfaction.
Patent Information
- Application Number
- JP2020177664
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2020-10-22
- Publication Date
- 2024-12-17
- Estimated Expiration
- 2040-10-22
AI Technical Summary
There is a mismatch between the supply and demand for taxi services, leading to underutilization of taxi vehicles and high fares, which deters potential users, while taxi companies face challenges such as labor costs, resource scarcity, and declining revenues.
A taxi reservation support system that includes a server generating operation plans, allowing operators and users to select and apply for shared taxi services, with mediation and solicitation functions to adjust demand and supply, and dynamic pricing based on user applications.
The system effectively matches taxi supply with demand, increasing the utilization of taxi vehicles and reducing fares, thereby enhancing customer service and revenue for taxi companies.
Smart Images

Figure 0007601597000001 
Figure 0007601597000002 
Figure 0007601597000003
Abstract
Description
[Technical Field]
[0001] The present invention relates to a taxi reservation support system, and more particularly to a technology for supporting the provision of new ways to use 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 acceptance means for accepting car sharing reservations from a user's mobile communication terminal via a communication network, and a communication means for sending a message to the mobile communication terminal suggesting that the user use a taxi, ride-sharing car, or shared bicycle that the user is expected to use to travel to the location of the reserved shared car or from the return location of the shared car, along 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. A server supports the provision of a service in which the price for a flat-rate taxi to travel within a specified area with a user is constant for the same user. A request receiving unit receives requests for the use of a flat-rate taxi from multiple users (requests include advance reservations and requests for immediate boarding). A 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. [Prior art documents] [Patent documents]
[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-144654 [Patent Document 2] Japanese Patent Publication No. 2020-46884 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 elderly people surrender their driver's licenses, they need alternative means of transportation to replace their personal cars. Also, as young people move away from cars, some people who do not own their own cars need some kind of transportation that they can use easily. Furthermore, 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. Furthermore, tourists visiting a particular area need a more convenient means of transportation within that area other than the current taxis, buses, and trains.
[0006] On the other hand, taxi companies and other operators of taxis are facing various challenges, such as rising labor costs, securing personnel, stricter regulations, and declining operating revenues year by year. For this reason, they want to increase the ratio of taxis that are actually in operation with passengers on board, thereby increasing sales.
[0007] However, in reality, many taxis are parked in front of train stations and waiting in large numbers, or are driving around looking for customers. In other words, despite the large potential demand for transportation such as taxis as described above, the number of people actually using taxis is relatively small. The reason for this is thought to be a lack of matching between the service content of taxi companies that provide transportation and the supply and demand relationship between potential users who need transportation such as taxis. For example, even if potential users want to use a taxi, they are likely to give up on using it because the fare is too high.
[0008] Therefore, if a car sharing system 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.
[0009] The present invention has been made in consideration of the above-mentioned circumstances, and its purpose is to provide a taxi reservation support system that can be used to facilitate matching of supply and demand between taxi companies and potential taxi users, and to increase the ratio of taxis that are in actual use. [Means for solving the problem]
[0010] In order to achieve the above-mentioned object, the taxi reservation support system according to the present invention has the following features (1) to (8). (1) A taxi reservation support system that supports the 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 a taxi vehicle, 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, respectively; The server A plan generation function that generates multiple operation plans including departure points and destination points; 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 acceptance function that presents the content of the selected provider-selected plan to the user terminal and identifies the selected plan as a user-applied plan in response to an instruction from the user terminal; A taxi operation for each plan is determined according to the application status of the user-applied plan, and a dispatch request according to the corresponding plan is sent to the operator of the determined plan. At the same time, a notification of the confirmed reservation is sent to the user terminal of the user who applied for the confirmed plan. A dispatch request function, A taxi reservation support system with
[0011] (2) The dispatch request function identifies whether each plan is feasible by comparing the number of people recruited for each plan with the number of users who applied for the corresponding plan and / or the number of user applications. The taxi reservation support system described in (1) above.
[0012] (3) The vehicle dispatch request function includes a mediation function that performs mediation processing for a user who applied for a specific plan identified as unsuccessful to apply for a similar plan whose content is similar to the specific plan. The taxi reservation support system described in (2) above.
[0013] (4) The mediation function automatically selects, as the similar plan, another plan whose departure point and / or destination is within a specific area common to the specific plan. The taxi reservation support system described in (3) above.
[0014] (5) The dispatch request function includes a solicitation function that, if the number of users applying for each plan or the number of user applications is insufficient compared to the number of users designated for each plan, solicits users who have applied for the corresponding plan to apply for additional applications. The taxi reservation support system described in (2) above.
[0015] (6) The plan generation function sets at least one of the departure point and the destination as an area, The user application acceptance function can accept from the user a desired boarding location and a desired disembarking location within the area. The taxi reservation support system described in (1) above.
[0016] (7) The plan generation function includes the number of user applications and / or the fare per person for each user application in the operation plan, The dispatch request function determines the fare according to the number of users who applied or the number of user applications at the time the operation plan was determined, The taxi reservation support system described in (1) above.
[0017] (8) 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, A company terminal used by the operator; a user terminal used by the user; a server capable of providing communication services to the provider terminal and the user terminal, The server includes a first communication unit for communicating with the provider terminal; a second communication unit for communicating with the user terminal; A plan generation function that generates multiple operation plans including departure points and destination points; 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 acceptance function that presents the content of the selected provider-selected plan to the user terminal and identifies the selected plan as a user-applied plan in response to an instruction from the user terminal; A taxi operation for each plan is determined according to the application status of the user-applied plan, and a dispatch request according to the corresponding plan is sent to the operator of the determined plan. At the same time, a notification of the confirmed reservation is sent to the user terminal of the user who applied for the confirmed plan. A dispatch request function, A taxi reservation support system with
[0018] According to the taxi reservation support system having the above configurations (1) and (8), a taxi operator providing a taxi service can select a service plan from among multiple service plans presented by the server depending on the situation. Meanwhile, a user who wishes to use a taxi service can browse the service plans available from the operator by connecting to the server using a user terminal. Furthermore, a user who finds a plan they wish to use can apply for the corresponding plan by sending specified information to the server. Depending on the user's actual application status for each plan, the server determines the taxi operation for each plan and sends a dispatch request to the operator. This makes it possible to match taxi operators providing taxi service with each user who wishes to use the service, thereby realizing each plan.
[0019] According to the taxi reservation support system configured as described in (2) above, the server can appropriately determine whether a plan is feasible based on the user application status for each plan. In other words, whether each plan will generate enough revenue to justify operating a taxi vehicle varies greatly depending on factors such as the number of users who actually ride, the number of applications, the price per person, and the price per application. Therefore, an appropriate judgment can be made by comparing the number of people recruited, the number of user applications, and the number of user applications. Therefore, for example, by comparing the upper and lower limits of the number of passengers for a plan with the number of user applications, it can be determined whether the number of user applications exceeds or is equal to the minimum number of people required for the plan to be operated (recruited).
[0020] According to the taxi reservation support system configured as described in (3) above, it is possible to prepare a similar plan for a user who applied for a specific plan that was not accepted. Since the similar plan has similar content to the specific plan applied for by the user, the user is likely to apply for this similar plan, making it easier to effectively adjust the matching of supply and demand for each plan.
[0021] According to the taxi reservation support system having the configuration described in (4) above, the similar plan selected has a departure point or destination within a specific area that is common to the specific plan, so users who applied for a specific plan that was not successful are likely to apply for the similar plan instead of the specific plan.
[0022] According to the taxi reservation support system configured as described in (5) above, if the user applies for additional applications in accordance with the solicitation function, it is possible to change a specific plan that may have been rejected into a successful plan. This makes it easier to effectively adjust the matching of supply and demand for each plan.
[0023] According to the taxi reservation support system having the above configuration (6), the possibility of the plan being established can be increased by specifying the starting point and destination of the operation plan by area.
[0024] According to the taxi reservation support system having the configuration described in (7) above, the user can know in advance the fare per person for each number of user applicants and / or number of user applications. Therefore, even if the number of user applicants and / or number of user applications decreases, the fare to be paid will be within the range known to the user in advance, reducing the possibility that the user will cancel their application. [Effects of the Invention]
[0025] The taxi reservation support system of the present invention facilitates matching of supply and demand between taxi companies and potential taxi users, thereby making it possible to increase the ratio of taxis that are in actual service.
[0026] The present invention has been briefly described above. The details of the present invention will become clearer by reading the following detailed description of the invention (hereinafter referred to as "embodiments") with reference to the accompanying drawings. [Brief explanation of the drawings]
[0027] [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. [Figure 2] FIG. 2 is a sequence diagram showing an example of the main operations of the taxi reservation support system. [Figure 3] 3(a) and 3(b) are front views showing specific examples of the display of an operation plan. [Figure 4] FIG. 4 is a flowchart showing the procedure for reservation management in the taxi reservation support system. [Figure 5] FIG. 5 is a flowchart showing the procedure of the mediation process in the taxi reservation support system. [Figure 6] FIG. 6 is a block diagram showing an example of the configuration of an in-vehicle taximeter unit. [Figure 7] 7(a) and 7(b) are front views showing examples of screen displays of the taximeter in-vehicle unit. DETAILED DESCRIPTION OF THE INVENTION
[0028] Specific embodiments of the present invention will be described below with reference to the accompanying drawings.
[0029] <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.
[0030] The taxi cloud service 10, which is the core function of the taxi reservation support system 100, is located 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 perform the functions of the taxi cloud service 10.
[0031] The taxi cloud service 10 is composed of communication-enabled computer hardware, the operating system (OS) required to operate as a server, and application software that enables operations to provide the functions of this taxi cloud service.
[0032] Operators such as taxi companies that are capable of operating taxi vehicles can access the taxi cloud service 10 and use this service by using operator terminals 20-1, 20-2, 20-3, etc. that each company owns.
[0033] 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.
[0034] 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 that supports the reservation of the selected operation plan by any user who will be a taxi passenger.
[0035] 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 their own user terminal 30-1, 30-2, 30-3, etc., which is equipped with communication functions, and use this service.
[0036] 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, thereby accessing the taxi cloud service 10.
[0037] 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.
[0038] The taximeter on-board units 40-1, 40-2, 40-3, etc. are mounted on taxi vehicles managed by operators such as taxi companies. Each taximeter on-board unit 40-1, 40-2, 40-3, etc. has the functions necessary to use the taxi cloud service 10. That is, each taximeter on-board unit 40 has a wireless communication function, and can communicate with the taxi cloud service 10 at any time, allowing the use of the services provided by the taxi cloud service 10. This enables the taxi vehicles to be dispatched according to the schedule of the plan determined by the taxi cloud service 10, and to operate the service with each user who has made a reservation as a passenger. Note that the on-board devices 40-1, 40-2, etc. may not necessarily be taximeters; however, tablets or smartphones with equivalent functions can be used to provide and operate this service.
[0039] <Examples of main system operations> FIG. 2 is a sequence diagram showing an example of the 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 steps S11, S13, S15, S17, S19, and S20 shown in Fig. 2. Furthermore, 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 an operator terminal 20. Furthermore, any user who can use the taxi cloud service 10 can execute steps S16 and S18 in Fig. 2 by operating a user terminal 30.
[0040] 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 information that is automatically generated based on various demand forecasts using artificial intelligence (AI) and other technologies in the taxi cloud service 10, consideration of convenience, and the like, and it is not yet determined whether the operator will actually adopt them, and it is also not yet determined whether each plan will be realized. In addition, data on boarding and alighting locations recorded by the taxi meter onboard unit 40 may be collected in a database, and this data may be used when generating operation plans.
[0041] Each operation plan generated by the taxi cloud service 10 is registered and stored in the operation plan DB 13. As will be described in detail later, each operation plan includes information that indicates at least each location including the departure point and the destination, and information that indicates the operation schedule.
[0042] A person in charge of 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 operator terminal 20 to which it is connected (S13).
[0043] A person in charge of a taxi company or the like selects an appropriate operation plan that allows the company to provide operation services from among the many operation plan candidates presented by the taxi cloud service 10, taking into consideration, for example, the availability of in-house taxi vehicles by date and time, the availability of each driver, and the cost of operating a taxi vehicle. At this time, the person in charge of a taxi company or the like can manually adjust the date and time, minimum number of participants, etc., of the plan presented on 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] A user (passenger) can access the taxi cloud service 10 via the Internet 21 using dedicated application software (app) installed in the user terminal 30 or a general web browser. 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, for example, searches 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 taking into consideration the departure point, destination, time zone, travel budget, etc. 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.
[0048] 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).
[0049] When the taxi cloud service 10 starts accepting applications for operation plans, it performs "reservation management" (S20), for example, periodically, to manage each operation plan for which applications have been accepted from at least users. Then, for an operation plan for which operation implementation 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 address 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 address registered in advance. Details of "reservation management" will be described later.
[0050] <Example of operation plan> <Display example> 3(a) and 3(b) are front views showing specific examples of the display of operation plans P1 and P2, respectively.
[0051] For example, when a user operates the user terminal 30 to search for plan candidates in step S16 of Figure 2, the user can display and confirm information about one operation plan P1 as shown in Figure 3(a) or information about one operation plan P2 as shown in Figure 3(b) on the screen of the user terminal 30.
[0052] 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.
[0053] The representative image 61 is information such as a photo showing a typical view of the destination in the plan. The plan name information 62 is assigned a name that makes it easy for the user to understand the contents of the plan, such as the purpose or destination of the plan. The fare information 63 clearly indicates the travel fare per passenger or per application for the plan.
[0054] The departure / destination information 64 is information about the departure and destination locations, specifically, station names, store names, etc. 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).
[0055] 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, as shown in Figures 3(a) and 3(b), for example.
[0056] <Operation plan submission method> As an example, a long-term matching period is set (crowdfunding format) and applications are solicited. If there are not enough applications to meet a certain level, the taxi operator may stop operations because it may become unprofitable. However, if there is financial support from the national or local government in addition to fare revenue, and the actual fare does not fall below the fare approved by the government, it is possible to operate the service even if there are not enough applications. In the case of a long-term matching period, reservations for the plan will be accepted on a per-passenger basis or per-entry basis. In addition, one person may make multiple reservations by paying multiple fees. Furthermore, if the number of users who have applied does not meet the minimum number of applications when determining whether the operation plan is successful or not, the remaining number of applications may be allocated to users who have already applied. In such a recruitment method, the maximum fare per person should be clearly stated in the operation plan.
[0057] <Operation plan fees> A ride-sharing fee will be applied, assuming multiple people will be sharing 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 in which the unit price decreases as the upper limit on the number of people / number of units recruited increases.
[0058] <What to specify and specify in the operation plan> Location: starting point, destination, ending point, etc. Time: Estimated departure time, estimated arrival time at destination, time spent at destination, estimated time of departure, etc. Price: Fare per person / per unit Number of people / number of seats: Maximum, minimum, etc. Regarding the amount, the fare per person for each number of people who ultimately applied may be listed.
[0059] <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.
[0060] <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, which 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 of Fig. 2. The procedure in Fig. 4 will be described below.
[0061] 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 / units to be recruited (corresponding to the recruitment condition information 66) in that plan with the number of people / units actually accepted for application from the user (S21). If the number of people / units to be recruited 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 valid.
[0062] 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 / units with other similar operation plans. In other words, if the number of people / units applied by users who applied for the plan does not reach the lower limit of the number of people / units available, the reservation management server 12 mediates so that applicants of other similar plans can re-book to switch to the plan. Conversely, users who applied for the plan cannot apply for more than the upper limit of the number of people / units 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.
[0063] 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 successful.
[0064] If the number of applicants / number of shares is less than the lower limit of the number of applicants / number of shares 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 application shares.
[0065] After completing the solicitation process in S24, the reservation management server 12 again compares the lower limit of the number of people / units to be offered in the plan with the number of people / units actually accepted from users (S25). If the number of people / units to be offered is within the range of the number of people / units to be offered, the process proceeds from S25 to S28, and it is determined that the operation of the operation plan is successful.
[0066] 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.
[0067] The reservation management server 12 automatically determines whether to implement the operation plan even if the number of passengers who have applied / the number of shares is less than the number of passengers / 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 fares paid by passengers, or if other revenues are expected, the reservation management server 12 compares the total income with the cost of operation and takes into account various conditions to make a decision so that the operator will not incur a loss.
[0068] If the operation plan is to be implemented, the reservation management server 12 proceeds from S27 to S28 and determines that the operation of the operation plan is established.If the operation plan is not to be implemented, the reservation management server 12 proceeds from S27 to S29 and determines that the operation plan is not established.
[0069] When the reservation management server 12 determines in S28 that the operation of the operation plan is established, it transmits a plan dispatch request C1 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 for the reservation of the operation plan.
[0070] On the other hand, if it is determined in S29 that the operation plan will not be completed, 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 completed (not shown).
[0071] In addition to the reservation management shown in FIG. 4, the reservation management server 12 can also provide the following additional services.
[0072] (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 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 provide 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 that 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 add a section for posting any advertisements to the place where the information in (2) above is posted, and to provide a function that allows users to earn additional income by posting advertisements. (4) After a user who has made a reservation through the taxi cloud service 10 actually rides in a taxi according to the operation plan, it is possible to provide a function for the user to evaluate the taxi driver and other users, and a function for the user to post the 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 users to use commuter passes or coupon tickets as part of an operation plan that can be reserved by each user.
[0073] <Processing procedure for mediation> 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 center position.
[0076] The reservation management server 12 searches for operation plans from the numerous operation plans managed on 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 for operation plans whose destinations match or are similar to the area of the destination identified in S32 from among the numerous operation plans managed on the operation plan DB 13, and extracts all those that meet the conditions (S34).
[0078] The reservation management server 12 calculates the degree of similarity, which indicates the degree to which the schedule and time period of each flight plan extracted in either S33 or S34 are similar to the submitted plan in S31 (S35).
[0079] 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.
[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 / units of the user who has reserved that plan is insufficient or the application has ended, the reservation management server 12 mediates for the user to change the reservation from that plan to another similar plan, and attempts to adjust the number of applicants / units for each plan so that it is appropriate. Whether or not to actually change the reservation is up to each user's own judgment. This mediation processing function can also be applied when the plan searched for by the user is not found in S16 of FIG.
[0081] <Configuration example of taximeter on-board unit> Fig. 6 is a block diagram showing an example of the configuration of the taximeter on-board unit 40. The taximeter on-board unit 40 shown in Fig. 6 has the same functions as a taximeter installed in a normal taxi vehicle, and also has additional functions that enable the taxi operation service to be carried out according to a reserved operation plan using the taxi cloud service 10 described above.
[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 on-board device 40 can use various functions provided by the taxi cloud service 10.
[0084] The reservation status confirmation function 41b has a function to manage the reservation status and reservation number of each passenger for the operation plan that has been assigned to the taxi vehicle equipped with this on-board device through 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, and the taxi meter on-board device 40 can acquire this number and display it on the screen of the display 43.
[0085] The operation information display function 41c has the function of automatically displaying the reservation details for the operation plan assigned to the taxi vehicle equipped with this on-board 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 is 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 taxi driver picks up a passenger in the taxi according to the reservation details. For example, when 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, the passenger authentication function 41d cooperates with the taxi cloud service 10 via the cloud cooperation function 41a and authenticates the person who made the reservation.
[0087] <Example of on-board unit screen display> 7(a) and 7(b) are front views showing examples of screen displays of the taxi meter on-board unit 40. Note that displays such as those shown in Fig. 7(a) and 7(b) may also be displayed on a tablet terminal or smartphone installed 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.
[0088] 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 this on-board device are displayed, including the plan name indicating the destination, departure time, and number of passengers. By displaying the screen of Figure 7(a), passengers can also check the contents of the reserved plan.
[0089] When each passenger gets into a taxi, 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 to be used for input, etc. are displayed on the screen. By entering 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 Figures 7(a) and 7(b) may be displayed on the screen of a tablet terminal or smartphone installed in a taxi vehicle.
[0091] In the above description, the reservation management server 12 generates an operation plan with a set departure point and destination, but the departure point and destination of the operation plan may also be specified by area. In this case, the reservation management server 12 allows the user terminal 30 to input the desired boarding and disembarking points within the area. In addition, when a vehicle dispatch request is made, the reservation management server 12 may also provide the operator terminal 20 with information specifying the order in which passengers should board and disembark within the area. Specifying the departure point and destination of the operation plan by area increases the likelihood of the operation being successful.
[0092] As described above, the taxi reservation support system 100 according to the embodiment of the present invention allows operators such as taxi companies that can provide taxi operation services to use the taxi cloud service 10 on the operator terminal 20. In a situation where a surplus of taxi vehicles or drivers is expected based on the trend in the actual taxi vehicle occupancy rate, the taxi company can improve the occupancy rate of taxi vehicles and increase sales by providing operation services according to various operation plans presented by the taxi cloud service 10.
[0093] Various users who wish to use a taxi at a relatively low fare can also use the taxi cloud service 10 using their own user terminal 30. The operation plans presented to each user by the taxi cloud service 10 are basically operation services in which multiple passengers share the same vehicle, so the fare paid by each passenger is relatively low. Furthermore, each user can select a plan that is convenient for their purpose and situation from a variety of operation plans. Furthermore, each user can make a reservation in advance at a time appropriate to their schedule.
[0094] Therefore, for example, elderly people who have surrendered their driver's licenses, young people who do not own their own cars, and people raising children can use the operation plans of the Taxi Cloud Service 10 as a means of transportation that can be used easily on a daily basis. Also, tourists visiting the area can secure a low-cost, easy-to-use means of transportation by using the operation plans of the Taxi Cloud Service 10. This will make it easier to discover potential demand for taxis and adjust the balance between supply and demand regarding taxi operations.
[0095] 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 below in [1] to [8]. [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, The system comprises 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 a server (Web server 11 or reservation management server 12) capable of providing communication services to the service provider terminal and the user terminal, respectively; The server A plan generation function (S11) that generates a plurality of operation plans including a departure point and a destination point; a service provider plan selection function (S13, S15) 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 acceptance function (S17, S19) that presents the content of the selected provider-selected plan to the user terminal and identifies the selected plan as a user-applied plan in response to an instruction from the user terminal; A dispatch request function (S20) for determining taxi operation for each plan according to the application status of the user-applied plan and transmitting a dispatch request (C1) according to the corresponding plan to the operator of the determined plan; A taxi reservation support system with
[0096] [2] The vehicle dispatch request function identifies whether each plan is feasible by comparing the number of users recruited for each plan with the number of users who applied for the corresponding plan and / or the number of user applications (S21). The taxi reservation support system described in [1] above.
[0097] [3] The dispatch request function includes an intermediation function (S22) that performs an intermediation process for a user who applied for a specific plan identified as unsuccessful to apply for a similar plan whose content is similar to the specific plan. The taxi reservation support system described in [2] above.
[0098] [4] The mediation function automatically selects, as the similar plan, another plan whose departure point and / or destination is within a specific area common to the specific plan (S33 to S36). The taxi reservation support system described in [3] above.
[0099] [5] The dispatch request function includes a solicitation function (S23, S24) that, when the number of users applying for each plan or the number of user applications is insufficient compared to the number of users specified for each plan, performs a solicitation process to solicit users who have applied for the corresponding plan to apply for additional applications. The taxi reservation support system described in [2] above.
[0100] [6] The plan generation function sets at least one of the departure point and the destination as an area, The user application acceptance function can accept from the user a desired boarding location and a desired disembarking location within the area. The taxi reservation support system described in [1] above.
[0101] [7] The plan generation function includes the number of user applications and / or the fare per person for each user application in the operation plan, The dispatch request function determines the fare according to the number of users who applied or the number of user applications at the time the operation plan was determined, The taxi reservation support system described in [1] above.
[0102] [8] A taxi reservation support system (100) that supports a reservation procedure for using 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 company terminal (operator terminal 20) used by the operator; A user terminal (30) used by the user; a server (Web server 11 or reservation management server 12) capable of providing communication services to the provider terminal and the user terminal, The server includes a first communication unit (S13, S15) for communicating with the agent terminal (operator terminal 20); a second communication unit (S17, S19) for communicating with the user terminal (30); A plan generation function (S11) that generates a plurality of operation plans including a departure point and a destination point; a service provider plan selection function (S13, S15) 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 acceptance function (S17, S19) that presents the content of the selected provider-selected plan to the user terminal and identifies the selected plan as a user-applied plan in response to an instruction from the user terminal; A dispatch request function (S20) for determining taxi operation for each plan according to the application status of the user-applied plan and transmitting a dispatch request (C1) according to the corresponding plan to the operator of the determined plan; A taxi reservation support system with [Explanation of symbols]
[0103] 10. Taxi Cloud Service 11 Web Server 12 Reservation Management Server 13 Operation plan DB 20, 20-1, 20-2, 20-3 Operator terminal 21 Internet 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 Unit 41a Cloud integration function 41b Reservation status confirmation function 41c Operation information display function 41d Passenger authentication function 42 Radio Communication Department 43 Display 44 Control section 50 Data Centers 61 Representative image 62 Plan Name Information 63 Pricing Information 64 Origin / Destination Information 65 Schedule Information 66 Recruitment Conditions 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 plan generation function that generates multiple operation plans including a departure point and a destination point; 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 dispatch request function identifies whether each plan is feasible by comparing the number of people to be recruited determined for each plan with the number of users who applied for the corresponding plan and / or the number of user applications. The taxi reservation support system according to claim 1.
3. The dispatch request function includes a mediation function for performing a mediation process for a user who has applied for a specific plan identified as being unsuccessful to apply for a similar plan having contents similar to the specific plan, The taxi reservation support system according to claim 2.
4. The brokering function automatically selects, as the similar plan, another plan having at least one of a departure point and a destination in a specific area common to the specific plan. The taxi reservation support system according to claim 3.
5. The dispatch request function includes a solicitation function that, when the number of users applying for each plan or the number of user applications is insufficient compared to the number of people to be recruited determined for each plan, executes a solicitation process for users who applied for the corresponding plan to apply for additional applications; The taxi reservation support system according to claim 2.
6. The plan generation function sets at least one of the departure point and the destination as an area, The user application reception function allows a user to receive a desired boarding location and a desired disembarking location within the area. The taxi reservation support system according to claim 1.
7. The plan generation function includes the number of users applying and / or the fare per person for each user application in the operation plan, The dispatch request function determines the fare according to the number of users who applied or the number of users who applied at the time when the operation plan was determined, The taxi reservation support system according to claim 1.
8. 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 company terminal used by the operator; A user terminal used by the user; a server capable of providing communication services to the provider terminal and the user terminal, The server includes a first communication unit for communicating with the provider terminal; A second communication unit for communicating with the user terminal; A plan generation function that generates multiple operation plans including a departure point and a destination point; 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.
Citation Information
Patent Citations
Share-ride operation support system, and method therefor
JP2002150470A
Transportation demand and supply matching system and transportation demand and supply matching method
JP2018084855A
Management system, management method, and management program
JP2019144654A
Server device that assists in identifying combination between service provider and service user, and method and program performed on that server device
JP2019211896A
Demand forecast device for passenger vehicles, demand forecast method for passenger vehicles, and program
JP2020030726A
