JP7619199B2 - Shared taxi system - Google Patents

Description

This disclosure relates to a ride-sharing taxi system.

When using a taxi, if the departure point or destination is the same, there is a demand for sharing a taxi for a lower fare. In order to provide a shared taxi service, it is necessary to collect data on taxi users who have the same departure point or destination, match the data with the departure point or destination and boarding and alighting times, and calculate the driving route based on the obtained data.

Patent Document 1 discloses a taxi ride-sharing support system that uses a call center system that links customers and taxi companies to perform a matching search that matches the departure point, destination, and boarding reservation time from the received reservation information, and generates grouped data that groups the results obtained by the matching.

JP 2003-233656 A

One way to use a taxi is by renting it by the hour, where the fee is determined by the duration of use. Taking advantage of the ease of calculating the fee, hourly taxi rentals are sometimes used when mediating for ride-sharing taxis. However, when renting a taxi by the hour, the fee for renting the taxi increases once a certain time has elapsed even if a ride-sharing route has been created, so the fee cost can be high. The taxi ride-sharing support system in Patent Document 1 does not take into account the time conditions for hourly taxi rentals, nor does it consider whether a ride-sharing route satisfies certain conditions after it has been created.

The objective of the present disclosure is to provide a ride-sharing taxi system that, after creating a ride-sharing route, performs clustering again and creates a ride-sharing route again if certain conditions, such as the time conditions for hourly taxi rentals, are not met.

The ride-sharing taxi system according to the present disclosure includes a receiving unit that receives boarding and alighting request data of multiple users wishing to share a ride, a vehicle dispatching plan unit that generates a vehicle dispatching plan based on the boarding and alighting request data, and a transmitting unit that transmits the vehicle dispatching plan to a taxi company. The vehicle dispatching plan unit includes a clustering unit that performs clustering to group multiple boarding and alighting request data based on the similarity of the boarding information or alighting information contained in the boarding and alighting request data, assigns taxis to be dispatched one by one, and generates clusters so that the number of people riding in one taxi is equal to or less than a predetermined number, and a vehicle dispatching plan processing unit that creates a ride-sharing driving route for the cluster and generates a vehicle dispatching plan based on the driving route. The vehicle dispatching plan processing unit is characterized in that if the ride-sharing driving time for each cluster is equal to or longer than a certain time, it increases the number of taxis to be dispatched and performs clustering again.

The ride-sharing taxi system according to the present disclosure can create a ride-sharing route that satisfies specified conditions by increasing the number of taxis to be dispatched and performing clustering again when the ride-sharing travel time for each cluster is equal to or longer than a certain time.

1 is an overall configuration diagram of a ride-sharing taxi service provided using the ride-sharing taxi system of the present disclosure. 1 is an example of a hardware configuration of a ride-sharing taxi system according to the present disclosure. FIG. 1 is a functional block diagram of a ride-sharing taxi system according to an embodiment. A figure showing an example of the data structure of boarding and alighting request data received from a user terminal by the ride-sharing taxi system of an embodiment. A figure showing an example of the data structure of reservation confirmation data transmitted from the ride-sharing taxi system of the embodiment to a user terminal. FIG. 5 is a diagram showing a state in which a plurality of boarding and alighting request data in FIG. 4 are compiled. FIG. 7 is a diagram showing a state in which the boarding/alighting request data in FIG. 6 is grouped. FIG. 11 is a diagram explaining the process of clustering multiple grouped boarding and alighting request data, in which (a) is a diagram showing the boarding and alighting request data arranged on a map, (b) is a diagram showing vectors from the departure point to each boarding and alighting request data, and (c) is a diagram showing the state after clustering is completed. FIG. 13 is a diagram showing an example of a data structure of a carpooling route in which a driving route is added to a cluster. A figure showing an example of a data structure of a vehicle allocation plan in which user information is added to the carpooling route of Figure 9. FIG. 4 is a diagram illustrating an example of a data structure of fee calculation data. FIG. 13 is a diagram for explaining re-clustering. FIG. 2 is a diagram illustrating an example of a processing sequence of the ride-sharing taxi system of the embodiment. 11 is a flowchart illustrating an example of a process of a clustering unit of the embodiment. 11 is a flowchart illustrating an example of a process of a vehicle allocation planning processing unit of the embodiment. 11 is a flowchart illustrating an example of a process of a fee calculation processing unit of the embodiment. FIG. 11 is a diagram illustrating a clustering process according to another embodiment. FIG. 13 is a diagram illustrating re-clustering under synergistic conditions in another embodiment.

Embodiments of the present disclosure will be described in detail below with reference to the drawings. In the following description, specific shapes, materials, directions, values, etc. are merely examples to facilitate understanding of the present disclosure, and may be modified as appropriate according to the application, purpose, specifications, etc. In addition, it is anticipated from the beginning that the components of the embodiments and modified examples described below will be selectively combined.

[Definition]
In this disclosure, "clustering" refers to a technique for grouping data based on the similarity between the data, and a group of similar items created by clustering is called a "cluster."

[System configuration]
1 is an overall configuration diagram of a ride-sharing taxi service provided using the ride-sharing taxi system 10 of the present disclosure. The ride-sharing taxi system 10 receives boarding and alighting request data, which is requests for boarding location, boarding date and time, alighting location, alighting date and time, etc., from a user terminal 100 via a network 300, and transmits a dispatch plan, which also serves as taxi order information for ride-sharing, to a computer 200 installed at an external taxi company, thereby realizing the ride-sharing taxi service.

The user terminal 100 is a terminal through which a person wishing to use a ride-sharing taxi transmits ride-sharing request data to the ride-sharing taxi system 10. There are multiple user terminals 100 for each user, and for example, a mobile terminal 100A is connected to the network 300 via a mobile communication network. Alternatively, the user terminal 100 may be a computer 100B connected to the network 300.

The computer 200 is an external system that is installed in an external taxi company and transmits a dispatch plan from the ride-sharing taxi system 10. The configuration of the computer 200 is not limited in this disclosure.

[System hardware configuration]
FIG. 2 shows an example of a hardware configuration diagram of the ride-sharing taxi system 10. The ride-sharing taxi system 10 has a CPU (Central Processing Unit) 11, an input device 12, an output device 13, a storage device 14, and a communication device 15. The CPU 11 performs various calculations and controls each device. The input device 12 inputs data from the outside. The output device 13 outputs data to the outside. The storage device 14 stores programs and data, and stores data input from the outside. The communication device 15 transmits and receives data to and from an external system via a network 300. These devices are connected to each other by a bus 16 and exchange data. The devices shown in FIG. 2 work together to operate as the ride-sharing taxi system 10.

First Embodiment
3 shows a functional block diagram of the ride-sharing taxi system 10 of the first embodiment. The ride-sharing taxi system 10 has a vehicle dispatch planner 20, a receiver 24, and a transmitter 25. The receiver 24 is connected to a network 300 and receives boarding and alighting request data from a user terminal 100 of a user who wishes to share a ride. The transmitter 25 is connected to the network 300 and transmits a vehicle dispatch plan for sharing a ride to an external taxi company computer 200. The ride-sharing taxi system 10 may further include other functional blocks such as a memory unit 23 for storing various data generated by the vehicle dispatch planner 20 and data received by the receiver 24, a fare calculation processor 31, an information notification processor 32, and an order processor 33.

The vehicle allocation planning unit 20 generates a vehicle allocation plan based on the boarding and alighting request data. The vehicle allocation planning unit 20 has a clustering unit 21 and a vehicle allocation plan processing unit 22, and the vehicle allocation planning unit 20 performs specific processing using these.

The clustering unit 21 receives the boarding/alighting request data from the receiving unit 24. The clustering unit 21 groups a plurality of boarding/alighting request data based on the similarity of the boarding information or disembarking information contained in the boarding/alighting request data. Furthermore, the clustering unit 21 performs clustering to generate clusters such that the number of people riding in one taxi is equal to or less than a predetermined number. The clustering unit 21 performs clustering on each of the grouped groups.

The dispatch plan processing unit 22 generates a dispatch plan for each cluster generated by the clustering unit 21. The dispatch plan processing unit 22 creates a carpooling route representing the carpooling route based on the boarding and alighting request data included in the cluster. If the values calculated based on the created carpooling route contain data that does not satisfy predetermined conditions, it determines that the cluster is unsuitable for carpooling, increases the number of taxis to be dispatched, i.e., increases the total number of clusters in the group, and performs clustering again.

The receiving unit 24 is connected to the network 300 and receives data from the outside. In this embodiment, the receiving unit 24 receives boarding and alighting request data from the user terminal 100. The receiving unit 24 also receives a reply to the dispatch order from the taxi company's computer 200. When the receiving unit 24 receives data from the outside, it stores the data in the memory unit 23.

The transmission unit 25 transmits the dispatch plan to the taxi company's computer 200. It also transmits reservation confirmation data in response to boarding and alighting request data received from the user terminal.

The fare calculation processing unit 31 calculates the fare for each ride-sharing user based on the dispatch plan. In this embodiment, the fare calculation processing unit 31 is also configured to process changes and cancellations to the ride-sharing boarding and alighting request data.

The information notification processing unit 32 transmits reservation confirmation data when a ride-sharing reservation is accepted and when a change is accepted to the user terminal 100 via the transmission unit 25, and transmits a response and a cancellation fee if the boarding/alighting request data is canceled.

The order processing unit 33 transmits the dispatch plan to the taxi company's computer 200 via the transmission unit 25.

[About data structure]
4 to 11, a series of processes for grouping and clustering boarding and alighting request data to generate a ride-sharing route and a ride-sharing plan will be described while showing the data structure generated in the process of generating a ride-sharing dispatch plan by the ride-sharing taxi system 10. In this disclosure, the data structure will be shown by a table with items listed vertically and data contents listed horizontally. A vertical column represents one set of data, and when there are multiple different data, they are displayed consecutively horizontally.

[Boarding and alighting request data]
FIG. 4 shows the structure of the boarding/alighting request data 121 received from the user terminal 100. The items of the boarding/alighting request data 121 are vertically composed of a reservation acceptance number, (reservation) type, boarding location, boarding date and time, alighting location, alighting date and time, desired time, desired fare, synergy conditions 1 and 2, etc. The reservation acceptance number is a number assigned when the ride-sharing taxi system 10 accepts the boarding/alighting request data 121, and has the meaning of an identification number that distinguishes it from other data. The boarding/alighting request data 121 includes new data 121a and 121b shown in FIG. 4(a) and (b), change data 121c shown in FIG. 4(c), and cancellation data 121d shown in FIG. 4(d). The change data 121c and the cancellation data 121d have character data of change and cancellation inputted in the type field, respectively. The previous reservation acceptance number is inputted in the type field of the change data 121c and the cancellation data 121d.

As shown in Figures 4(a) and (b), in the case of new data 121a and 121b, the reservation acceptance number is undecided. The items from the boarding location to the disembarking date and time are items used when creating a ride-sharing route. The desired time, desired fare, and synergy conditions 1 and 2 are not required conditions. For example, examples of synergy conditions include conditions regarding the gender and number of passengers sharing the ride. Other conditions include restrictions on the ride-sharing time and fees. Not all of these items are necessarily required, and can be adjusted depending on the content of the ride-sharing taxi service provided. The use of synergy conditions will be described later.

Comparing the data content of data 121a in FIG. 4(a) with the data content of data 121b in FIG. 4(b), it can be seen that the boarding location and disembarking location have been swapped. The boarding date and time and the disembarking date and time are different. This is because data 121a is boarding/disembarking request data 121 when the user is going from address A to address X, and data 121b is boarding/disembarking request data 121 when the user is returning from address X to address A.

The ride-sharing taxi system 10 transmits reservation confirmation data to the user terminal 100 to confirm the reservation acceptance status (acceptance status of boarding and alighting request data). FIG. 5 shows an example of the data structure of reservation confirmation data 122 transmitted to the user terminal 100. The user can check the reservation confirmation data on the user terminal 100 to confirm the status of the ride-sharing reservation.

The items in the reservation confirmation data 122 are, vertically, the reservation acceptance number, boarding location, boarding date and time, disembarking location, disembarking date and time, number of passengers, fare, taxi information, and route information. Items from the reservation acceptance number to the disembarking date and time are the same as those in the boarding and disembarking request data 121. The number of passengers is the number of passengers including the person sharing the ride. The fare is the usage fee for the ride, and the taxi information is the name of the taxi company that will be dispatched. The route information is information that indicates the ride-sharing route, and on the user terminal 100, it is a link to a map screen. The link to the route information opens a map app, and the actual ride-sharing route is displayed on the map. Note that the format of the route information is one example, and other formats are also possible.

Figure 6 shows a state where multiple boarding and alighting request data 121 are stored in the ride-sharing taxi system 10. Basically, it is the same as a single boarding and alighting request data 121, but user information is added to the boarding and alighting request data 121. The user information may be divided into multiple items such as the user's name, age, sex, and registration ID number in the system. The reason for adding user information is that when creating a ride-sharing route, information on boarding and alighting passengers is required. As will be described later, information on boarding passengers at the boarding point and disembarking passengers at the disembarking point is added to the dispatch plan, and the user information is used as the information on boarding and alighting passengers. The driver of the ride-sharing taxi can confirm the users who will board and alight at the boarding and alighting points from the user information.

Address information is entered for the boarding and disembarking locations. The address information may be text information indicating the address, or numerical data of latitude and longitude. In addition, building information at the boarding and disembarking locations may be added. When traveling in a shared taxi, information that helps confirm the boarding and disembarking locations may also be added.

Let us look at the data entered into the multiple boarding and alighting request data 121 shown in Figure 6. The data with reservation reception numbers 001 to 003 all have the same drop-off location and drop-off date and time. This data indicates that users A, B, and C each wish to go from a different boarding location to the same drop-off location. A specific situation could be when they are going to a cram school. For example, users may be expected to attend classes at the same cram school at the same time. Therefore, it can be said that users with reservation reception numbers 001 to 003 are highly likely to be able to use a shared taxi.

Next, reservation numbers 011 to 013 are the data for users A, B, and C, who are the same as reservation numbers 001 to 003, and who are requesting the same boarding location and boarding date and time. Looking at the drop-off locations, the drop-off location for reservation number 011 is address A, the same as the boarding location for reservation number 001. The drop-off location for reservation number 012 is address B, the same as the boarding location for reservation number 002, and the drop-off location for reservation number 013 is address C, the same as reservation number 003. In the previous example, one possible scenario would be when all the students return home at the same time after their cram school lessons. The situations shown above are merely examples, and other situations are naturally conceivable. If the drop-off locations are the same, one possible scenario would be when going to a facility where many people gather. If the boarding location is the same, one possible scenario would be when returning home from that facility.

[Grouping of boarding and alighting request data]
Next, a process of grouping a plurality of boarding and alighting request data 121 will be described. FIG. 7 is a diagram for explaining a method of grouping based on the same data as FIG. 6. In the grouping method of this embodiment, boarding and alighting request data 121 having the same boarding location and boarding date and time are grouped into one group. Also, boarding and alighting request data 121 having the same disembarking location and disembarking date and time are grouped into one group. Then, GroupNo is added to the beginning of the data for each group. In this way, the same GroupNo is added to the same group, and the data in FIG. 7 is generated. In the example of FIG. 7, data with reservation reception numbers 001 to 003 are grouped with GroupNo 001, and data with reservation reception numbers 011 to 013 are grouped with GroupNo 002. That is, in the data shown in FIG. 7, the data with GroupNo 001 is the same data with the disembarking location being address X and the disembarking date and time being date and time X1. The data with GroupNo 002 is the same data with the boarding location being address X and the boarding date and time being date and time X3.

The three pieces of data with different reservation reception numbers and GroupNo 001 have different boarding locations. This is because the users are different, and users who want to use a ride-sharing taxi to go from different boarding locations to the same disembarking location, Address X, are grouped together in one group. The three pieces of data with different reservation reception numbers and GroupNo 002 have the same boarding location and boarding date and time, but different disembarking locations. Users who want to use a ride-sharing taxi to go from the same boarding location to different disembarking locations are grouped together in one group. Note that the number of data in each group is not limited to three in this example. All boarding and disembarking request data with the same boarding location and boarding date and time, or the same disembarking location and disembarking date and time, will be grouped together in one group.

In the above example, as an example of grouping multiple boarding and alighting request data based on the similarity of the boarding information or alighting information contained in the boarding and alighting request data, boarding and alighting request data with the same boarding location and boarding date and time, or boarding and alighting request data with the same alighting location and alighting date and time, are grouped, but they do not have to be completely identical. Boarding and alighting request data with similar boarding locations and boarding dates and times, or boarding and alighting request data with similar alighting locations and alighting dates and times, may also be grouped. The degree of similarity of the boarding and alighting request data to be grouped is set appropriately depending on the ride-sharing service to be provided.

In this embodiment, the ride-sharing taxi system 10 groups multiple boarding and alighting request data, then clusters the data within the group, dividing it into clusters consisting of a small number of data, and creates a dispatch plan in which one taxi is assigned to each cluster. The process is explained step by step below.

[Clustering process]
FIG. 8(a) shows a diagram in which the drop-off points are arranged on a map for all boarding and alighting request data included in one group. The boarding and alighting request data included in the group are data for cases in which users get off at their respective drop-off points from the same boarding point. Point O, which is arranged in the approximate center of the map and has a different shape from the others, indicates the boarding point (starting point). That is, the map shown in FIG. 8(a) shows the distribution of drop-off points that users want to go to by using a ride-sharing taxi from point O, which indicates the boarding point on the same date and time. Therefore, by clustering these drop-off points and creating a driving route for each cluster, a ride-sharing driving route is created. The following is one method, and does not exclude the creation of a driving route by other methods.

First, as shown in FIG. 8(b), a vector from the departure point (point O) to the alighting point of each boarding/alighting request data is calculated from the address information included in the boarding/alighting request data. The vector is indicated by an arrow in FIG. 8(b).

For example, data with arrows pointing in a similar direction indicates that the direction of the destination from the departure point is similar, and tends to be suitable for clustering for carpooling. The length of the arrow indicates the distance from the departure point, and by selecting data with arrows pointing in a similar direction and with gradually different lengths, a cluster suitable for carpooling will be obtained. In this way, the data surrounded by the solid line in FIG. 8(c) is the data obtained by clustering the boarding and alighting request data in FIG. 8(a). The dashed lines in FIG. 8(c) indicate the stepwise distance from the departure point. FIG. 8(c) shows that the clusters indicated by CL1 to CL6 have been generated. Note that the drawings on the map shown in FIG. 8(a) to (c) are shown in the figure to make the clustering process easier to understand, and it is not necessary to actually draw the data on the map to generate the clusters. Note that in this embodiment, when clustering is performed, the number of boarding and alighting request data included in each cluster is set to 4 or less. This is because this is the maximum number of passengers who will ride together, and if there are more than four people, it becomes difficult to ride together. The maximum number of people in a cluster is not limited to four, as it also depends on the size of the vehicle providing the ride-sharing service.

The clustering method is not limited to the above-mentioned clustering method. A method for generating clusters from multiple boarding and alighting request data can be achieved by applying machine learning using AI, but details will be omitted.

[Carpool route]
Next, the ride-sharing taxi system 10 creates a ride-sharing route for each cluster. An example of the created ride-sharing route 124 is shown in Fig. 9(a) and (b). Fig. 9(a) shows a ride-sharing route 124a in the case where users board at multiple boarding points and ride-sharing to a common arrival point. Fig. 9(b) shows a ride-sharing route 124b in the case where multiple users board at a common departure point and drop off at different drop-off points.

The carpooling route 124a has the dispatch number added to the top of the vertical column. This is followed by four items for the boarding location and boarding date and time, followed by the arrival location, arrival date and time, and route information. The dispatch number indicates the number of the taxi that will be dispatched for the carpooling. In data with a dispatch number of 001, this means that four users will board at boarding locations 1 to 4 and disembark at the arrival location (address X). The route information is information that indicates the carpooling route. Route R1 in the route information has the same structure as the route information in FIG. 5. The route information is used to later send it to the user terminal 100 and the taxi company's computer 200.

For data with dispatch number 002, the items from boarding location 3 to boarding date and time 4 are blank. This is because there are two passengers. In this way, when there are fewer than four passengers, some items will be blank. The data items from the arrival location onwards are the same as when dispatch number is 001. The data items for dispatch numbers 003 and onwards are the same as for data with dispatch numbers 001 and 002.

Figure 9 (b) shows the structure of the carpooling route 124b. Unlike the carpooling route 124a, the carpooling route 124b is ride-sharing data when multiple users board a taxi at the departure point and get off at each of the alighting points. Therefore, the items of departure point and departure date and time follow the dispatch number. Then, four items of alighting point and alighting date and time follow, forming the route information. The data of the carpooling route 124b with dispatch number 011 means that four users board a taxi at the departure point (address X) all at once, and each user gets off one by one. The content of the route R11 of the route information is information indicating the carpooling route. The data of the carpooling route 124b with dispatch number 012 means that there are two passengers, so the items from alighting point 3 to alighting date and time 4 are blank.

If the carpooling routes 124a, 124b contain data that does not satisfy the specified conditions (data that is determined to be unsuitable for carpooling), the number of dispatched taxis in the same group is increased (for example, by adding one taxi) as described below, clustering is performed again, and the carpooling route is created again. If there is no data that does not satisfy the specified conditions, it is processed into a vehicle dispatch plan.

[Judgment for Prescribed Conditions]
In the ride-sharing taxi system 10 of this embodiment, after creating a ride-sharing route, it is determined whether the data includes data that is not suitable for ride-sharing. An example will be described in which a ride-sharing taxi is used for hourly rental. The problem with hourly rental is that the fee increases each time the usage time exceeds a certain rental time. Therefore, it is necessary to ensure that the time spent using a taxi for ride-sharing does not exceed the certain rental time. In this case, the specified condition is that the usage time does not exceed the certain rental time. Hereinafter, an example will be described using data with a dispatch number of 001 for the ride-sharing route 124a in Figure 9(a).

The time spent using a taxi for carpooling corresponds to the carpooling time required to travel the entire carpooling route, which is the time from date and time A1, which is the boarding date and time 1, to date and time X1, which is the arrival date and time. If the time required from date and time A1 to date and time X1 is TA and the time at which the hourly rental fee changes is Ta, then the specified condition is TA<Ta. If this condition is not met, the rental time will be exceeded, the taxi rental fee will be high, and it is determined that the taxi is not suitable for carpooling. If the specified condition TA<Ta is not met, the number of taxis is increased for the group that includes the carpooling route, and clustering is performed again. Since one taxi is assigned to each cluster, increasing the number of taxis to be dispatched increases the total number of clusters, and by clustering again, it is possible to shorten the carpooling time TA. If the specified condition is met, a vehicle dispatch plan is generated.

The specified condition can be something other than the rental time of a taxi for hourly rental. For example, it can be determined based on whether the difference in time between carpooling and not carpooling (called lost time) exceeds a specified time. Lost time is the difference between the time required for carpooling and the time required for a single person to use a taxi. This lost time is the extra time incurred by carpooling, and if the lost time is long, it reduces the benefits of carpooling.

Again, an example of data for the shared ride route 124a in FIG. 9(a) with dispatch number 001 will be described. The data for dispatch number 001 has data filled in for boarding locations 1 to 4, so there are four users. The time required for each user to share a ride is the time obtained by subtracting the user's boarding date and time from the arrival date and time X1. For the data for boarding date and time 2, which is the second data, it is date and time X1 - date and time B1 (T1). The reason why a loss time occurs for the time spent using a taxi alone is because there is a possibility that the route will be detoured to allow other users to board. Now, when calculating the loss time for a user who boards at boarding location 2, it is necessary to calculate the time spent using a taxi alone (t1), but this time t1 can be calculated using an existing route calculation method from the address B of boarding location 2 and the address X of the arrival location. The loss time is T1 - t1. When the allowable time for loss time is Tb, the predetermined condition is (T1 - t1) < Tb. If this condition is not met, it means that carpooling takes longer than the allowable time, and some users may not see the benefit of carpooling. If the specified condition is not met, the number of taxis is increased for the group that includes the carpooling route (the total number of clusters is increased), and clustering is performed again. If the specified condition is met, a vehicle dispatch plan is generated.

[Vehicle allocation plan]
If there is no data in the carpooling route that does not satisfy a predetermined condition, a vehicle dispatch plan 125 is generated. The vehicle dispatch plan 125 is data for requesting a taxi company to dispatch a taxi. The vehicle dispatch plan 125 includes all items included in the carpooling routes 124a and 124b in Figs. 9(a) and 9(b). In addition, the vehicle dispatch plan 125 has two types of structures corresponding to the two types of carpooling routes 124 in Figs. 9(a) and 9(b). Fig. 10(a) is a vehicle dispatch plan 125a corresponding to Fig. 9(a), and Fig. 10(b) is a vehicle dispatch plan 125b corresponding to Fig. 9(b).

The data structure of the dispatch plan 125a differs from that of the carpooling route 124a in that information on passengers boarding at each of the boarding points 1 to 4 is added. In addition, information on passengers disembarking at the disembarking points is also added. The data structure of the dispatch plan 125b differs from that of the carpooling route 124b in that information on passengers boarding at the departure point and information on passengers disembarking at each of the disembarking points 1 to 4 is added. This information is necessary for taxi company drivers to confirm passengers getting on and off.

[Fee calculation data]
FIG. 11 shows the data structure of the fare calculation data 126. The fare calculation data 126 is data that calculates the fare for each user of a shared taxi. The fare calculation data 126 has the dispatch number at the top of the vertical column, followed by the user, boarding location, boarding date and time, alighting location, alighting date and time, required time, single time, single distance, single fare, number of passengers, coefficient, fare, and route information. The items of single time, single distance, and single fare are not required items, but are data that reflect the merits and demerits of carpooling, and are added as reference values. The required time is the planned time it takes to share a ride from the boarding location to the alighting location. The single time is the predicted required time when a taxi is used directly without sharing a ride. The single distance and single fare are the predicted distance and fare when a taxi is used directly. The number of passengers is the number of users who will ride together in a shared ride. The coefficient is a coefficient for calculating the fare for a shared ride, and for example, the fare for a shared ride is determined by multiplying the single fare by the coefficient. The route information has the same data structure as the route information in the dispatch plan 125. In Fig. 11, four pieces of data with dispatch number 001 are shown, which correspond to data for which fares are calculated for each of the four users A to D included in the data with dispatch number 001 in the dispatch plan 125a in Fig. 10(a).

Based on this fare calculation data, the ride-sharing taxi system 10 transmits reservation confirmation data 122 shown in FIG. 5 for each user from the transmission unit 25 to the user terminal 100.

[Re-clustering process]
With reference to Fig. 12, a description will be given of the clustering process performed again when data that does not satisfy a predetermined condition exists in the carpooling route and it is determined that the route is not suitable for carpooling. Fig. 12(a) shows the state immediately after the clustering similar to that of Fig. 8(c) is completed. It is assumed that the data marked with a star in cluster CL3 is not suitable for carpooling. In this case, cluster CL3 is decomposed, the total number of clusters is increased by 1, and the number of clusters is set to 7, and clustering is performed again.

The simplest method of re-clustering is to split the data of a cluster containing data that is unsuitable for carpooling into two clusters. If the data that is unsuitable for carpooling cannot be eliminated by simply splitting the cluster, re-clustering is attempted, including the adjacent clusters. Alternatively, clustering of the entire group may be performed based on the direction and magnitude of the vectors of the departure point and disembarkation point, as described in Figures 8(b) and (c). In this case, since the total number of clusters is increased, the number of data contained in the clusters is reduced, so it is possible to use a similar method to perform clustering so that data that is unsuitable for carpooling is eliminated. Figure 12(b) shows an example of the result of re-clustering. Cluster CL3 has been split and cluster CL7 has been newly added.

[Processing sequence of the ride-sharing taxi system]
The sequence diagram shown in Fig. 13 shows an example of processing performed by the ride-sharing taxi system 10 of this embodiment between the user terminal 100 and the taxi company's computer 200, along with data exchange. Fig. 13 shows a series of processing from sending a ride-sharing request at the user terminal 100, processing the ride-sharing data at the ride-sharing taxi system 10, sending the results to the user terminal 100, and sending a dispatch order to the taxi company's computer 200. In the explanation of Fig. 13, the ride-sharing taxi system 10 will be simply referred to as system 10.

In step S1, boarding/alighting request data is transmitted from the user terminal 100, and the system 10 receives the data at the receiving unit 24. Next, in step S2, the system 10 merges the boarding/alighting request data that has already been accumulated with the data received in step S1, and then performs the above-mentioned grouping, clustering, creation of a carpooling route, and generation of a vehicle dispatch plan.

Next, in step S3, the system 10 transmits a vehicle dispatch plan to the computer 200. The vehicle dispatch plan is the data described in FIG. 10. Next, in step S4, a receipt reply for the vehicle dispatch plan transmitted from the computer 200 is received, and it is confirmed that the data transmission has been completed successfully. After that, in step S5, the system 10 transmits reservation confirmation data including the reservation acceptance number, route information, and fare to the user terminal 100. The reservation confirmation data is the data shown in FIG. 4.

Next, we will explain the sequence that occurs when a reservation is changed or canceled before the actual dispatch of a shared taxi.

The system 10 receives a request to change or cancel a reservation as boarding and alighting request data from the user terminal 100. In step S6, it is assumed that the system 10 receives boarding and alighting request data for changing or canceling a reservation. The system 10 then processes the reservation change or cancellation in step S7. The actual processing is performed based on the data entered in the type of boarding and alighting request data item. In the case of a change in a reservation, the system 10 updates the data with the same reservation reception number among the boarding and alighting request data already in the system 10, performs processing from grouping onwards, and generates a vehicle dispatch plan. In the case of a cancellation of a reservation, the system 10 deletes the data with the same reservation reception number, performs processing from grouping onwards, and generates a vehicle dispatch plan. Next, in step S8, the system 10 transmits the updated vehicle dispatch plan to the computer 200. In step S9, the system 10 receives a receipt reply for the vehicle dispatch plan transmitted from the computer 200 and confirms that the data transmission has been completed successfully. Thereafter, in step S10, the system 10 transmits reservation confirmation data including the updated reservation reception number, route information, and fare to the user terminal 100.

When the day for dispatching the ride-sharing taxi arrives, the system 10 transmits dispatch confirmation information to the computer 200 in step S11. After this, the system 10 does not accept any changes or cancellations to the reservation. In step S12, the system 10 transmits dispatch information for that day to the user terminal 100. This dispatch information for that day is the same as the reservation confirmation data that has already been transmitted to the user terminal 100. Note that the transmission of dispatch confirmation information and dispatch information for that day is not mandatory.

Next, a flowchart of the processing performed in the ride-sharing taxi system 10 is shown. The flowchart described here shows the processing performed in the clustering unit 21, the dispatch plan processing unit 22, and the fare calculation processing unit 31 shown in FIG. 3.

[Clustering process]
14 is a flowchart of the process performed by the clustering unit 21. The clustering unit 21 performs grouping, clustering, and re-clustering of a plurality of boarding/alighting request data.

The clustering unit 21 first receives boarding and alighting request data (step S11). The boarding and alighting request data includes boarding and alighting request data for reservation changes and cancellations (C in the figure). The boarding and alighting request data is stored and accumulated in the storage unit 23. Next, the accumulated boarding and alighting request data is grouped (step S12). Details of the grouping have already been explained in FIG. 7, so they will be omitted. Next, the clustering unit 21 performs clustering on the group data (step S13). Clustering includes re-clustering when the boarding and alighting time is inappropriate in the vehicle allocation planning process described later (processing from A in the figure). The process from A in the figure corresponds to re-clustering, and the number of taxis (cluster number) is increased by 1 (step S14), and clustering processing is performed (step S13). When clustering is completed, the processing of the clustering unit 21 is completed. Note that after the clustering in step S13, synergistic condition adjustment (step S15) may be performed. Synergistic condition adjustment will be described later.

[Vehicle allocation planning processing]
15 is a flowchart of the process performed by the vehicle allocation plan processing unit 22. The vehicle allocation plan processing unit 22 performs processes such as creating a carpooling route for the clusters generated by the clustering unit 21, calculating data for determining whether or not a vehicle is suitable for carpooling, generating a vehicle allocation plan, and assigning a matching coefficient for fare calculation.

The dispatch plan processing unit 22 first creates a ride-sharing route for the cluster data and calculates each required time (step S21). Each required time is the ride-sharing time TA required to travel the entire ride-sharing route, and the loss time T1-t1 for each ride-sharing user. First, it is determined whether the ride-sharing time TA satisfies a predetermined condition: TA<Ta (step S22). If it does not, it is assumed that the predetermined condition for the boarding and alighting time is not satisfied, and clustering is performed again (go to A in the figure). If the predetermined condition is satisfied, proceed to the next step S23. Next, it is determined whether the loss time satisfies a predetermined condition: (T1-t1)<Tb (step S23). If it does not, clustering is performed again in the same way (go to A in the figure). If it is satisfied, a process of assigning a matching coefficient for fare calculation to each user is performed (step S24). After step S24, the process transitions to fare calculation processing (go to B in the figure). In parallel with step S24, the vehicle dispatch plan processing unit 22 generates a vehicle dispatch plan (step S25). The generated vehicle dispatch plan is sent to the information notification processing unit 32 and the order processing unit 33, where it is processed as necessary, and is then sent by the transmission unit 25 to the user terminal 100 and the computer 200.

[Fee calculation process]
16 is a flowchart of the process performed by the fee calculation processing unit 31. After the dispatch plan is generated, the fee calculation processing unit 31 performs processes such as calculation of a ride-sharing fee, reservation change of boarding/alighting request data, confirmation of cancellation, and calculation of a cancellation fee in the event of a cancellation.

The fee calculation processing unit 31 first calculates the fee based on the boarding and alighting distance based on the dispatch plan (step S31). This fee calculation corresponds to the calculation of the single fee explained in the fee calculation data of FIG. 10. Next, the fee is calculated by multiplying the calculated fee by the matching coefficient received from the dispatch plan processing unit (B in the figure) (step S32). This completes the fee calculation, but the fee calculation processing unit 31 of this embodiment further performs processing to check whether the reservation has been changed (step S33) or canceled (step S34). If there is a change in the reservation, the process proceeds to the reservation change process (C in the figure). In parallel with this, the change acceptance data is created for the user terminal (step S35), and the process proceeds to the information notification processing unit 32 for transmission. If there is a cancellation, the process proceeds to the cancellation process (C in the figure). In parallel with this, the cancellation fee is calculated (step S36), and the process proceeds to the information notification processing unit 32 for transmission of the cancellation fee to the user terminal. If there are no changes or cancellations to the reservation, reservation confirmation data and fee information are created (step S37), and processing is transferred to the information notification processing unit 32 for transmission to the user terminal 100.

The first embodiment has been described above. According to this embodiment, ride-sharing routes are created for clusters obtained by grouping and clustering boarding and alighting request data, and if there is data that does not satisfy the specified conditions for ride-sharing, the number of taxis (number of clusters) is increased and clustering is performed again, making it possible to generate ride-sharing routes that satisfy the specified conditions.

Second Embodiment
17 shows another processing example of the ride-sharing taxi system 10 of the second embodiment. The operation of the ride-sharing taxi system 10 in the case where the period for accepting reservations of boarding and alighting request data from the user terminal 100 is long, there is a certain period until the ride-sharing taxi is dispatched, and the boarding and alighting request data increases over time will be described.

Figure 17(a) shows cluster formation one week before dispatch of a ride-sharing taxi, for example. Figure 17(b) shows cluster formation three days before dispatch of a ride-sharing taxi. Figure 17(c) shows cluster formation the day before dispatch of a ride-sharing taxi. As shown in Figures 17(a) to (c), the boarding and alighting request data increases over time, and the cluster formation changes accordingly. In the first embodiment, clustering is performed again every time a reservation change is accepted, but in the second embodiment, clustering is performed at regular intervals. If the reservation period is long, it is expected that the boarding and alighting request data will increase, and this is advantageous because it does not consume system resources as compared to performing clustering again every time a reservation is changed. It goes without saying that the interval for performing clustering again is appropriately adjusted according to the specific situation of providing the ride-sharing service.

Third Embodiment
FIG. 18 shows an example of clustering again based on the synergy conditions set in the boarding/alighting request data. In the first embodiment, the dispatch plan processing unit 22 judges whether or not a predetermined condition is satisfied based on the calculation result of each required time, and clustering again is performed if it is not satisfied. In the third embodiment, clustering again is performed based on the synergy conditions included in the boarding/alighting request data. The synergy conditions are conditions for passengers who will ride together, as explained in the boarding/alighting request data of FIG. 4. Specifically, when using a carpool to take a child to or from a cram school as explained above, it is assumed that the user is a child and only passengers of the same sex are allowed. This process corresponds to the synergy condition adjustment (step S15) of the clustering process of FIG. 14, the explanation of which is omitted.

The explanation will be made with reference to Figs. 18(a) to (c). Fig. 18(a) shows the case where clustering is completed and clusters CL1 to CL6 are generated. Fig. 18(b) shows the relationship of synergy conditions. It is a table showing the synergy conditions of users who are allowed to ride together with users of synergy conditions A, B, and C. The data on the map of clusters CL1 to CL3 in Fig. 18(a) shows which of conditions A to C it is. The data of cluster CL1 is A, A, and C, and there is no problem with the synergy conditions from Fig. 18(b). The data of cluster CL2 is B, C, and C. Users of condition B only allow users of conditions A and B to ride together, so they do not satisfy the synergy conditions. The data of cluster CL3 is A, A, A, and B, and there is no problem with the synergy conditions.

In this case, the number of clusters is increased (to 7) and clustering is performed again. As a result, clusters CL2 and CL3 are divided and cluster CL7 is generated as shown in FIG. 18(c), and the problem of synergistic conditions is resolved. This process is executed by a program incorporated in the clustering unit. What is shown in this embodiment is just one example, and it is of course possible for clusters other than those shown in the figure to be generated by the clustering algorithm. This disclosure does not specify the details of clustering, but is characterized by increasing the number of clusters and performing clustering again.

The present invention is not limited to the above-described embodiment and its variations, and various modifications and improvements are possible within the scope of the claims of this application.

REFERENCE SIGNS LIST 10 Shared taxi system, 11 CPU, 12 Input device, 13 Output device, 14 Storage device, 15 Communication device, 16 Bus, 20 Vehicle dispatch planner, 21 Clustering unit, 22 Vehicle dispatch plan processor, 23 Memory unit, 24 Receiving unit, 25 Transmitting unit, 31 Fare calculation processor, 32 Information notification processor, 33 Order processor, 100, 100A, 100B User terminal, 200 Computer, 300 Network

Claims (1)

A receiving unit that receives boarding and alighting request data of a plurality of users who wish to share a ride;
A vehicle allocation planner that generates a vehicle allocation plan based on the boarding and alighting request data;
A transmission unit that transmits the dispatch plan to a taxi company;
A shared taxi system having:
The vehicle dispatch planning unit is
a clustering unit that performs clustering by grouping a plurality of the boarding/alighting request data based on similarity of boarding information or alighting information contained in the boarding/alighting request data, clustering the data in the group to divide it into clusters consisting of a small number of data, allocating one taxi to be dispatched to each of the clusters , and generating the clusters so that the number of people riding in one taxi is equal to or less than a predetermined number;
a vehicle allocation plan processing unit that creates a ride-pooling route for the cluster and generates the vehicle allocation plan based on the ride-pooling route;
having
When the ride-sharing travel time for each cluster is equal to or longer than a certain time, the vehicle dispatch plan processing unit increases the number of taxis to be dispatched and performs clustering again.
Shared taxi system.

Images