Shared taxi system

Abstract

To provide a share-riding taxi system which performs clustering again, when a predetermined condition is not satisfied, after creating a share-riding travel route, and creates the share-riding travel route again.SOLUTION: In a share-riding taxi service, a share-riding taxi system 10 comprises: a reception unit 24 which receives getting on / off desire data of a plurality of users who desire share-riding; a vehicle dispatch plan unit 20 which generates a vehicle dispatch plan, on the basis of the getting on / off desire data; and a transmission unit 25 which transmits the vehicle dispatch plan to a taxi company. The vehicle dispatch plan unit 20 comprises: a clustering unit 21 which groups a plurality of pieces of getting on / off desire data, on the basis of similarity of getting-on information or getting-off information which the getting on / off desire data have, allocates a taxi to be dispatched one by one, and performs clustering which generates a cluster so that the number of people getting on one taxi becomes equal to or less than a predetermined number; and a vehicle dispatch plan processing unit 22 which creates a share-riding travel route, with respect to the cluster, and generates a vehicle dispatch plan, on the basis of the travel route.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present disclosure relates to a ride-sharing taxi system. [Background technology]

[0002] When using a taxi, if the departure point or destination is the same, there is a demand for sharing a taxi at a low cost. 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 a driving route based on the obtained data.

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

[0004] [Patent Document 1] JP 2003-233656 A Summary of the Invention [Problem to be solved by the invention]

[0005] 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 fact that the fee can be easily calculated, hourly rental of a taxi may be used when mediating a ride-sharing taxi. 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 is created, so the fee cost may become high. The taxi ride-sharing support system of Patent Document 1 does not consider whether the ride-sharing route satisfies certain conditions after it is created, nor does it consider the time conditions for hourly rental of a taxi.

[0006] The object 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 taxi hourly rental, are not satisfied. [Means for solving the problem]

[0007] The ride-sharing taxi system according to the present disclosure includes a receiving unit that receives boarding and alighting request data of multiple users who wish 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 similarity of 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 a predetermined number or less, 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, the number of taxis to be dispatched is increased and clustering is performed again. Effect of the Invention

[0008] The ride-sharing taxi system of 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 greater than or equal to a certain time. [Brief description of the drawings]

[0009] [Figure 1] 1 is an overall configuration diagram of a ride-sharing taxi service provided using the ride-sharing taxi system of the present disclosure. [Diagram 2] 1 is an example of a hardware configuration of a ride-sharing taxi system according to the present disclosure. [Diagram 3] FIG. 1 is a functional block diagram of a ride-sharing taxi system according to an embodiment. [Figure 4] 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. [Diagram 5] 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. [Figure 6] 5 is a diagram showing a state in which a plurality of boarding / alighting request data in FIG. 4 are compiled. FIG. [Figure 7] FIG. 7 is a diagram showing a state in which the boarding / alighting request data in FIG. 6 is grouped. [Figure 8] FIG. 11 is a diagram explaining the process of clustering multiple grouped boarding and alighting request data, where (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. [Figure 9] 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. [Figure 10] FIG. 10 is a diagram showing an example of a data structure of a vehicle allocation plan in which user information is added to the carpooling route in FIG. 9. [Figure 11] FIG. 4 is a diagram illustrating an example of a data structure of fee calculation data. [Figure 12]FIG. 13 is a diagram for explaining re-clustering. [Figure 13] FIG. 2 is a diagram illustrating an example of a processing sequence of the ride-sharing taxi system of the embodiment. [Figure 14] 11 is a flowchart illustrating an example of a process of a clustering unit of the embodiment. [Figure 15] 11 is a flowchart illustrating an example of a process of a vehicle allocation planning processing unit of the embodiment. [Figure 16] 11 is a flowchart illustrating an example of a process of a fee calculation processing unit of the embodiment. [Figure 17] FIG. 11 is a diagram illustrating a clustering process according to another embodiment. [Figure 18] FIG. 13 is a diagram illustrating re-clustering under synergistic conditions in another embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0010] Hereinafter, the embodiments of the present disclosure will be described in detail with reference to the drawings. In the following description, specific shapes, materials, directions, values, etc. are examples for facilitating understanding of the present disclosure, and can be appropriately changed according to applications, purposes, specifications, etc. In addition, it is initially assumed that the components of the embodiments and modified examples described below can be selectively combined.

[0011] [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."

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

[0013] The user terminal 100 is a terminal through which a person who wishes to use a ride-sharing taxi transmits ride-sharing request data to the ride-sharing taxi system 10. There are a plurality of 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.

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

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

[0016] <First embodiment> FIG. 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.

[0017] 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 by using these units.

[0018] 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 similarity of 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 a predetermined number or less. The clustering unit 21 performs clustering on each of the grouped groups.

[0019] The vehicle allocation plan processing unit 22 generates a vehicle allocation plan for each cluster generated by the clustering unit 21. The vehicle allocation plan processing unit 22 creates a carpooling route representing a carpooling route based on the boarding and alighting request data included in the cluster. If the value calculated based on the created carpooling route contains data that does not satisfy a predetermined condition, the processing unit 22 determines that the cluster is unsuitable for carpooling, increases the number of taxis to be allocated, i.e., increases the total number of clusters in the group, and performs clustering again.

[0020] 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 / alighting request data from the user terminal 100. The receiving unit 24 also receives a reply to the dispatch order from the taxi company computer 200. When the receiving unit 24 receives data from the outside, it stores the data in the storage unit 23.

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

[0022] The fee calculation processing unit 31 calculates the fee for each ride-sharing user based on the vehicle dispatch plan. The fee calculation processing unit 31 of this embodiment is also configured to process changes and cancellations to the ride-sharing boarding and alighting request data.

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

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

[0025] [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 dispatch plan will be described while showing the data structure generated in the process of the ride-sharing taxi system 10 generating a ride-sharing dispatch plan. 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.

[0026] [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 configured with a reservation reception number, (reservation) type, boarding location, boarding date and time, alighting location, alighting date and time, desired time, desired fare, and synergistic conditions 1 and 2. The reservation reception number is a number assigned when the ride-sharing taxi system 10 accepts the boarding / alighting request data 121, and serves as an identification number to distinguish 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 entered in the type field, respectively. The previous reservation reception number is entered in the type field of the change data 121c and the cancellation data 121d.

[0027] As shown in Figs. 4(a) and (b), in the case of new data 121a and 121b, the reservation acceptance number is undecided. The items from the boarding place 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.

[0028] 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 the disembarking location are swapped. The boarding date and time and the disembarking date and time are different. This is because data 121a is boarding / alighting request data 121 when the user is going from address A to address X, and data 121b is boarding / alighting request data 121 when the user is returning from address X to address A.

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

[0030] The items of the reservation confirmation data 122 are, in the vertical order, the reservation reception number, boarding location, boarding date and time, alighting location, alighting date and time, number of passengers, fare, taxi information, and route information. Items from the reservation reception number to the alighting date and time are the same as the items of the boarding and alighting 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 dispatched taxi company. The route information is information indicating the ride-sharing route, and is a link to a map screen on the user terminal 100. The link to the route information opens a map application, and the actual ride-sharing route is displayed on the map. The format of the route information is an example, and other formats are also possible.

[0031] FIG. 6 shows a state where a plurality of boarding and alighting request data 121 are accumulated 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 a plurality of items such as the user's name, age, sex, and a registration ID number in the system. The reason for adding the user information is that when a ride-sharing route is created, information on boarding and alighting passengers is required. As will be described later, information on boarding passengers at the boarding point or alighting passengers at the alighting 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 board and alight at the boarding and alighting points by the user information.

[0032] Address information is input for the boarding and disembarking locations. The address information may be character information indicating the address or numerical data of latitude and longitude. Building information at the boarding and disembarking locations may also be added. When traveling in a shared taxi, information that helps confirm the boarding and disembarking locations may also be added.

[0033] Let us look at the data entered into the multiple boarding and alighting request data 121 shown in FIG. 6. The data for 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, it is assumed that the users attend classes at the same time at the same cram school. Therefore, it can be said that there is a high possibility that users with reservation reception numbers 001 to 003 will be able to use a shared taxi.

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

[0035] [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 place and boarding date and time are grouped into one group. Also, boarding and alighting request data 121 having the same alighting place and alighting 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 alighting place being address X and the alighting date and time being date and time X1. The data with GroupNo 002 is the same data with the boarding place being address X and the boarding date and time being date and time X3.

[0036] The three 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 data with different reservation reception numbers and GroupNo 002 have the same boarding location and boarding date and time, but different disembarking locations. This means that 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.

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

[0038] The ride-sharing taxi system 10 of this embodiment groups a plurality of boarding and alighting request data, then clusters the data in the group, divides 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 will be explained step by step below.

[0039] [Clustering process] FIG. 8(a) shows a diagram in which the drop-off points for all boarding and alighting request data included in one group are arranged on a map. 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 driving routes using other methods.

[0040] 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).

[0041] For example, data with arrows pointing in a similar direction means 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 means the distance from the departure point, and by selecting data with arrows pointing in a similar direction and with lengths that differ in stages, a cluster suitable for carpooling is 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 distance from the departure point in stages. 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 easy 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 share a ride, 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.

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

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

[0044] The carpooling route 124a has a dispatch number added to the top of the vertical column. This is followed by four items for boarding location and boarding date and time, followed by arrival location, arrival date and time, and route information. The dispatch number means the number of the taxi dispatched for the carpooling. Data with a dispatch number of 001 means that four users board at boarding locations 1 to 4 and get off at the arrival location (address X). The route information is information that indicates the carpooling route. The route R1 in the route information has the same data structure as the route information in FIG. 5. The route information is used to later transmit to the user terminal 100 and the taxi company computer 200.

[0045] 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 destination onwards are the same as when dispatch number is 001. The data items for dispatch numbers 003 and onwards are the same as data for dispatch numbers 001 and 002.

[0046] FIG. 9(b) shows the structure of the carpooling route 124b. The carpooling route 124b is different from the carpooling route 124a in that it is ride-sharing data when multiple users get on a taxi at a departure point and get off the taxi at each of their respective drop-off points. Therefore, following the dispatch number, the departure point and departure date and time are items. Then, four items of drop-off point and drop-off date and time follow, forming the route information. The data of the carpooling route 124b with dispatch number 011 means that four users get on 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 a carpooling route. The data of the carpooling route 124b with dispatch number 012 means that there are two passengers, so the items from drop-off point 3 to drop-off date and time 4 are blank.

[0047] When there is data that does not satisfy a predetermined condition (data determined to be unsuitable for carpooling), as will be described later, the number of dispatched taxis within the same group is increased (for example, increased by one), clustering is performed again, and a carpooling route is created again. When there is no data that does not satisfy the predetermined condition, it is processed into a vehicle allocation plan.

[0048] [Judgment on Predetermined Conditions] In the carpooling taxi system 10 of the present embodiment, after creating a carpooling route, it is determined whether there is data unsuitable for carpooling in the data. An example of using a carpooling taxi for time rental will be described. What becomes a problem in the case of using it for time rental is that the fee increases every time the usage time exceeds a certain rental time. Therefore, it is necessary to ensure that the time for using a taxi for carpooling does not exceed a certain rental time. In this case, the condition that the usage time does not exceed a certain rental time becomes a predetermined condition. Hereinafter, an example of the data with the vehicle allocation No. 001 of the carpooling route 124a in FIG. 9(a) will be described.

[0049] The time for using a taxi for carpooling corresponds to the carpooling usage time required to travel the entire carpooling route, and is the time from the boarding date and time A1 (which is the date and time 1) to the arrival date and time X1. Let TA be the time required from date and time A1 to date and time X1, and Ta be the time when the fee for time rental changes. Then, the predetermined condition is TA < Ta. If this condition is not satisfied, since the rental time is exceeded, the taxi rental fee becomes high, and it is determined that it is not suitable for carpooling. When the predetermined condition TA < Ta is not satisfied, for the group including the carpooling route, the number of taxis is increased and clustering is performed again. Since one taxi is assigned to each cluster for vehicle allocation, increasing the number of taxis to be allocated means increasing the total number of clusters. By performing clustering again, it becomes possible to shorten the carpooling usage time TA. When the predetermined condition is satisfied, a vehicle allocation plan is generated.

[0050] The specified conditions can also be set to exclude the rental time of the taxi's time rental. For example, it may be determined based on whether the time difference (referred to as loss time) between the case of sharing a ride and the case of not sharing a ride exceeds a predetermined time. The loss time is the difference between the time required when sharing a ride and the time required when using a taxi alone. This loss time is the extra time taken by sharing a ride, and when the loss time is long, the merits of sharing a ride will be reduced.

[0051] Again, an example of the data with the dispatch No. 001 of the shared ride route 124a in Fig. 9(a) will be described. Since the data with the dispatch No. 001 has data filled in the items of pick-up locations 1 to 4, it means there are 4 users. The time required for each user to share a ride is the time obtained by subtracting the pick-up date and time of the user from the date and time X1 of the arrival date and time. For the data of the pick-up date and time 2, which is the second data, it is X1 - date and time B1 (denoted as T1). The loss time occurs with respect to the time of using a taxi alone because there is a possibility of detouring the route to pick up other users. Now, when calculating the loss time for the user who gets on at pick-up location 2, it is necessary to calculate the time of using a taxi alone (denoted as t1), and this time t1 can be calculated using the existing route calculation method based on the address B of pick-up location 2 and the address X of the destination. The loss time is T1 - t1. When the allowable time for the loss time is Tb, the predetermined condition is (T1 - t1) < Tb. If this condition is not satisfied, it means that the time taken by sharing a ride exceeds the allowable time, and in some cases, users may not feel the merits of sharing a ride. If the predetermined condition is not satisfied, for the group including the shared ride route, the number of taxis is increased (the total number of clusters is increased), and clustering is performed again. If the predetermined condition is satisfied, a vehicle dispatch plan is generated.

[0052] [Vehicle Dispatch Plan] If there is no data in the carpooling route that does not satisfy the predetermined conditions, 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 (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 (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).

[0053] The data structure of the vehicle dispatch plan 125a differs from that of the carpooling route 124a in that information on passengers boarding at each of the boarding locations 1 to 4 is added. In addition, information on passengers disembarking at the disembarking locations is also added. The data structure of the vehicle dispatch plan 125b differs from that of the carpooling route 124b in that information on passengers boarding at the departure location and information on passengers disembarking at each of the disembarking locations 1 to 4 are added. This information is necessary for the taxi company drivers to confirm passengers boarding and disembarking.

[0054] [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 people sharing a ride, 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 people sharing a ride 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 of the dispatch plan 125. In Fig. 11, four data items with dispatch No. 001 are shown, which correspond to data items with fares calculated for each of the four users A to D included in the data with dispatch No. 001 of the dispatch plan 125a in Fig. 10(a).

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

[0056] [Re-clustering process] With reference to Fig. 12, the clustering process is described 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. The data marked with a star in cluster CL3 is considered to be data that 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.

[0057] 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, try re-clustering, 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 the drop-off 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 cluster the data so that the data that is unsuitable for carpooling is eliminated using a similar method. Figure 12(b) shows an example of the result of re-clustering. Cluster CL3 has been split and cluster CL7 has been newly added.

[0058] [Processing sequence of a ride-sharing taxi system] 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 is shown together with data transmission in the sequence diagram shown in Fig. 13. Fig. 13 shows a series of processing from sending a ride-sharing request at the user terminal 100, processing the ride-sharing data in 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 called the system 10.

[0059] 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 already stored 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.

[0060] 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 normally. 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.

[0061] Next, a sequence will be described in the case where a reservation is changed or canceled before the actual dispatch of a shared taxi.

[0062] The system 10 receives a request to change or cancel a reservation as boarding / alighting request data from the user terminal 100. In step S6, it is assumed that the system 10 receives boarding / 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 / alighting request data item. In the case of a change in a reservation, data with a matching reservation reception number among the boarding / alighting request data already in the system 10 is updated, and processing from grouping onwards is performed to generate a vehicle allocation plan. In the case of a cancellation of a reservation, data with a matching reservation reception number is deleted, and processing from grouping onwards is performed to generate a vehicle allocation plan. Next, in step S8, the system 10 transmits the updated vehicle allocation plan to the computer 200. In step S9, the system 10 receives a receipt response for the vehicle allocation plan transmitted from the computer 200 and confirms that data transmission has been completed normally. 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.

[0063] On the day of dispatching the ride-sharing taxi, 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 it is not essential to transmit the dispatch confirmation information and dispatch information for that day.

[0064] Next, there will be shown a flowchart of the processing performed in the ride-sharing taxi system 10. The flowchart described here shows the processing contents in the clustering unit 21, the vehicle allocation plan processing unit 22, and the fare calculation processing unit 31 shown in FIG.

[0065] [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 desire data.

[0066] 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 described in FIG. 7 and will not be described here. Next, the clustering unit 21 performs clustering on the group data (step S13). The 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.

[0067] [Ride-sharing Plan Processing] FIG. 15 is a flowchart of the processing performed by the ride-sharing plan processing unit 22. The ride-sharing plan processing unit 22 performs processing such as creating a ride-sharing route, calculating data for determining whether it is suitable for ride-sharing, generating a ride-sharing plan, and assigning a matching coefficient for fare calculation for the clusters generated by the clustering unit 21.

[0068] The ride-sharing 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 utilization 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 utilization time TA satisfies the predetermined condition: TA < Ta (step S22). If it does not satisfy, it is considered that the predetermined condition of the boarding and alighting time is not satisfied, and clustering is performed again (to A in the figure). If the predetermined condition is satisfied, the process proceeds to the next step S23. Next, it is determined whether the loss time satisfies the predetermined condition: (T1 - t1) < Tb (step S23). If it does not satisfy, clustering is performed again in the same way (to A in the figure). If it satisfies, the process of assigning a matching coefficient for fare calculation to each user is performed (step S24). After step S24, the process is transferred to the fare calculation process (to B in the figure). In parallel with step S24, the ride-sharing plan processing unit 22 generates a ride-sharing plan (step S25). The generated ride-sharing plan is sent to the information notification processing unit 32 and the order processing unit 33, subjected to necessary processing, and transmitted to the user terminal 100 and the computer 200 by the transmission unit 25.

[0069] [Fare Calculation Processing] FIG. 16 is a flowchart of the processing performed by the fare calculation processing unit 31. After the ride-sharing plan is generated, the fare calculation processing unit 31 performs processing such as calculating the ride-sharing fare, reserving changes to boarding and alighting request data, confirming the presence or absence of cancellation, and calculating the cancellation fare if cancellation occurs.

[0070] The fee calculation processing unit 31 first calculates the fee based on the boarding and alighting distances 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). Although the fee calculation is completed above, the fee calculation processing unit 31 of this embodiment further performs processing to check whether the reservation has been changed (step S33) and whether it has been canceled (step S34). If there is a change in the reservation, the process proceeds to reservation change processing (C in the figure). In parallel with this, 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 cancellation processing (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 is no reservation change or cancellation, reservation confirmation data and fee information are created (step S37), and the process is transferred to the information notification processing unit 32 for transmission to the user terminal 100.

[0071] 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 a predetermined condition 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 predetermined conditions.

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

[0073] FIG. 17(a) shows the cluster formation state one week before dispatch of a ride-sharing taxi, for example. FIG. 17(b) shows the cluster formation state three days before dispatch of a ride-sharing taxi. FIG. 17(c) shows the cluster formation state the day before dispatch of a ride-sharing taxi. As shown in FIG. 17(a)-(c), the boarding and alighting request data increases with time, and the cluster formation state also changes. 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. When 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 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 a ride-sharing service.

[0074] <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 which the explanation has been omitted in the clustering process of FIG. 14.

[0075] The following description will be given with reference to Fig. 18(a)-(c). Fig. 18(a) shows a case where clustering is completed and clusters CL1-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-CL3 in Fig. 18(a) shows which of conditions A-C applies. 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.

[0076] 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 the synergistic conditions is resolved. This process is executed by a program incorporated in the clustering unit. What is shown in this embodiment is just an example, and it is possible that clusters other than those shown in the figure may be generated by the clustering algorithm. The present disclosure does not specify the details of clustering, but is characterized by increasing the number of clusters and performing clustering again.

[0077] It should be noted that the present invention is not limited to the above-described embodiment and its modified examples, and various modifications and improvements are possible within the scope of the matters described in the claims of this application. [Explanation of symbols]

[0078] 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

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