A hitchhiking relay method, device and equipment

Abstract

The embodiment of the specification provides a hitchhiking relay method, device and equipment, and relates to the technical field of traffic and travel, and the method comprises the following steps: acquiring a hitchhiking order for cross-city travel; the hitchhiking order comprises a starting point and a terminal point; determining a relay node according to the starting point and the terminal point; splitting the hitchhiking order into a high-speed section sub-order from the starting point to the relay node and a final section sub-order from the relay node to the terminal point; matching a first transport capacity for the high-speed section sub-order; matching a second transport capacity for the final section sub-order; and performing unified performance state tracking and trip management on the high-speed section sub-order and the final section sub-order.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of transportation and travel technology, specifically to a ridesharing method, device, and equipment. Background Technology

[0002] Intercity ridesharing is an important scenario in the shared mobility sector. Passengers post their intercity travel needs on the platform, and private car owners along the way accept the orders, achieving low-cost intercity travel.

[0003] However, many passing drivers only travel on highways near their target cities and are unwilling to exit the highway and detour into the city. The existing single-driver full-journey delivery model excludes them from the supply, resulting in a large waste of highway transportation capacity and a low cross-city ridesharing order acceptance rate. Summary of the Invention

[0004] The purpose of the embodiments in this specification is to provide a ridesharing method, device, and equipment to overcome the waste of a large amount of highway transportation capacity and the low cross-city ridesharing order acceptance rate in existing methods.

[0005] To solve the above-mentioned technical problems, the specific technical solutions of the embodiments in this specification are as follows: On the one hand, the embodiments of this specification provide a ridesharing relay method, including: Obtain ride-sharing orders for intercity travel; the ride-sharing orders include the origin and destination; Based on the starting point and the ending point, the relay node is determined; The ride-sharing order is split into a high-speed segment order from the origin to the relay node and a final segment order from the relay node to the destination; Match the first transport capacity to the order for the aforementioned high-speed segment; Match a second transport capacity to the last segment of the sub-order; The order status of the high-speed segment and the order of the last segment are tracked and the trip is managed in a unified manner.

[0006] Furthermore, the unified tracking of fulfillment status and trip management for the high-speed segment orders and the final segment orders includes: Generate the total amount to be paid for the ridesharing order; Receive a one-time payment confirmation from the passenger for the total price to be paid.

[0007] The step of determining the relay node based on the start and end points includes: Based on the origin and destination, determine the multiple highway exit nodes along the route of the ride-sharing order; The node closest to the destination among multiple high-speed exit nodes is selected as the relay node.

[0008] Furthermore, determining the relay node based on the starting point and the ending point includes: Based on the origin and destination, determine multiple candidate nodes along the route of the ride-sharing order; Calculate the succession index for each candidate node; The node with the highest successor index among multiple candidate nodes is selected as the successor node.

[0009] Furthermore, the calculation of the relayability index of each candidate node includes: The relayability index of each candidate node is calculated based on at least one of the multiple node evaluation factors. The node evaluation factors include terminal capacity supply density, highway detour distance, node stopping safety, node transfer convenience, terminal travel distance, and node traffic congestion index.

[0010] Furthermore, the method also includes: After a ridesharing order is completed, update multiple relay evaluation factors for each candidate node; Based on the updated relay evaluation factors of each candidate node, the relayability index of each candidate node is updated.

[0011] Furthermore, the first transportation capacity includes ride-sharing capacity; the second transportation capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity. The method further includes: Calculate the availability index of various secondary transportation capabilities corresponding to each candidate node; The step of selecting the node with the highest successor index among multiple candidate nodes as the successor node includes: If the availability index of multiple secondary transportation resources corresponding to the node with the highest relay index does not meet the preset availability conditions, the node with the highest relay index among the candidate nodes whose availability index of multiple secondary transportation resources meets the preset availability conditions will be taken as the relay node.

[0012] Furthermore, the method also includes: During high-speed travel, update the relay index of each unpassed candidate node and the availability index of various secondary transportation capabilities corresponding to each unpassed candidate node; Adjust relay nodes based on the updated relayability and availability indices.

[0013] Furthermore, the first transportation capacity includes ride-sharing capacity; the second transportation capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity. The process of matching the second transportation capacity for the final sub-order includes: Calculate the availability index for each type of secondary transport capacity; The second capacity with the highest availability index is matched to the last sub-order.

[0014] Furthermore, the calculation of the availability index for each type of second capacity includes: The availability index of each second capacity is calculated based on at least one of multiple capacity evaluation factors for each type of second capacity; the capacity evaluation factors include terminal journey distance, terminal capacity supply density, expected waiting time, and passenger capacity preference.

[0015] Furthermore, the method also includes: Determine the mode priority of each type of secondary transportation based on at least one of the following: the time period of the last segment order, the capacity supply during that time period, and the passenger's historical capacity preference profile; The calculation of the availability index for each second capacity based on at least one of multiple capacity evaluation factors for each second capacity includes: The availability index for each type of secondary capacity is calculated based on the mode priority of each type of secondary capacity and at least one of the multiple capacity evaluation factors for each type of secondary capacity.

[0016] Furthermore, the method also includes: During high-speed travel, if the location of the first matched transport capacity and the relay node meet the preset triggering conditions, the relay of the second matched transport capacity will be triggered.

[0017] Furthermore, the method also includes: During high-speed travel, the relay time of the matched second transport is adjusted based on the feedback information of the location and speed of the matched first transport.

[0018] Furthermore, the method also includes: If the second capacity matching for the final sub-order fails or is cancelled, a rematch will be performed using the same capacity mode. If matching within the same capacity mode fails, a downgraded matching across different capacity modes will be performed. If multiple secondary transport options are unavailable at the relay node and the first transport option for the high-speed segment order has not arrived at the relay node, a new relay node is determined.

[0019] Furthermore, embodiments of this specification provide a ridesharing relay device, comprising: The acquisition module is used to acquire ride-sharing orders for intercity travel; the ride-sharing orders include the origin and destination; The determination module is used to determine the relay node based on the starting point and the ending point; The splitting module is used to split the ride-sharing order into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination. The first matching module is used to match the first transportation capacity for the high-speed segment order; The second matching module is used to match a second transportation capacity for the final segment sub-order; The tracking and management module is used to perform unified tracking of the fulfillment status and trip management for the high-speed segment orders and the last segment orders.

[0020] Furthermore, embodiments of this specification provide a computer device, including: The system includes a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes these computer instructions to implement the aforementioned ridesharing method.

[0021] Furthermore, embodiments of this specification provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the aforementioned ridesharing relay method.

[0022] Furthermore, embodiments of this specification provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the aforementioned ridesharing relay method.

[0023] As can be seen from the technical solutions provided in the embodiments of this specification above, these embodiments can split intercity ridesharing orders into highway segment sub-orders and final segment sub-orders, and match them with first and second transportation capacity respectively. This allows a trip that originally required a single transportation capacity for the entire journey to be completed by two segments of transportation capacity relaying each other. This allows drivers who only wish to travel on the highway segment and do not want to detour into the city to act as the first transportation capacity to take over the highway segment, avoiding the exclusion of this portion of transportation capacity from the supply, releasing wasted highway toll capacity, and improving the capacity utilization rate and order matching success rate of intercity ridesharing. Simultaneously, by uniformly tracking the fulfillment status and managing the trip for the two sub-orders, passengers perceive it as a single order and a single trip, ensuring the continuity and consistency of the transfer process. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below.

[0025] Figure 1 This is a schematic diagram illustrating an application scenario of a ridesharing relay method provided in the embodiments of this specification; Figure 2 This is a flowchart of a ridesharing relay method provided in the embodiments of this specification; Figure 3 This is a schematic diagram of the overall process of a ridesharing relay method provided in the embodiments of this specification; Figure 4This is a schematic diagram of the hierarchical structure of a ridesharing relay method provided in the embodiments of this specification; Figure 5 This is a schematic diagram illustrating the unified tracking of fulfillment status and trip management of sub-orders in a ridesharing relay method provided in the embodiments of this specification; Figure 6 This is a schematic diagram of the selection process for candidate nodes in a ridesharing relay method provided in the embodiments of this specification; Figure 7 This is a schematic diagram of multi-party interactive relay in a ridesharing relay method provided in the embodiments of this specification; Figure 8 This is a schematic diagram of the local recalculation and mode degradation mechanism in a ridesharing relay method provided in the embodiments of this specification; Figure 9 This is a schematic diagram of the structural composition of a computer device provided in the embodiments of this specification; Figure 10 This is a schematic diagram of the structural composition of a terminal device provided in the embodiments of this specification. Detailed Implementation

[0026] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments in this specification. Other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort should fall within the scope of protection of this specification.

[0027] It should be noted that the terms "first," "second," etc., used in this specification, claims, and the foregoing drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0028] This specification provides an embodiment of a ridesharing system. For example... Figure 1As shown, the ridesharing system includes multiple terminal devices and a server. The terminal devices can be user-facing devices. The users can include one or more first users, one or more second users, and one or more third users. The first user is a ridesharing driver providing high-speed transportation capacity, the second user is a passenger initiating an intercity travel request, and the third user is a transportation provider offering last-mile transportation capacity, which includes at least one of ridesharing capacity, taxi capacity, or public transportation capacity. The terminal devices can include one or more first terminal devices, one or more second terminal devices, and one or more third terminal devices. The first terminal device is for the first user, the second terminal device is for the second user, and the third terminal device is for the third user.

[0029] The terminal device can be a personal computing device owned and operated by the user, such as a smartphone, tablet, laptop, or in-vehicle smart terminal. On these terminal devices, a client application providing ride-sharing services is installed and runs. This client application is responsible for presenting the user interface, obtaining operational instructions, and communicating with a remote server. Users interact with this client to complete a series of operations, including posting intercity travel orders, confirming relay points, splitting orders, matching transportation capacity, and connecting trips.

[0030] Specifically, the first user's first terminal device is responsible for: 1) presenting the ride-sharing trip acquisition interface, receiving and uploading the trip origin, destination and departure time window entered by the first user; 2) receiving and displaying the relay node information and highway segment order matching results sent by the server; 3) continuously reporting the first user's real-time location and driving speed during the trip execution; and 4) receiving the relay node arrival prompts and passenger transfer guidance information pushed by the server.

[0031] The second user's second terminal device is responsible for: 1) presenting the intercity travel order publishing interface, receiving and uploading the departure point, destination, and target travel time window entered by the second user, and generating a master order; 2) receiving and displaying the order splitting results and relay node information issued by the server; 3) receiving the matching status of the final segment of transportation capacity and the estimated arrival time at the relay node; 4) at the relay node, receiving transfer guidance information, including navigation to the final segment's boarding point and the vehicle's real-time location; 5) after the trip ends, presenting the trip feedback interface, obtaining the second user's evaluation information on the highway segment and the final segment of transportation capacity, and uploading it to the server.

[0032] The third user's third terminal device is responsible for: 1) receiving the last segment order matching request sent by the server and presenting the order details (relay node to destination, estimated departure time window); 2) obtaining the third user's confirmation or rejection instruction for the last segment order; 3) continuously reporting the third user's real-time location during the trip; 4) receiving the estimated time of passenger arrival at the relay node and pick-up instructions pushed by the server.

[0033] The server can be a backend system deployed in the cloud, providing core computing and scheduling capabilities. It can be a high-performance cloud server instance or a cluster of multiple servers. The server is the hub of the ridesharing system, and it can be used to: 1) Receive parent orders uploaded by second terminal devices, determine at least one candidate relay node based on the origin and destination, calculate the relayability index of each candidate node, and select the node with the highest relayability index as the target relay node. 2) Split the parent order into high-speed segment orders from the origin to the relay node and final segment orders from the relay node to the destination. 3) Match the high-speed segment orders with a first user (a passing ridesharing driver) and push the matching results to the first terminal device. 4) Match the final segment orders with a third user or public transportation capacity. The matching process includes evaluating the feasibility of three capacity modes: ridesharing, on-demand rides, and public transportation connections, selecting the optimal mode, and pre-matching capacity. 5) During the trip, obtain the real-time location and speed of the first user. When the location of the first user and the relay node meet the preset trigger conditions, send a pick-up notification to the matched third user. Dynamically adjust the timing of sending the pick-up notification based on the real-time location and speed of the first user. 6) When the second capacity matching for the final segment of the sub-order fails or is canceled, perform same-mode re-matching or cross-mode downgraded matching, and reselect a relay node if necessary. 7) After each relay is completed, obtain the actual waiting time, matching success rate of each mode, fulfillment time, and passenger evaluation data, and update the relayability index of the candidate relay node and the adaptation weight of each mode.

[0034] Through close collaboration, terminal devices and servers form a cloud-based intelligent decision-making and precise connection ride-sharing system. The first terminal device ensures real-time interaction and autonomous control for drivers on highways during their trips; the second terminal device provides passengers with a one-stop experience for intercity travel and transfers; and the third terminal device enables last-mile delivery providers to efficiently accept orders and coordinate connections. This collaboration achieves a complete closed loop for ride-sharing matching, from master order placement, intelligent order splitting, multi-mode delivery matching, relay timing control to anomaly handling and system self-evolution.

[0035] like Figure 1As shown in the example scenario, Ms. Li, a second user, plans to travel from Beijing to Shijiazhuang to attend a meeting the following morning and hopes to take a rideshare. She opens the travel service application on her phone, enters the "Intercity Rideshare" interface, inputs the departure point "a residential area in Chaoyang District, Beijing", the destination "a hotel in Chang'an District, Shijiazhuang", and the departure time window "19:00-20:00 on the same day", generating an intercity travel master order. The second terminal device then sends the order information to the cloud server.

[0036] After receiving the parent order, the server plans an intercity route based on the origin and destination, identifying three candidate relay nodes along the way: Zhuozhou Exit, Baoding Exit, and Zhengding Exit on the G4 Beijing-Hong Kong-Macau Expressway. The server calculates the relay index for each node, comprehensively considering the terminal capacity supply density around the node, the extra driving distance for drivers on the expressway to reach the node, node parking safety, pedestrian convenience for transfers, remaining distance, and traffic congestion index. It finds that the Zhengding Exit has the highest terminal capacity supply density and the best transfer convenience, resulting in the highest overall score, and thus determines it as the target relay node.

[0037] The server splits the parent order into a highway segment order (a residential area in Chaoyang District, Beijing → Zhengding Exit) and a final segment order (Zhengding Exit → a hotel in Chang'an District, Shijiazhuang). The server searches for drivers passing through the Zhengding Exit from online ride-sharing drivers. The first user, Mr. Zhang, was driving from Tongzhou, Beijing to Zhengzhou, Henan that day, and his route happened to pass through the Zhengding Exit; he did not plan to exit the highway into the city. The server pushed the highway segment order to Mr. Zhang, who confirmed the order and became the first available driver.

[0038] The server evaluated three transportation options for the last-mile order: a bus departs near the Zhengding exit at 20:15 and passes by Ms. Li's hotel, a 3-minute walk from the bus stop; two ridesharing options are also available; and three express cars can arrive within 5 minutes. Considering Ms. Li's urgent meeting time and the approximately 18-kilometer last-mile distance, the server selected the on-demand ride-hailing option as the optimal second transportation option, pre-matching the nearest express driver (the third user, Mr. Zhao) and pushing the matching result to Ms. Li's second terminal device. Ms. Li reviewed and confirmed the plan.

[0039] During the trip, Mr. Zhang's primary terminal continuously reported his real-time location and speed. When the server detected that Mr. Zhang was 25 kilometers away from the Zhengding exit and expected to arrive in 25 minutes, it sent a pick-up notification to Mr. Zhao's secondary terminal: "You have a passenger expected to arrive at the Zhengding exit in 25 minutes. Please proceed to the waiting area outside the exit." Mr. Zhao confirmed and departed. The server dynamically adjusted the timing of the notification based on Mr. Zhang's real-time speed. When Mr. Zhang slowed down due to congestion, the server pushed an updated arrival time to Mr. Zhao.

[0040] Mr. Zhang arrived at the Zhengding exit as planned, and Ms. Li got off. The server pushed walking guidance information to Ms. Li's second terminal device: "Please walk 100 meters along the right-hand passage to the parking area. Mr. Zhao's white express car is waiting." Ms. Li successfully transferred to the car and finally arrived at the hotel on time.

[0041] If the supply of express cars near the Zhengding exit suddenly becomes tight on the day of travel, and the pre-matched driver Zhao cancels for any reason, the server will automatically perform cross-mode downgrade: re-search for rideshares for the last leg of the journey. If the distance is too far to reach in time, switch to bus connection mode, push the latest bus information and walking navigation, and ensure that Ms. Li has an alternative for the last leg of her journey.

[0042] After the trip is completed, the server obtains the actual waiting time (Ms. Li waited for 2 minutes), the matching success rate, the fulfillment time, and Ms. Li's evaluation data on the highway section and the last section. It then updates the relay index of the Zhengding exit node and the adaptation weight of the ride-hailing mode for that period, which is used for intelligent decision-making for subsequent orders.

[0043] In the above scenario example, the server intelligently splits the parent order and scores the relay nodes, transforming Mr. Zhang, a passing driver unwilling to exit the highway, into an effective supply; through multi-mode matching and pre-scheduling in the final stage, it provides Ms. Li with a deterministic transfer guarantee; and through timing control and anomaly degradation, it achieves a smooth connection between the highway segment and the final stage. The entire process, centered on intercity ridesharing relay, systematically solves the problems of wasted capacity on highways and low acceptance rates for intercity ridesharing, achieving efficient collaboration among highway drivers, final stage capacity providers, and passengers.

[0044] Figure 2 A flowchart of a ridesharing relay method according to one embodiment of this specification is shown. This ridesharing relay method can be applied to a server. Although this specification provides method operation steps or apparatus structures as shown in the following embodiments or figures, more or fewer operation steps or module units may be included in the method or apparatus based on conventional or non-inventive effort. In steps or structures where there is no logically necessary causal relationship, the execution order of these steps or the module structure of the apparatus is not limited to the execution order or module structure described in the embodiments and figures of this specification. When the method or module structure is applied in actual devices or terminal products, it can be executed sequentially or in parallel according to the method or module structure shown in the embodiments or figures (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed processing environment).

[0045] Specifically, such as Figure 2 As shown in the figure, one embodiment of this specification provides a ridesharing method that can be applied to a server, which may include the following steps.

[0046] S201: Obtain a ride-sharing order for intercity travel; the ride-sharing order includes the origin and destination.

[0047] In some embodiments, cross-city ridesharing orders can be used to characterize travel demand where the departure and arrival cities belong to different administrative regions. Specifically, the geographical coordinates of the departure and destination cities input by the passenger can be received from the passenger's end, and electronic map data can be used to determine whether the two locations cross at least one city boundary. Direct public transportation between different cities is often lacking, and the success rate of matching ridesharing throughout the entire journey is low, forcing passengers to make multiple transfers or drive themselves. Therefore, using cross-city boundaries as an order filtering condition can provide an accurate basis for subsequently breaking down the trip into highway and terminal segments.

[0048] In other embodiments, cross-city ridesharing orders can also be used to characterize travel demand where there is at least one toll highway or closed expressway between the origin and destination, regardless of whether they are located within the same administrative region. Specifically, a route can be planned based on the origin and destination, and it can be detected whether the route includes toll highway sections or closed expressway sections with speed limits not lower than a preset speed and without traffic lights. Therefore, the aforementioned cross-city ridesharing orders can specifically include, but are not limited to, the following types: cross-city travel orders, intra-city cross-district travel orders, and cross-suburban and urban travel orders.

[0049] Furthermore, ride-sharing orders for intercity travel can also be used to characterize travel demand between the originating and destination cities. The destination and originating cities are connected by highways or expressways, and the geographical distance exceeds a preset distance. For example, this travel demand could be from the main urban area of ​​the originating city to its outer suburbs. The main urban area can be defined as the continuous built-up area radiating outwards from the city's administrative center, while the outer suburbs can be defined as the peripheral areas connected to the main urban area by highways or expressways, and geographically located beyond a preset distance (e.g., 30 kilometers).

[0050] In practice, the origin and destination coordinates can be obtained from the passenger's end, and then road network topology data can be called to determine whether a highway connection exists between the two locations, and whether the length of the connection exceeds a preset distance (e.g., 30 kilometers). It should be noted that between the near and far suburbs of a city, and between the main urban areas and suburbs of different cities, many drivers prefer to use main highways rather than suburban side roads. Therefore, extending the concept of intercity travel to long-distance expressway travel between urban and suburban areas can help free up more previously wasted highway capacity.

[0051] S202: Determine the relay node based on the starting point and the ending point.

[0052] A transfer node is a geographical location that allows passengers to transfer from one mode of transportation to another during a ridesharing trip. This transfer node is located on the planned route between the origin and destination and has physical space conditions for vehicles to temporarily stop, for passengers to safely disembark, and for passengers to walk to the pick-up point of another mode of transportation. These physical space conditions may include: areas where vehicles can enter and temporarily stop, passageways where passengers can safely walk, and areas where the second mode of transportation can enter and stop to pick up passengers.

[0053] The relay node can be one or more of the following physical locations: a temporary parking area or designated parking area outside the highway exit toll plaza, which is a transition section between the highway closed area and local roads, allowing vehicles to temporarily stop to pick up and drop off passengers; parking spaces or designated transfer areas in highway service areas, where passengers can complete cross-vehicle transfers; bus stops, taxi stands, or ride-hailing pick-up and drop-off points near the intersection of the highway exit connecting road and local roads; or the plaza outside the exit of a transportation hub or subway station, or a popular taxi-hailing area, which is no more than a preset walking distance (e.g., 200 to 500 meters) from the highway exit.

[0054] The relay node must meet the following conditions: the driver can reach the node to drop off passengers without entering the city's internal road network, and can rejoin the original route after dropping off passengers by an additional driving distance not exceeding a preset mileage threshold (such as 3 kilometers).

[0055] In some embodiments, multiple highway exit nodes along the route of the ride-sharing order can be determined based on the origin and destination.

[0056] The highway exit node is used to identify the location of toll stations where the highway mainline connects to the ramps. This node can include the location information, name of the toll station, and attribute information such as whether temporary parking is allowed at the exit.

[0057] In some embodiments, a driving route can be planned based on the starting point and the destination, and all highway exit names and their location information on the route can be extracted based on map road network data to form an exit list.

[0058] In other embodiments, only high-speed exit nodes that are more than a first preset mileage from the starting point and more than a second preset mileage from the ending point can be retained to exclude invalid exits that are too close to the starting point or the ending point.

[0059] In some embodiments, the node closest to the destination among multiple highway exit nodes can be selected as the relay node. For each highway exit node, the route mileage from that exit along the planned route to the destination can be calculated, and the exit with the shortest route mileage can be selected as the relay node. Minimizing the final journey distance helps passengers reach the destination as quickly as possible after transferring. If there are multiple exit nodes with the shortest route mileage (e.g., the same exit in different directions), the exit with the shortest walking transfer distance can be selected as the relay node.

[0060] In some embodiments, multiple candidate nodes along the route of a ride-sharing order can be determined based on the origin and destination. Candidate nodes represent a set of potential geographical locations that can be selected as relay nodes, which may include one or more of highway exit nodes, service area nodes, and transportation hub nodes. Considering that there may be more convenient public transportation transfer points near highway exits, using only exit locations as candidates may overlook better transfer options.

[0061] In some embodiments, cross-city driving routes can be planned based on the origin and destination. Multiple highway exits along the driving route can be used as candidate nodes. Service areas, highway exits, and bus hubs, subway stations, and ride-hailing hotspots within a preset walking distance of the highway exits along the driving route can also be merged and aggregated to form multiple candidate node sets. Each candidate node set corresponds to a physical area where passengers can transfer, and the geographical center of this set is used as a candidate node. The purpose of merging and aggregating is to treat multiple spatially adjacent and walkable transfer points as a single transfer area, avoiding duplicate calculations and scoring biases caused by multiple transfer points within the same area (such as bus stops and subway stations next to highway exits) being treated as independent nodes. Regional aggregation reduces redundant nodes, allowing relay node scoring to focus more on the overall capacity of the area rather than individual facilities.

[0062] In some embodiments, the historical success rate of each candidate node and the density of last-mile transportation hubs within a preset radius around the node can also be obtained. The historical success rate represents the proportion of times the node has been selected as a relay node and successfully completed a transfer within a past period. The density of last-mile transportation hubs represents the number of available ride-sharing, express, or bus stops within a certain radius around the node. Some highway exits, although well-located, have historically had high transfer failure rates or lack last-mile transportation capacity in their vicinity. Therefore, filtering out substandard nodes in advance through data screening can effectively improve the relay success rate.

[0063] In some embodiments, a relayability index is calculated for each candidate node. The relayability index is used to characterize the overall score of a candidate node's suitability as a relay node; a higher overall score indicates that the node is more conducive to the connection between high-speed and terminal capacity.

[0064] In some embodiments, the relayability index of each candidate node can be calculated based on at least one of multiple node evaluation factors. These node evaluation factors include terminal capacity supply density, highway detour distance, node stop safety, node transfer convenience, terminal travel distance, and node traffic congestion index. Terminal capacity supply density characterizes the spatiotemporal abundance of available secondary transportation options (ridesharing, taxis, public transportation) around the node. Highway detour distance characterizes the additional mileage required for the first transportation option to deviate from its original route to the node. This detour distance is calculated as the additional mileage required to return to the original route or rejoin the highway after departing from the nearest point on the first transportation option's original route, disembarking passengers at the relay node, and then returning to the original route. Methods of returning to the original route include, but are not limited to: re-entering the highway via the dedicated U-turn ramp outside the toll plaza, driving along the connecting road to a U-turn intersection and then turning back onto the highway, or continuing along local roads to the next highway entrance to re-enter the highway. Node stop safety characterizes whether the node has a standardized parking area, lighting facilities, and security conditions. Node transfer convenience is used to characterize the distance a passenger walks from the disembarkation point to the final boarding point, the availability of rain shelters, and accessibility features such as elevators. Final journey distance is used to characterize the remaining travel distance from the node to the destination. Node traffic congestion index is used to characterize the traffic conditions on roads surrounding the node.

[0065] When the drop-off point is the plaza outside a highway exit toll station, the passenger disembarkation process is as follows: The driver exits the main highway, enters the ramp, passes through the toll station, exits the toll lane, and enters the temporary parking area or designated drop-off area outside the toll station plaza, where passengers disembark safely. The driver does not need to enter urban main roads or internal roads. After passengers disembark, the driver can use the dedicated U-turn ramp outside the toll station plaza, the U-turn intersection on the connecting road, or continue along local roads to the next highway entrance to re-enter the highway and continue their original journey. If the exit does not have direct U-turn access to the highway, the system can calculate the highway detour distance for that node based on road network data and exclude nodes with detour distances exceeding a preset threshold from the candidate nodes.

[0066] In some embodiments, one of the multiple node evaluation factors for each candidate node can be directly used as the successor index for each candidate node.

[0067] In other embodiments, multiple evaluation factors for each candidate node can be weighted and summed according to preset weights, and the result of the weighted sum can be used as the successor index of the candidate node. The preset weights are used to characterize the relative importance of different evaluation factors in the overall score, and can be pre-defined according to business strategies to achieve multi-objective comprehensive optimization.

[0068] In some embodiments, the weighting coefficients of the evaluation factors for each node can be adjusted based on the departure time of the ride-sharing order. The weighted sum of the evaluation factors for each node, based on the adjusted weighting coefficients, yields the relayability index for each candidate node. The departure time characterizes whether the order's departure time is during the day, night, peak, or off-peak hours. For example, the weight of node parking safety is increased during nighttime, and the weight of the node's traffic congestion index is increased during peak hours. Since the actual impact of each evaluation factor varies across different time periods, fixed weights can lead to evaluations deviating from reality, while dynamically adapting to time period characteristics can improve the accuracy of the relayability index.

[0069] In some embodiments, historical relay success rate data for each candidate node within multiple historical time windows can also be obtained; based on the estimated arrival time of ride-sharing orders at each candidate node, corresponding historical success rate factors are extracted from the historical relay success rate data; multiple node evaluation factors are fused with the historical success rate factors to obtain the relayability index for each candidate node. The historical success rate factor is used to characterize the frequency with which the node has been successfully selected as a relay node under the same or similar time windows. Simply relying on real-time static factors cannot reflect the historical performance of a node and may repeatedly select nodes that have frequently failed in the past. By introducing historical experience data, this problem can be effectively avoided.

[0070] In some embodiments, the node with the highest successor index among multiple candidate nodes is selected as the successor node.

[0071] In some embodiments, the relay index of each candidate node can be compared, and the candidate node with the largest index can be selected as the relay node. If there are two or more candidate nodes with the largest relay index, the one with the shortest final journey distance can be selected as the relay node. The final journey distance is used as a secondary selection condition to improve the efficiency of the passenger's journey after transfer.

[0072] In other embodiments, historical relay success rate data for each candidate node within multiple historical time windows can be obtained; based on the estimated arrival time of ride-sharing orders at each candidate node, the predicted relay success rate of each candidate node is extracted from the historical relay success rate data; the relayability index of each candidate node is fused with the corresponding predicted relay success rate to obtain a comprehensive score; and the candidate node with the highest comprehensive score is selected as the relay node. The predicted relay success rate is used to characterize the probability that the node will actually complete the relay within a future arrival time window, based on historical data. The fusion method may include, but is not limited to, multiplication or addition. Nodes with high current relayability index but low historical actual success rate may perform poorly due to unforeseen factors (such as frequent congestion or seasonal capacity shortages). Therefore, correcting the current score based on historical success rates helps improve decision robustness.

[0073] In some embodiments, the second capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity. Ride-sharing capacity is used to represent carpooling services provided by private car owners whose routes overlap with the final segment of the order. Taxi capacity is used to represent paid transportation services provided by ride-hailing platforms or taxi companies that offer immediate response. Public transportation capacity is used to represent buses or rail transit operating on fixed routes and schedules.

[0074] In some embodiments, availability indices for various secondary capacity options are calculated for each candidate node. The availability index characterizes the feasibility of a particular capacity pattern successfully matching and completing the final leg of the journey at a specific candidate node.

[0075] In some embodiments, if the availability indices of multiple secondary transportation modes corresponding to the node with the highest transferability index do not meet the preset availability conditions, the node with the highest transferability index among the candidate nodes whose availability indices of multiple secondary transportation modes meet the preset availability conditions can be selected as the transfer node. The preset availability conditions are used to indicate that at least one of each transportation mode is available (e.g., the availability index of taxi transportation is greater than 0.5, or there are bus services within the expected time). The node with the highest transferability index may have all its secondary transportation modes unavailable (e.g., no buses at night, no ridesharing nearby, excessively high taxi fares). Selecting this node would prevent the final leg of the journey. Therefore, by adding transportation availability constraints to the node score, it is possible to ensure that the selected node has feasible transfer conditions in practice.

[0076] In some embodiments, candidate nodes can be traversed in descending order of their availability index. For each traversed candidate node, it is determined whether the availability indices of the various secondary transportation modes corresponding to that node all meet preset availability conditions. The first candidate node that meets the preset availability conditions is selected as the relay node. The preset availability conditions characterize that each secondary transportation mode has at least one available option. For example, the availability index of taxi service is greater than 0.5, or public transportation has operating services within the expected transfer time window.

[0077] In other embodiments, candidate nodes whose availability indices for various secondary transportation modes all meet preset availability conditions can be selected from multiple candidate nodes to form an available node set. If the available node set is not empty, the candidate node with the highest relay index is selected as the relay node. If the available node set is empty, at least one threshold in the preset availability conditions is lowered, and the nodes are re-selected. The candidate node with the highest relay index in the re-selected available node set is then selected as the relay node. Lowering the threshold indicates that the requirements are relaxed when the strict conditions are unsolvable. For example, the ride-hailing availability index is lowered from 0.5 to 0.3, or only one transportation mode is allowed to be available. By introducing this condition relaxation mechanism, a relatively optimal relay node can be selected even in extreme cases.

[0078] In some embodiments, if the availability index of at least one mode among the various availability indices of the secondary capacity corresponding to a relay node is lower than a preset availability condition, a relay node reselection can be triggered. During the reselection process, a comprehensive relay index for each candidate node is calculated based on the lowest value among the relayability index and the availability index corresponding to each candidate node. The candidate node with the highest comprehensive relay index is selected as the new relay node. The lowest value among the availability indices is used to characterize the availability of the weakest capacity mode of the node. The comprehensive relay index is used to characterize the comprehensive score considering both the overall evaluation of the node and the capacity availability weakness. This mechanism can avoid selecting a node with extremely low availability of a certain capacity while other aspects are normal, because once the weak mode is selected as the secondary capacity, the actual matching success rate will drop significantly. Through this weakness penalty mechanism, the system is guided to prioritize relay nodes with better capacity balance.

[0079] S203: The ride-sharing order is split into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination.

[0080] Highway segment orders represent the portion of the journey executed by the first vehicle from the origin to the relay node, with the route covering highways or expressways. Terminal segment orders represent the portion of the journey executed by the second vehicle from the relay node to the destination, with the route covering urban roads or terminal side streets. The purpose of splitting ride-sharing orders is to divide a journey that would originally be completed by a single vehicle into two logically independent but temporally related sub-journeys, so as to match different types of vehicles accordingly.

[0081] In some embodiments, the original route of a ridesharing order can be divided into a first segment and a second segment, using the relay node as the dividing point. The first segment serves as the route for the high-speed segment sub-order, and the second segment as the route for the final segment sub-order. Independent sub-order identifiers can be generated for both the high-speed segment and the final segment sub-order, and these two sub-order identifiers are associated with and bound to the parent order identifier of the ridesharing order. The sub-order identifier uniquely identifies a sub-trip within the system. The parent order identifier assigns two sub-orders to the same passenger and the same travel request. Through the combination of independent sub-order identifiers and a shared parent order identifier, unified tracking of the overall trip can be maintained while matching different transportation capacities.

[0082] In other embodiments, a transfer connection area can be defined centered on the relay node. The transfer connection area represents a geographically continuous space encompassing the relay node and its surrounding walkable area, within which passengers can safely disembark and walk to another boarding point. The endpoint of a highway segment order can be set as a stop within the transfer connection area; the starting point of the final segment order can be set as a boarding point within the transfer connection area; the walking distance between the stop and boarding points does not exceed a preset walking threshold. The preset walking threshold represents the maximum distance a passenger is willing to walk for the transfer, for example, 200 to 500 meters. The stop and boarding points can be different specific locations within the transfer connection area, such as a highway exit stop and an adjacent bus stop. Since the relay node is a point coordinate, and the actual transfer requires passengers to walk from a specific disembarkation point to a specific boarding point, the transfer is not feasible if the distance between the two points is too far. Therefore, by defining a transfer area and setting an upper limit on the walking distance, the spatial feasibility of the transfer can be ensured, avoiding transfer failure due to the distance between the stop and boarding points being too far.

[0083] In some embodiments, the arrival time window for the high-speed segment and the departure time window for the final segment can be calculated based on the estimated travel time of the high-speed segment and the final segment, respectively. These two windows are then set to overlap at the relay node, with the overlap period being longer than a preset transfer time. Based on these time windows, time-constrained high-speed segment sub-orders and final segment sub-orders are generated. The arrival time window for the high-speed segment order and the departure time window for the final segment order are calculated based on their estimated travel time. The estimated travel time can be calculated based on the mileage of the planned route and the historical average speed of that segment. The arrival time window characterizes the time interval within which the high-speed segment sub-order may arrive at the relay node. The departure time window characterizes the time interval within which the final segment sub-order should depart from the relay node. The overlapping period characterizes the portion of the time window that is shared by both time windows on the time axis. The preset transfer time characterizes the reasonable time required for a passenger to disembark, walk to the boarding point, wait for the final segment's capacity, and complete boarding. For example, 5 to 15 minutes. If the arrival time window of the high-speed segment does not overlap with the departure time window of the final segment, or the overlap is insufficient, passengers may experience long waits or be left waiting empty after the final segment's capacity arrives early. Therefore, setting overlapping time windows ensures smooth transfers in terms of time and reduces passenger waiting time.

[0084] Specifically, the end time of the arrival time window and / or the start time of the departure time window can be adjusted to create an overlapping interval on the timeline, with the length of the overlapping interval exceeding the preset transfer time. The end time of the arrival time window represents the latest arrival time of the high-speed segment order at the relay node. The start time of the departure time window represents the earliest departure time of the final segment order from the relay node. Adjustment methods may include, but are not limited to: postponing the start time of the final segment departure time window (allowing the final segment capacity to arrive slightly later), or advancing the end time of the high-speed segment arrival time window (requiring the first capacity to arrive as punctually or early as possible), or adjusting both simultaneously. Since the original time windows may not naturally overlap, proactive adjustment allows the system to intervene in the time windows to meet transfer requirements.

[0085] Furthermore, based on the historical transfer time distribution data of the relay nodes, the minimum overlap time required under the preset transfer success rate can be calculated. The historical transfer time distribution data includes the walking time distribution of passengers from the high-speed section drop-off point to the final section pick-up point, and the waiting time distribution of passengers waiting for the final segment of the transport. Based on the position and speed of the first transport segment during its high-speed journey, the first probability time interval for arriving at the relay node is predicted; the second probability time interval for the second transport segment to arrive at the relay node is obtained; the arrival time window and departure time window are adjusted so that the overlap length of the probability time intervals is greater than the minimum overlap time. The walking time distribution is used to characterize the statistical time taken for different passengers to complete walking transfers under different conditions. The waiting time distribution is used to characterize the statistical waiting time required for the final segment of the transport segment to arrive at the relay node. The preset transfer success rate is used to characterize the desired transfer success probability, such as 95%. The minimum overlap time is used to characterize the time buffer length required to achieve the preset success rate under a given historical distribution. Both the first and second probability time intervals can be expressed using a normal distribution or interval estimation method. Arrival and departure time windows can be adjusted so that the overlap between the first and second probability time intervals is greater than the minimum overlap duration. Static, fixed transfer time assumptions cannot adapt to fluctuations in actual transfer times at different nodes and time periods. Dynamically calculating the required overlap duration based on historical data and dynamically adjusting it in conjunction with real-time predicted probability time intervals can significantly improve the robustness and success rate of transfer connections.

[0086] S204: Match the first transport capacity to the high-speed segment order.

[0087] The first capacity is used to characterize the transport entity undertaking the journey from the origin to the relay node. This transport entity has the capability to travel on highways and is willing to complete this segment of the journey. The matching process for the first capacity can be based on the journey constraints of the highway segment orders and the travel routes and time windows of the capacity providers.

[0088] The fundamental reason why first-tier transportation companies are unwilling to enter cities to reach the final destination of orders is not a lack of subjective willingness, but rather the objective economic and inefficient nature of the journey. From the perspective of the drivers' travel purpose, first-tier transportation companies are essentially transit drivers; their core task is to travel from the departure city to another long-distance destination, and the passenger's final destination city is merely a stop along the way. The driver's original route is fixed, and any deviation from this route into the city will increase mileage, time, and fuel consumption, seriously disrupting their overall travel arrangements. Specifically, if first-tier transportation companies are required to deliver passengers to a specific destination within the city, the driver must execute a complete detour sequence: exiting the highway, entering the city's main roads, navigating through the city's side streets, delivering the passenger, and then returning to the highway entrance. City roads have low speed limits, numerous traffic lights, and frequent congestion, and completing this round trip usually takes an additional 30 to 60 minutes or even longer.

[0089] Furthermore, the driver's final destination is often located downstream from the city; entering and then exiting the city means deviating from the intended route and then turning back, significantly delaying the entire journey. By setting up a relay point at the highway exit to drop off passengers, the first transport vehicle can continue its original journey without entering the city, fundamentally avoiding all the aforementioned costs. Passengers then complete the final leg of their journey from the relay point to the destination using a pre-matched second transport vehicle.

[0090] Therefore, the strict requirement of "always along the route" is relaxed to "always along the highway," thereby freeing up a large amount of transit capacity that was previously excluded due to the "last leg into the city." The relay point can be a location that the first vehicle can reach without deviating from the main highway. After dropping off passengers there, the first vehicle can directly return to the highway via a dedicated U-turn ramp or connecting road to continue its journey, without entering the city's internal road network. This completely eliminates the extra cost of entering the city, which is the most fundamental difference from existing ride-sharing matching models.

[0091] In some embodiments, the first capacity includes ride-sharing capacity. Ride-sharing capacity is used to characterize non-commercial passenger transport services provided by private car owners for the purpose of sharing travel costs, where the vehicles are registered as small passenger cars and the owners have valid driver's licenses and vehicle insurance. Ride-sharing capacity is characterized by routes planned by the car owners themselves, with passengers only taking a portion of the route that is convenient for them.

[0092] In some embodiments, a first transport capacity can be matched for the high-speed segment order.

[0093] It can retrieve the origin, destination, and estimated departure time window for highway segment orders. The origin represents the geographical location of the departure point for the highway segment, the destination represents the geographical location of the relay node, and the estimated departure time window represents the time range within which passengers expect to depart.

[0094] In some embodiments, drivers whose routes pass through the origin and destination of the highway segment order and whose departure times overlap with the expected departure time window can be retrieved from online ride-sharing drivers. "Route passing through" indicates that the driver's planned route completely covers the segment from origin to destination. "Departure time overlap" indicates that the driver's planned departure time falls within or intersects with the passenger's expected departure time window. The retrieved ride-sharing drivers are used as candidate first-line drivers, and one is selected as the first-line matching driver. Filtering based on the two core criteria of route coverage and time matching ensures that the matched driver can actually perform the highway segment trip.

[0095] In other embodiments, it is also possible to retrieve passing rideshare drivers whose routes completely cover the section from the start to the end of the highway rideshare order, and whose end point is located within a preset distance downstream of the relay node. "Downstream" represents the road section after passing the relay node along the driving direction. The preset distance range is, for example, 10 km to 30 km, to ensure that the driver's original destination is not near the relay node, but further away, thus identifying them as passing drivers. For each retrieved passing rideshare driver, the additional driving distance by which their original route deviates from the end point of the highway rideshare order can be calculated. The additional driving distance represents the additional mileage required for the driver to turn from their original route to the relay node and then return to their original route. Passing rideshare drivers with additional driving distances less than a preset deviation threshold can be selected as candidate first-line drivers. The preset deviation threshold is, for example, 3 km to 8 km. The driver with the smallest additional driving distance from the candidate first-line drivers can be selected as the matched first-line driver. The core reason why passing drivers are unwilling to exit the highway is that the cost of detouring is too high. By quantifying the cost of detouring and selecting the driver with the lowest cost, we can prioritize matching drivers who take the shortest detour on the highway, thereby freeing up previously unavailable transport capacity.

[0096] In some embodiments, drivers who have completed trips from the origin area to the pick-up node area within a preset time period can be identified from historical ride-sharing data, forming a historical capacity set. The preset time period is, for example, 30 to 90 days. This preset time period ensures the timeliness of the data. The origin area and the pick-up node area are areas centered on the origin and pick-up node with a preset radius, respectively. For example, the preset distance is 5-10 kilometers. Drivers currently online whose estimated departure time overlaps with the estimated departure time window can be selected from the historical capacity set. Drivers are sorted from highest to lowest based on the number of historical trips completed, and the driver with the highest ranking is determined as the first matching capacity. The number of historical trips characterizes the driver's familiarity with the route and past willingness to accept orders. Newly registered drivers or drivers unfamiliar with the route may refuse orders or have low fulfillment rates. Utilizing historical behavioral data to select experienced drivers for the route can improve the matching success rate and fulfillment reliability of highway segment orders.

[0097] S205: Match the second transport capacity for the last segment sub-order.

[0098] The second capacity refers to the transportation entity responsible for the journey from the relay node to the destination. This entity is capable of traversing the final segment of urban roads or side streets and delivering passengers to their destination. The matching process for the final segment sub-orders can be based on a comprehensive decision-making process considering the spatiotemporal constraints of the final segment, the real-time supply status of each capacity mode, and passenger preferences.

[0099] In some embodiments, the second capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity.

[0100] Ride-sharing capacity represents carpooling services provided by private car owners, where the route overlaps with the final leg of the ride. It has lower costs, but the matching success rate is limited by the supply of car owners. Taxi-hailing capacity represents on-demand transportation services provided by ride-hailing platforms or taxi companies. It offers high certainty but is relatively expensive. Public transportation capacity represents buses or rail transit operating on fixed routes and schedules. It has the lowest cost, but its flexibility and timeliness are limited by the timetable. By introducing these three complementary capacity modes, the system can adapt to different distances, time periods, and cost sensitivities, improving its resilience.

[0101] In some embodiments, an availability index can be calculated for each type of second capacity. The availability index is used to characterize the overall score of a certain capacity mode's ability to successfully match and complete the final segment of the journey under the current spatiotemporal conditions. The higher the score, the more suitable the mode is for the current final segment sub-order.

[0102] In some embodiments, the availability index for each second mode of transportation can be calculated based on at least one of several capacity evaluation factors for each type of second mode of transportation. These capacity evaluation factors include terminal journey distance, terminal capacity supply density, estimated waiting time, and passenger capacity preference. Terminal journey distance characterizes the remaining travel distance from the relay node to the destination; a shorter distance imposes fewer restrictions on the mode of transportation. Terminal capacity supply density characterizes the number or frequency of available modes of transportation within a preset range around the relay node. Estimated waiting time characterizes the estimated time required for a passenger to board the transportation service from arrival at the relay node. Passenger capacity preference characterizes the passenger's historical preference for different modes of transportation, such as a preference for ridesharing or taxis. Through multi-factor evaluation, the availability index can more comprehensively reflect actual matching conditions.

[0103] In some embodiments, one of the multiple capacity evaluation factors can be directly used as the availability index for each second capacity. For example, only the terminal capacity supply density can be used as the availability index, or only the reciprocal of the expected waiting time can be used as the availability index.

[0104] In other embodiments, multiple capacity evaluation factors can be weighted and summed according to preset weights, and the result of the weighted sum can be used as the availability index of each second capacity. Preset weights are used to characterize the relative importance of different evaluation factors; for example, the weight for the final journey distance is 0.2, the weight for supply density is 0.4, the weight for estimated waiting time is 0.3, and the weight for passenger preference is 0.1. Differentiated evaluation can be achieved through weight configuration to adapt to different business strategies.

[0105] In some embodiments, the weighting coefficients of each capacity evaluation factor can be determined based on the distance interval to which the final trip distance belongs, and the capacity evaluation factors can be fused to obtain the availability index for each type of second capacity. The distance interval is used to divide the final trip distance into short distances (e.g., less than 5 kilometers), medium distances (e.g., 5 to 15 kilometers), and long distances (e.g., greater than 15 kilometers). For example, the short distance interval increases the weighting of the supply density of ride-hailing capacity, while the long distance interval increases the weighting of the final trip distance of carpooling capacity. The influence of each factor differs under different distance intervals; fixed weights can lead to evaluation distortion, while dynamically adapting the distance interval can make the availability index more closely reflect actual scenarios.

[0106] In some embodiments, historical fulfillment rate data for each second capacity within multiple historical time windows can also be obtained. The historical fulfillment rate characterizes the proportion of successful completion of the final segment of the journey by that capacity mode within a past time window. Based on the time period of the final segment sub-order, the predicted fulfillment rate for each second capacity can be extracted from the historical fulfillment rate data. The predicted fulfillment rate characterizes the actual fulfillment probability of that capacity mode in the current time period, inferred from historical data. Based on the predicted fulfillment rate, the final segment capacity supply density of each second capacity can be corrected. Correction methods may include, but are not limited to, multiplying the original supply density by the predicted fulfillment rate to obtain the corrected effective supply density. Based on the final segment journey distance, the corrected supply density, the estimated waiting time, and passenger capacity preferences, an availability index for each second capacity can be determined. The final segment journey distance and estimated waiting time are negatively correlated with the availability index, for example, by taking the reciprocal or a negative exponent. The corrected supply density and passenger capacity preferences are positively correlated with the availability index, for example, by taking a positive number or a multiple. The final index is obtained by fusing multiple parameters; the fusing method will not be elaborated here.

[0107] In some embodiments, the mode priority of each secondary transportation mode can be determined based on at least one of the time period of the last segment sub-order, the capacity supply during that time period, and the passenger's historical capacity preference profile. Mode priority characterizes the recommendation order among different capacity modes; a higher priority indicates a greater tendency to match that mode. Based on this, an availability index for each secondary transportation mode is calculated based on its mode priority and at least one of multiple capacity evaluation factors. For example, mode priority can be multiplied as an additional weighting factor in the availability index calculation.

[0108] In some embodiments, the priority of each type of secondary transportation mode can be determined based on one of the following: the time period of the last sub-order, the capacity supply during that time period, and the passenger's historical capacity preference profile. For example, priority can be determined solely based on the time period (ride-hailing > carpooling > public transportation during late night hours), or solely based on capacity supply (those with higher supply density take precedence).

[0109] In other embodiments, the priority of each secondary transportation mode can be determined based on the fusion results of multiple factors, including the time period of the final sub-order, the available capacity during that time period, and the passenger's historical capacity preference profile. Fusion methods include weighted voting, product scoring, or ranking fusion to improve the robustness and personalization of priority decisions.

[0110] In some embodiments, the historical average matching success rate and historical average fulfillment time of each second capacity under the time period of the final segment sub-order can also be extracted from historical relay data. The historical average matching success rate is used to characterize the proportion of available capacity successfully found after a certain capacity mode initiates a matching within that time period. The historical average fulfillment time is used to characterize the average time taken for that capacity mode to complete the final segment of the trip within that time period. The supply fluctuation coefficient is determined based on the comparison between the supply density of the final segment capacity under that time period and the supply density of the same period in history. For example, the ratio is obtained by dividing the current supply density by the density of the same period in history. The preference coefficient can be determined based on the deviation between the historical acceptance rate of each second capacity in the passenger's historical capacity preference profile and the historical acceptance rate of all second capacity. The preference coefficient is positively correlated with the deviation, that is, the larger the deviation, the stronger the preference. The matching success rate can be predicted based on the fusion result (e.g., multiplication) of the historical average matching success rate and the supply fluctuation coefficient. The fulfillment efficiency can be predicted based on the comparison result of the historical average fulfillment time and the supply fluctuation coefficient (e.g., historical average fulfillment time divided by the supply fluctuation coefficient). The matching success rate, fulfillment efficiency, and preference coefficient can be comprehensively ranked, with the matching success rate as the primary ranking key and fulfillment efficiency as the secondary ranking key, to determine the mode priority of each secondary transportation capacity. By combining historical statistics and real-time fluctuations for prediction, the priority can reflect the current actual situation.

[0111] In some embodiments, the second capacity with the highest availability index can be matched to the last-segment sub-order.

[0112] In some embodiments, the capacity mode corresponding to the one with the highest availability index can be selected as the second capacity mode for matching; if there are two or more capacity modes with the highest availability index, the one with the shortest expected waiting time is selected as the second capacity mode for matching.

[0113] In other embodiments, the estimated first arrival time of the first transport vehicle at the relay node and the estimated second arrival time of each second transport vehicle at the relay node can also be obtained. The first time can be calculated based on the position and speed of the first transport vehicle, and the second time can be calculated based on the position and speed of the second transport vehicle. The time difference between the second time and the first time for each second transport vehicle can be calculated. The time difference is used to characterize the proximity of the arrival time of the second transport vehicle at the relay node to that of the first transport vehicle; the smaller the absolute value, the tighter the connection. The connection coefficient of each second transport vehicle can be determined based on the time difference. The connection coefficient is negatively correlated with the absolute value of the time difference, that is, the smaller the time difference, the larger the connection coefficient. The availability index of each second transport vehicle can be adjusted (e.g., multiplied) using the connection coefficient to obtain the connection availability index. The second transport vehicle with the highest connection availability index is selected. By introducing a time connection factor, the smoothness of transfers can be optimized, avoiding situations where the availability index is high but the time is mismatched.

[0114] In some embodiments, the second capacity modes can be sorted in descending order of availability index to generate a candidate sequence. Matching requests can be sent sequentially to the capacity providers corresponding to each second capacity mode in the candidate sequence, with a response waiting time set (e.g., 30 to 60 seconds). If the matching request for the current second capacity mode is confirmed within the response waiting time, that second capacity mode can be identified as the matched second capacity mode, and subsequent requests are terminated. If the matching request for the current second capacity mode is not confirmed or is rejected within the response waiting time, a matching request can be sent to the next second capacity mode in the candidate sequence. Capacity matching is uncertain; even with a high availability index, no one may accept the order. A serial confirmation mechanism ensures actual matching, avoiding paper-based matching failures caused by relying solely on index calculations.

[0115] S206: Perform unified fulfillment status tracking and trip management for the high-speed segment orders and the final segment orders.

[0116] In some embodiments, independent sub-order statuses can be maintained for the high-speed segment sub-orders and the terminal segment sub-orders, and the sub-order statuses include pending departure, in progress, completed, and cancelled; when the status of any sub-order changes, the overall status of the parent order is updated synchronously; the status information of the two sub-orders and their corresponding capacity information are displayed simultaneously in the parent order management interface.

[0117] The "Pending Departure" status indicates that a sub-order has been matched with available transportation capacity, but the trip has not yet started. The "In Progress" status indicates that the transportation capacity has departed and is currently in operation. The "Completed" status indicates that the transportation capacity has delivered the passenger to the destination of the sub-order. The "Cancelled" status indicates that the sub-order was terminated due to an abnormal reason. When the status of any sub-order changes, the overall status of the parent order is updated synchronously. The overall status of the parent order (ridesharing order) represents the overall completion progress of the intercity travel order, which depends on the combination of the statuses of the two sub-orders (e.g., the parent order is completed when both sub-orders are completed). The status information of both sub-orders and their corresponding transportation capacity information can be displayed simultaneously in the parent order management interface. The transportation capacity information includes transportation capacity type, license plate number, and driver contact information. Since the two sub-orders are matched with different transportation capacities, without unified tracking, passengers and the platform cannot know the overall trip progress. By maintaining independent sub-order statuses and aggregating and displaying them at the parent order level, a balance between divide and conquer and overall overview is achieved.

[0118] In some embodiments, the location of the first vehicle in the high-speed segment order can be obtained; it can be determined whether the distance between the location and the relay node is less than a preset arrival threshold; if it is less than the preset arrival threshold, the status of the high-speed segment order is marked as about to arrive, and the status of the last segment order is triggered to switch from waiting to depart to waiting to pick up; when the second vehicle of the last segment order completes the trip and delivers the passenger to the destination, the status of both the high-speed segment order and the last segment order is marked as completed, and a completion record of the parent order is generated.

[0119] The real-time location is obtained periodically through the terminal equipment held by the first transport vehicle. It is determined whether the geographical distance between this real-time location and the relay node is less than a preset arrival threshold, which indicates that the vehicle is approaching the relay node. The preset arrival threshold is, for example, between 200 and 500 meters. If it is less than the preset arrival threshold, the status of the highway segment sub-order is marked as "approaching," and the status of the final segment sub-order is switched from "awaiting departure" to "awaiting pickup." The "awaiting pickup" status indicates that the second transport vehicle should prepare to go to the relay node to wait for passengers. When the second transport vehicle of the final segment sub-order completes its journey and delivers the passenger to the destination, the status of both the highway segment sub-order and the final segment sub-order are simultaneously marked as "completed," and a completion record for the parent order is generated. The completion record includes fields such as actual completion time, mileage, and transfer time. The status switching of the two sub-orders needs to be time-sequentially linked based on location events; otherwise, the highway segment may end prematurely before the passenger arrives or the final segment may be triggered late. Therefore, through a location-triggered status linkage mechanism, the sub-order status can be strictly synchronized with the actual journey progress.

[0120] In some embodiments, a trip time sequence chain with the parent order as the granularity can also be constructed. This chain represents the sequence of nodes along the timeline of the entire intercity trip, including highway segment trip nodes, transfer window at relay nodes, and final segment trip nodes. Highway segment trip nodes represent the departure and arrival times of the highway segment sub-orders. Transfer window at relay nodes represents the start and end times of the passenger's transfer at the relay node, with the window length representing the preset transfer duration. Final segment trip nodes represent the departure and arrival times of the final segment sub-orders.

[0121] The system can monitor the fulfillment status of each node, indicating whether the node is executing as planned. If the estimated arrival time of a highway segment order at the relay node is later than the end time of the transfer window, a delayed pick-up notification is sent to the second capacity of the last segment order, and the estimated departure time of the last segment order is updated. The delayed pick-up notification includes the new estimated arrival time. If the second capacity of the last segment order fails to arrive at the relay node within the transfer window, a transfer anomaly alert can be pushed to the passenger terminal, and the rematching process for the last segment order can be activated. The transfer anomaly alert informs the passenger that the current second capacity may be delayed, and asks the passenger to wait at the relay node or prepare an alternative plan. Single status tracking cannot reflect deviations and anomalies on the timeline. By constructing the timeline and monitoring node fulfillment, trip deviations can be detected in advance and adaptively adjusted, improving the success rate of relays.

[0122] In some embodiments, a total fare to be paid for the ride-sharing order can be generated, and a one-time payment confirmation for the total fare to be paid can be received from the passenger.

[0123] The total amount to be paid represents the total amount a passenger needs to pay to complete the entire trip from origin to destination, covering the full cost of both the highway segment and the final segment. A one-time payment confirmation indicates that the passenger authorizes payment for the total cost of the entire intercity trip when posting a rideshare order or before departure, eliminating the need for separate payments for the highway and final segments, or switching between different payment interfaces. The total amount to be paid for a rideshare order can be pre-calculated based on the planned mileage from origin to destination and the respective capacity pricing rules for the highway and final segments.

[0124] After the system generates the total fare to be paid, it can push a payment confirmation request to the passenger's app, containing the total fare amount, pricing details, and payment deadline. Upon receiving the request, the passenger's app displays the total fare to be paid and available payment channels (such as third-party payment platforms, bank card payments, or account balance payments) on the payment interface. After the passenger selects a payment channel and completes identity verification (such as entering a payment password, fingerprint verification, or facial recognition), the passenger's app generates a payment instruction and sends it to the server. Upon receiving the payment instruction, the server calls the corresponding payment channel's interface to initiate the deduction. After receiving a success receipt from the payment channel, the server marks the order as paid and pushes a payment success notification to the passenger's app.

[0125] Based on the actual mileage and time taken for the highway segment of the ride, a first share can be allocated from the total price of the ride-sharing order as the share due to the highway segment's transportation provider. The actual mileage and time are obtained through the trajectory recording and timing of the first transportation segment. Based on the actual transportation mode used and the actual mileage taken for the final segment of the ride, a second share can be allocated from the total price of the ride-sharing order as the share due to the final segment's transportation provider. The actual transportation mode used may be ride-sharing, taxi, or public transportation, with different pricing methods corresponding to different modes. The first and second shares can be issued to the respective transportation providers' accounts. Passengers only need to pay once, perceiving it as a single order and a single trip. The platform's backend automatically splits and distributes the payments, maintaining a complete order experience externally and automating multi-party settlement internally.

[0126] In some embodiments, after receiving a one-time payment confirmation from the passenger for a ridesharing order, a first reserved share and a second reserved share can be pre-locked from the total price of the ridesharing order, but not actually allocated yet. The first reserved share corresponds to the estimated cost of the highway segment order, and the second reserved share corresponds to the estimated cost of the final segment order. During the execution of the highway segment order, the actual trajectory of the first transportation capacity is monitored in real time. If the deviation between the actual mileage and the planned mileage exceeds a preset deviation threshold (e.g., ±15%), the locked amount of the first reserved share is dynamically adjusted. During the execution of the final segment order, the locked amount of the second reserved share is dynamically adjusted according to the actual transportation mode used by the second transportation capacity (e.g., downgrading from ridesharing to taxi). After both sub-orders are completed, the adjusted first reserved share is issued as the actual first share to the highway segment transportation capacity provider, and the adjusted second reserved share is issued as the actual second share to the final segment transportation capacity provider. If either sub-order is canceled midway through execution, the reserved share corresponding to that sub-order is released and returned to the passenger, and the executed portion is charged proportionally and then issued. By using dynamic locking and adjustment mechanisms, the final allocation amount is matched with the actual execution, thereby improving the fairness and flexibility of settlement.

[0127] In some embodiments, the method further includes updating multiple relay evaluation factors for each candidate node after the ride-sharing order is completed.

[0128] This allows you to obtain the actual relay nodes used for this ridesharing order, the actual driving distance of the highway segment, the actual transfer waiting time for the final segment, and the passenger's rating score for the trip. The actual relay nodes identify the final transfer point used for this order. The actual driving distance represents the distance traveled by the first vehicle from the origin to the relay node. The actual transfer waiting time represents the time between the passenger arriving at the relay node and the arrival and boarding of the second vehicle. The rating score represents the passenger's satisfaction rating for this ridesharing experience (e.g., 1 to 5 points).

[0129] The historical success rate parameter of the relay node can be adjusted based on the actual transfer waiting time and passenger evaluation scores. The historical success rate parameter characterizes the proportion of successful relays completed at that node over a past period. One adjustment method is to increase this parameter when the transfer waiting time is below a preset satisfaction threshold and the evaluation score is above a preset high score threshold, and vice versa. The highway detour distance parameter of the relay node can be adjusted based on the deviation between the actual and planned travel distances. The highway detour distance parameter characterizes the additional mileage required for the first transport vehicle to deviate from the original route to reach the node. Adjustment methods may include, but are not limited to, incorporating the actual deviation value into the original parameter using exponential smoothing. The adjusted parameters can be stored in a database for use in calculating relay node scores for subsequent orders.

[0130] It can also obtain the time-series data of capacity supply for each candidate node during the execution of this ridesharing order. Each candidate node includes the actual relay node used and nodes along the route that were not selected. The time-series data of capacity supply is used to characterize the sequence of changes in the available quantity of each capacity mode around each candidate node over time within a preset time window before and after the departure time of this order. The time-series data of capacity supply can be fused with the historical capacity supply curves of each candidate node to update the capacity supply density of each candidate node at different times. The fusion method can be, but is not limited to, weighted average, with new data having a higher weight than historical data.

[0131] The system can obtain the actual walking distance and transfer time of passengers at each transfer node during this trip, and update the transfer convenience parameter of that transfer node. The transfer convenience parameter is used to characterize the ease of walking from the high-speed section drop-off point to the final section pick-up point. One calculation method is to find that the reciprocal of the transfer convenience parameter is negatively correlated with the weighted sum of the transfer walking distance and transfer time.

[0132] Alternatively, after passengers complete a one-time payment for the parent order, corresponding shares can be allocated from the total price of the parent order to the accounts of the highway segment and the final segment capacity provider, respectively, based on the fulfillment status of the highway segment and the final segment sub-orders. The allocation shares are calculated based on the actual mileage completed and the actual capacity mode used. During this allocation process, a first ratio of the actual completed mileage to the expected mileage for the highway segment sub-orders and a second ratio of the actual completed mileage to the expected mileage for the final segment sub-orders are recorded. The first ratio characterizes the deviation of the actual mileage traveled on the highway segment from the planned mileage. The second ratio characterizes the deviation of the actual mileage traveled on the final segment from the planned mileage.

[0133] The correction coefficient for the high-speed detour distance parameter of the corresponding relay node can be updated based on the first ratio. The correction coefficient is used to adjust the baseline value of the detour distance in subsequent calculations. When the first ratio is greater than 1, the correction coefficient is increased (indicating that the actual detour is longer than expected), and when it is less than 1, the correction coefficient is decreased.

[0134] The correction factor for the final leg distance parameter of the corresponding relay node can be updated based on the second ratio. The stability score of the relay node is updated according to whether any abnormal refunds or disputes occur during the allocation process. The stability score characterizes the frequency of disputes at the node during settlement; a dispute lowers the score. Actual mileage deviations and settlement disputes reflect issues with the node's planning accuracy or service quality. By correcting node parameters using mileage ratios and dispute records, the evaluation system can encompass information from the economic execution level.

[0135] In some embodiments, the method further includes updating the relayability index of each candidate node based on the updated relay evaluation factors of each candidate node.

[0136] The updated relay evaluation factors can be re-weighted and summed according to preset weights, and the result of the re-weighted summation can be used as the updated relay index for the candidate node. The preset weights can be consistent with the weights used in the initial calculation to ensure comparability before and after.

[0137] For each candidate node, the rate of change of each relay evaluation factor after the update compared to the corresponding factor before the update can also be calculated. The rate of change is used to characterize the degree of fluctuation of a single factor in this update. One calculation formula is (new value minus old value) divided by the absolute value of the old value.

[0138] The update magnitude of the successorability index for a candidate node can be determined based on the rate of change, with the update magnitude being positively correlated with the absolute value of the rate of change. A historical successorability index sequence for the candidate node can be obtained, representing the trajectory of the node's successorability index changes over past updates. If the trend of the historical successorability index sequence indicates that the node's successorability index has been continuously decreasing over a predetermined number of times (e.g., 3 times), a decay coefficient (e.g., 0.5) is applied to the update magnitude. This decay coefficient is used to suppress excessive penalties for continuously decreasing nodes, preventing underestimation due to short-term fluctuations. The updated successorability index can be obtained by adding the update magnitude after applying the decay coefficient to the previous successorability index. Simply updating based on the current rate of change may lead to drastic fluctuations in node scores, especially for historically stable nodes where a single anomaly should not have a significant impact. Therefore, by introducing historical trends and a decay mechanism, the update process can be smoothed, improving the stability of the successorability index.

[0139] In some embodiments, during high-speed travel, the relay availability index of each unpassed candidate node and the availability index of various second-capacity transport corresponding to each unpassed candidate node can be updated. Unpassed candidate nodes represent candidate relay node locations that have not yet been passed along the planned route from the current position of the first-capacity transport. Static, pre-calculated node scores and capacity availability can deviate during trip execution due to real-time traffic and supply changes; using old data may lead to suboptimal decisions. Therefore, dynamic updates during the trip ensure that relay decisions are always based on the latest information, improving the accuracy of subsequent adjustments.

[0140] In some embodiments, the terminal capacity supply density and node traffic congestion index of each unvisited candidate node can be reacquired at preset time intervals. The preset time interval can be, for example, 1 to 5 minutes, to balance real-time performance and computational overhead. Terminal capacity supply density represents the number of ridesharing, express, or bus stops available within a preset range around the node at the current time. The node traffic congestion index represents the real-time traffic conditions of roads around the node (e.g., a congestion level of 0 to 10). Based on the reacquired data, the relay index of each unvisited candidate node and the availability index of various secondary transportation options corresponding to each candidate node can be recalculated. The recalculation can use the same formulas and weights as the initial calculation. By periodically reacquiring real-time data and recalculating scores, the basis for dynamic decision-making is ensured to be up-to-date.

[0141] In other embodiments, traffic events ahead of the travel route can also be detected. Traffic events characterize sudden situations that may reduce road capacity, including traffic accidents, road construction, and temporary traffic control. If a traffic event is detected, the impact range and expected duration of the event are obtained. The impact range characterizes the length of the road section affected along the travel direction from the event point (e.g., 2 kilometers). The expected duration characterizes the estimated time required to clear or resolve the event (e.g., 30 minutes). Based on the impact range and expected duration, the traffic congestion index of unpassed candidate nodes located within or downstream of the impact range can be adjusted. One adjustment method is to multiply the original congestion index by an amplification factor greater than 1, which is positively correlated with the severity of the event. Based on the adjusted node traffic congestion index, the relay index of affected candidate nodes and the corresponding availability indices of various secondary transport capacities are recalculated. Unaffected candidate nodes retain their original values. Regular periodic updates may not capture sudden traffic events in a timely manner, potentially leading to nodes affected by congestion being incorrectly rated as highly available. By using event-driven updates, the evaluation of affected nodes is accurately corrected, avoiding the selection of relay nodes that are actually unusable due to congestion.

[0142] In some embodiments, the transfer node can be adjusted based on the updated transferability index and availability index. Adjusting the transfer node indicates whether to switch the transfer point to a better candidate node based on the latest dynamic score before the original transfer node is reached on the high-speed segment.

[0143] In some embodiments, the updated relayability index of the currently determined relay node can be compared with that of each unvisited candidate node. If the relayability index of an unvisited candidate node is higher than that of the current relay node and the difference exceeds a preset threshold (e.g., 0.2), the current relay node is switched to the unvisited candidate node with the highest relayability index. The preset threshold is used to avoid frequent switching due to small fluctuations. By setting a difference threshold, switching is only performed when there is a significant performance improvement, thus maintaining decision stability.

[0144] In other embodiments, the updated relay capability index and corresponding second capacity availability index of the currently determined relay node and each unpassed candidate node can be obtained. The comprehensive advantage score of each unpassed candidate node relative to the current relay node is calculated. The comprehensive advantage score represents the weighted sum of the increment of the relay capability index and the increment of the availability index. One calculation formula is: Comprehensive Advantage Score = α × (Candidate Node Relay Capability Index - Current Node Relay Capability Index) + β × (Lowest Value of Multiple Second Capacity Availability Indices of the Candidate Node - Lowest Value of Multiple Second Capacity Availability Indices of the Current Node), where α and β are preset weights (e.g., α = 0.6, β = 0.4). If the comprehensive advantage score of an unpassed candidate node exceeds a preset switching threshold (e.g., 0.3), and at least one mode of the multiple second capacity corresponding to that node has an availability index higher than a preset multiple (e.g., 1.5 times) of the availability index of the mode corresponding to the current relay node, then the current relay node is switched to the unpassed candidate node with the highest comprehensive advantage score. Simply comparing relayability indices may overlook the shortcomings in capacity availability, while nodes with low availability indices are unreliable even if their relayability indices are high. By comprehensively considering the node's overall score and the availability of weak capacity modes, and adding an advantage multiplier condition, we ensure that the switched-off node has a practically feasible and highly reliable guarantee capability.

[0145] In some embodiments, the succession index change sequence of the currently determined relay node and each unpassed candidate node at multiple consecutive time points (e.g., the past 5 update time points) can also be obtained. The change sequence is used to characterize the trajectory of the succession index of each candidate node fluctuating over time. Based on the change sequence, methods such as linear regression or exponential smoothing can be used, but are not limited to, to predict the succession index trend of each candidate node within a preset time period in the future (e.g., the next 10 minutes). The trend includes rising, falling, or stable. If the predicted succession index of an unpassed candidate node is expected to be consistently higher than that of the current relay node within the preset time period in the future, and the difference shows an increasing trend, then the unpassed candidate node is set as a pre-switching node. The pre-switching node is used to characterize a candidate node that has not yet switched immediately but already has switching potential. When the geographical distance between the real-time location of the first transport capacity and the pre-switching node is less than a preset multiple (e.g., 0.5 times) of the distance between the current relay node and the pre-switching node, a relay node switch is performed. Real-time scores may fluctuate, and premature switching may result in unnecessary adjustments due to subsequent reversals. By using trend prediction and location-triggered mechanisms, a forward-looking and smooth relay node switching can be achieved, avoiding frequent fluctuations.

[0146] In some embodiments, the method further includes: during high-speed travel, if the location of the matched first transport vehicle and the relay node meet preset triggering conditions, triggering the relay of the matched second transport vehicle. The preset triggering conditions characterize the spatial or temporal boundary conditions for initiating the second transport vehicle's pick-up action. Triggering the relay of the matched second transport vehicle instructs the pre-matched second transport vehicle to begin moving towards the relay node or preparing to pick up passengers. If the second transport vehicle departs too early, it may wait idly for a long time; if it departs too late, passengers may wait for a long time at the relay node, requiring precise triggering timing. By using a triggering mechanism based on the location of the first transport vehicle, activating the second transport vehicle at the appropriate time can achieve a smooth connection between the two at the relay node.

[0147] In some embodiments, the real-time location of the matched first transport vehicle and the straight-line distance between them and the relay node can be obtained. The straight-line distance characterizes the spatial proximity of the first transport vehicle's current location to the relay node, ignoring road curvature. When the straight-line distance is less than a preset distance threshold, a pick-up notification is sent to the matched second transport vehicle. The preset distance threshold can be, for example, 1 to 3 kilometers, to ensure the second transport vehicle has sufficient time to respond. The pick-up notification includes the location information of the relay node, the estimated arrival time, and the passenger's contact information. The location information of the relay node guides the second transport vehicle to the correct pick-up point. The estimated arrival time is calculated based on the current location and speed of the first transport vehicle. The passenger's contact information is used by the second transport vehicle to communicate with the passenger at the transfer site. By using the straight-line distance threshold, rapid triggering is achieved, ensuring the second transport vehicle responds promptly when the passenger approaches.

[0148] In other embodiments, the estimated arrival time of the first transport vehicle to the relay node can be predicted based on its real-time location, real-time speed, and planned route. The planned route represents the road sequence followed by the first transport vehicle from its origin to the relay node. The real-time speed is used to predict the time required for the remaining road segments. The traffic congestion index of the road segments ahead of the first transport vehicle is obtained. The traffic congestion index represents the traffic density and efficiency of each road segment between the current location of the first transport vehicle and the relay node, and is, for example, taken as 0 to 10. The estimated arrival time is corrected based on the traffic congestion index. One correction method is to divide the length of each road segment by the ratio of the historical average speed of that road segment to the congestion impact coefficient, where the congestion impact coefficient is positively correlated with the congestion index. When the difference between the corrected estimated arrival time and the current system time is less than a preset time threshold, a pick-up notification containing the corrected estimated arrival time can be sent to the matched second transport vehicle. The preset time threshold is, for example, 10 to 20 minutes. The estimated arrival time in the pick-up notification can be updated at preset time intervals (e.g., 1 minute) until the first vehicle actually arrives at the relay node. Straight-line distance triggering ignores actual road travel time and traffic conditions, which may result in triggering too early or too late. By dynamically updating the estimated arrival time based on refined predictions of routes and real-time congestion, the departure timing of the second vehicle is made more accurate, reducing waiting or delays.

[0149] In some embodiments, the method further includes: during high-speed travel, adjusting the relay time period of the matched second transport vehicle based on feedback information regarding the location and speed of the matched first transport vehicle. The relay time period characterizes the time interval during which the second transport vehicle should arrive at the relay node to wait for passengers; this interval has a start time and an end time. The initially set relay time period may no longer match due to fluctuations in the actual travel speed of the first transport vehicle, requiring dynamic adjustment. The relay time period is corrected in real time based on feedback information, ensuring that the waiting window of the second transport vehicle is always synchronized with the actual arrival time of the first transport vehicle.

[0150] In some embodiments, the estimated arrival time of the first transport vehicle to the relay node can be calculated based on the remaining distance between the real-time location of the matched first transport vehicle and the relay node, as well as its travel speed. The remaining distance is based on the planned route rather than the straight-line distance. The estimated arrival time equals the remaining distance divided by the current speed plus possible intersection waiting time. The estimated arrival time can be used as the relay start time for the matched second transport vehicle, and updated relay time information can be sent to the second transport vehicle. The relay time information includes the start time and a suggested arrival window (e.g., 5 minutes before and after the start time).

[0151] In other embodiments, the position and velocity sequences of the matched first transport vehicle at multiple consecutive time points can also be obtained. The position sequence represents the set of trajectory points of the first transport vehicle over a past period. The velocity sequence represents the instantaneous velocity at the corresponding time point. Based on the position and velocity sequences, a Kalman filter is used to predict the trajectory of the first transport vehicle within a preset future time period and the probability distribution of its arrival at the relay node. The Kalman filter is used to fuse historical observations with the motion model, outputting a prediction result with uncertainty. The probability distribution represents the likelihood of the first transport vehicle arriving at the relay node at different time points, expressed in terms of mean and variance. Based on the probability distribution, the expected time interval and confidence level for the first transport vehicle to arrive at the relay node are determined. The expected time interval is taken as the mean ± 1.96 times the standard deviation, corresponding to a 95% confidence level. The confidence level represents the reliability of the prediction result. When the confidence level is higher than a preset confidence threshold (e.g., 0.8), the lower limit of the expected time interval is taken as the earliest relay time of the second transport vehicle, and the upper limit is taken as the latest relay time of the second transport vehicle. The earliest relay time indicates that the second vehicle should not arrive earlier than this time, otherwise it may wait too long. The latest relay time indicates that the second vehicle should arrive before this time, otherwise passengers may experience excessive waiting. The earliest and latest relay times are sent to the second vehicle as adjusted relay periods, instructing it to arrive at the relay node within this period. Single speed and distance calculations cannot quantify the uncertainty of predictions, leading to potentially overly optimistic or pessimistic adjusted periods. Determining relay periods through probability prediction and confidence intervals allows the second vehicle sufficient time buffer while avoiding resource waste caused by premature arrival, thus improving the robustness of the connection.

[0152] In some embodiments, the method further includes: if the second capacity matching for the final segment sub-order fails or is canceled, performing re-matching within the same capacity mode. Re-matching within the same capacity mode represents the process of re-finding available capacity within the same capacity type range as the original second capacity, without changing the capacity mode category. The matched second capacity may be unable to execute the trip due to driver cancellation, vehicle malfunction, or unresponsive timeout, resulting in the final segment sub-order losing its capacity provider. Re-matching within the same mode restores capacity assurance for the final segment trip with minimal changes, avoiding the sudden cost or experience abrupt changes caused by direct cross-mode downgrading.

[0153] In some embodiments, when a matched second capacity is canceled or the matching fails, other candidate capacity belonging to the same capacity mode as the failed second capacity can be obtained. The same capacity mode is used to indicate that the capacity type is the same (e.g., if it was originally a ridesharing service, then a ridesharing service will still be sought; if it was originally a taxi service, then a taxi service will still be sought). Candidate capacity is sorted from nearest to farthest geographical distance from the relay node. Geographical distance is calculated based on straight-line distance or road network distance. Matching requests are sent sequentially to the sorted candidate capacity, and the first candidate capacity to accept the match is determined as the new second capacity. Through distance-priority sorting and serial confirmation mechanisms, alternative capacity is found in the shortest possible time, minimizing the impact on passengers' journeys.

[0154] In other embodiments, the current time when the second capacity matching fails or is canceled, as well as the estimated latest departure time of the final segment sub-order, can also be obtained. The estimated latest departure time characterizes the latest time at which the passenger can accept the departure of the final segment of the journey; exceeding this time may cause the passenger to arrive at the destination later than expected. The remaining time window from the current time to the estimated latest departure time is calculated. The remaining time window characterizes the length of time available for rematching. Within the remaining time window, rematching within the same capacity mode can be performed in rounds at preset time intervals (e.g., every 30 seconds). The first round matches only candidate capacity within a first distance range (e.g., within 2 kilometers) from the relay node; the second round expands the matching range to a second distance range (e.g., within 5 kilometers), and subsequent rounds expand accordingly. If any round matches successfully, subsequent rounds stop. If all rounds fail to match, a cross-capacity mode downgraded matching is initiated. When the remaining time window is short, priority should be given to matching nearby capacity to improve the success rate and response speed; when the remaining time is ample, the search range can be gradually expanded. By employing a phased and gradually expanding matching strategy, we aim to restore the system to the same pattern as much as possible within the time constraints, while reserving a decision window for subsequent downgrades.

[0155] In some embodiments, the method further includes: if rematching within the same capacity mode fails, performing a cross-capacity mode downgraded matching. Cross-capacity mode downgraded matching characterizes the process of switching to another capacity type to complete the final leg of the journey when no alternative of the same type of capacity can be found. Rematching within the same mode may fail due to insufficient overall supply of that mode, in which case it is necessary to switch to other capacity modes to ensure that passengers can continue their journey. Mode downgrade provides redundancy assurance, avoiding the failure of the entire parent order due to the depletion of supply in a single mode.

[0156] In some embodiments, when a rematch with the same capacity mode fails, other capacity modes can be tried sequentially according to a preset mode downgrade order. The preset mode downgrade order includes either an order from low to high determinism (ridesharing → taxi → public transport) or from low to high cost (public transport → ridesharing → taxi). For the currently attempted capacity mode, available candidate capacity modes are retrieved. If an available candidate capacity is found, the candidate capacity with the highest overall score in that mode is designated as the new second capacity mode, and the downgrade matching process terminates. The overall score is calculated based on factors such as the distance between the candidate capacity and the relay node, the estimated arrival time, and passenger reviews in that mode. If the current mode retrieval fails, the process switches to the next capacity mode and continues until success or all modes fail. This sequential, preset-order attempt ensures that the downgrade process is orderly and predictable, and prioritizes modes that better meet the scenario's needs.

[0157] In other embodiments, the remaining allowable waiting time for the final segment of the sub-order and the passenger's transfer location can also be obtained. The remaining allowable waiting time characterizes the maximum time a passenger is willing to wait for the final segment of the transport to arrive at the current relay node; this time is extracted from passenger preference settings or historical behavior data. Based on the remaining allowable waiting time, an acceptable set of degraded modes is determined. When the remaining allowable waiting time is less than a first time threshold (e.g., 5 minutes), only the instant ride-hailing mode is retained as the degraded target because it offers the fastest response. When the remaining allowable waiting time is between the first and second time thresholds (e.g., 15 minutes), both the instant ride-hailing mode and the relay carpooling mode are retained. When the remaining allowable waiting time is greater than the second time threshold, all modes, including the public transport connection mode, are retained. From the acceptable set of degraded modes, each mode is sorted from highest to lowest according to its real-time matching success rate at the current moment. The real-time matching success rate is calculated based on the actual matching success rate of that mode within a preset time window in the past. Matching requests are initiated sequentially for the sorted modes, and the transport capacity corresponding to the first successfully matched mode is determined as the new second transport capacity. Different passengers have varying tolerances for waiting times, and a fixed downgrade order may overlook their time-sensitive needs. By dynamically tailoring the set of acceptable downgrade options based on remaining waiting time and prioritizing options with high success rates, personalized and efficient downgrade decisions can be achieved.

[0158] In some embodiments, the method further includes: determining a new relay node if multiple secondary transportation options at the relay node are unavailable and the first transportation option for the high-speed segment order has not arrived at the relay node. The new relay node represents a reselected transfer location after the original relay node fails, and this location is still within the planned route segment not yet traversed by the first transportation option. When all secondary transportation modes around the original relay node are unavailable, there is still an opportunity to complete the transfer at a more downstream node if the first transportation option has not yet arrived. By reselecting the relay node, the failure of the entire journey due to localized capacity depletion is avoided, improving the final fulfillment rate of the parent order.

[0159] In some embodiments, the real-time location of the first transport capacity and a list of candidate nodes not yet traversed in the planned route can be obtained. Nodes not yet traversed, representing the current location of the first transport capacity, are not considered; only nodes preceding the first transport capacity are considered. Currently failed relay nodes and nodes within a preset downstream distance range (e.g., within 5 kilometers) are removed from the candidate node list. Removing nearby downstream nodes avoids selecting locations that are spatially too close to the original node and may also have insufficient capacity. The remaining candidate nodes are sorted from closest to furthest from the original relay node. The candidate node closest to the current location of the first transport capacity and corresponding to at least one available transport mode among various second transport options is determined as the new relay node. By removing adjacent failed nodes and sorting by distance, the first available downstream node is prioritized, balancing feasibility and transfer distance.

[0160] In other embodiments, for each unvisited candidate node, the estimated time for the first transport capacity to reach the node from its current location can be calculated. The estimated time is calculated based on the remaining road mileage and the real-time speed of the first transport capacity. Based on the estimated time, from the various second transport capacity options corresponding to the node, transport capacity modes expected to be available within a preset time window (e.g., 10 minutes before and after) before and after the estimated time are selected. The time window can be used to characterize the availability of a certain transport capacity mode near the predicted arrival time (e.g., buses have suitable schedules, express cars have online drivers). Candidate nodes with at least one available transport capacity mode are selected as alternative nodes. From the alternative nodes, the node with the smallest difference between the estimated time and the current system time is selected as the new relay node. The smallest difference is used to characterize the available node that the first transport capacity can reach the fastest. Simply filtering based on distance may ignore the temporal matching of transport capacity availability in the time dimension; nodes that are close but whose transport capacity is unavailable at that moment are actually invalid. By using time window alignment filtering, it is ensured that the new node is not only spatially feasible but also temporally matched with the arrival time of the first transport capacity, improving the success rate of relay after reselection.

[0161] Figure 3 A schematic diagram of the overall process of the above-mentioned ridesharing relay method is shown; Figure 4A schematic diagram of the above-mentioned ridesharing relay method is shown. Figure 5 This diagram illustrates how the server tracks the fulfillment status and manages the trip for sub-orders in a unified manner during the ride-sharing relay method described above. Figure 6 The diagram illustrates the selection process for candidate nodes in the above-mentioned ridesharing relay method. Figure 7 This diagram illustrates the multi-party interactive relay in the above-mentioned ridesharing relay method; Figure 8 The diagram illustrates the local recalculation and mode degradation mechanism in the aforementioned ride-sharing relay method.

[0162] As can be seen from the ridesharing relay method provided in the embodiments of this specification above, this embodiment can split intercity ridesharing orders into highway segment orders and final segment orders, and match them with first and second transportation capacity respectively. This allows a trip that originally required a single transportation capacity for the entire journey to be completed by two segments of transportation capacity relaying together. This allows drivers who only wish to travel on the highway segment and do not want to detour into the city to act as the first transportation capacity to take over the highway segment, avoiding the exclusion of this portion of transportation capacity from the supply, releasing wasted highway toll capacity, and improving the capacity utilization rate and order matching success rate of intercity ridesharing. At the same time, by uniformly tracking the fulfillment status and managing the trip for the two sub-orders, passengers still perceive it as a single order and a single trip, ensuring the continuity and consistency of the transfer process.

[0163] See Figure 9 As shown in the figure, this specification also provides a ridesharing relay device 900, which may specifically include the following structural modules: The acquisition module 901 is used to acquire ride-sharing orders for intercity travel; the ride-sharing order includes a starting point and a destination; The determining module 902 is used to determine the relay node based on the starting point and the ending point; The splitting module 903 is used to split the ride-sharing order into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination. The first matching module 904 is used to match the first transportation capacity for the high-speed segment order; The second matching module 905 is used to match a second transportation capacity for the final segment sub-order; The tracking and management module 906 performs unified tracking of the fulfillment status and trip management for the high-speed segment orders and the final segment orders.

[0164] In some embodiments, the tracking management module 906 described above can be specifically used for: Generate the total amount to be paid for the ridesharing order; Receive a one-time payment confirmation from the passenger for the total price to be paid.

[0165] In some embodiments, the determining module 902 described above can be specifically used for: Based on the origin and destination, determine the multiple highway exit nodes along the route of the ride-sharing order; The node closest to the destination among multiple high-speed exit nodes is selected as the relay node.

[0166] In some embodiments, the determining module 902 may also be used for: Based on the origin and destination, determine multiple candidate nodes along the route of the ride-sharing order; Calculate the succession index for each candidate node; The node with the highest successor index among multiple candidate nodes is selected as the successor node.

[0167] In some embodiments, the determining module 902 may also be used for: The relayability index of each candidate node is calculated based on at least one of the multiple node evaluation factors. The node evaluation factors include terminal capacity supply density, highway detour distance, node stopping safety, node transfer convenience, terminal travel distance, and node traffic congestion index.

[0168] In some embodiments, the ridesharing relay device 900 described above can also be used for: After a ridesharing order is completed, update multiple relay evaluation factors for each candidate node; Based on the updated relay evaluation factors of each candidate node, the relayability index of each candidate node is updated.

[0169] In some embodiments, the second capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity; Based on this, the aforementioned ride-sharing relay device 900 can also be used to: calculate the availability index of various secondary transportation capabilities corresponding to each candidate node; The step of selecting the node with the highest successor index among multiple candidate nodes as the successor node includes: If the availability index of multiple secondary transportation resources corresponding to the node with the highest relay index does not meet the preset availability conditions, the node with the highest relay index among the candidate nodes whose availability index of multiple secondary transportation resources meets the preset availability conditions will be taken as the relay node.

[0170] In some embodiments, the ridesharing relay device 900 described above can also be used for: During high-speed travel, update the relay index of each unpassed candidate node and the availability index of various secondary transportation capabilities corresponding to each unpassed candidate node; Adjust relay nodes based on the updated relayability and availability indices.

[0171] In some embodiments, the first capacity includes ride-sharing capacity; the second capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity. Based on this, the second matching module 905 mentioned above can be specifically used for: Calculate the availability index for each type of secondary transport capacity; The second capacity with the highest availability index is matched to the last sub-order.

[0172] In some embodiments, the second matching module 905 described above can also be used for: The availability index of each second capacity is calculated based on at least one of multiple capacity evaluation factors for each type of second capacity; the capacity evaluation factors include terminal journey distance, terminal capacity supply density, expected waiting time, and passenger capacity preference.

[0173] In some embodiments, the ridesharing relay device 900 described above can also be used for: Determine the mode priority of each type of secondary transportation based on at least one of the following: the time period of the last segment order, the capacity supply during that time period, and the passenger's historical capacity preference profile; Based on this, the second matching module 905 mentioned above can also be used for: The availability index for each type of secondary capacity is calculated based on the mode priority of each type of secondary capacity and at least one of the multiple capacity evaluation factors for each type of secondary capacity.

[0174] In some embodiments, the ridesharing relay device 900 described above can also be used for: During high-speed travel, if the location of the first matched transport capacity and the relay node meet the preset triggering conditions, the relay of the second matched transport capacity will be triggered.

[0175] In some embodiments, the ridesharing relay device 900 described above can also be used for: During high-speed travel, the relay time of the matched second transport is adjusted based on the feedback information of the location and speed of the matched first transport.

[0176] In some embodiments, the ridesharing relay device 900 described above can also be used for: If the second capacity matching for the final sub-order fails or is cancelled, a rematch will be performed using the same capacity mode. If matching within the same capacity mode fails, a downgraded matching across different capacity modes will be performed. If multiple secondary transport options are unavailable at the relay node and the first transport option for the high-speed segment order has not arrived at the relay node, a new relay node is determined.

[0177] As can be seen from the technical solutions provided in the embodiments of this specification above, these embodiments can split intercity ridesharing orders into highway segment sub-orders and final segment sub-orders, and match them with first and second transportation capacity respectively. This allows a trip that originally required a single transportation capacity for the entire journey to be completed by two segments of transportation capacity relaying each other. This allows drivers who only wish to travel on the highway segment and do not want to detour into the city to act as the first transportation capacity to take over the highway segment, avoiding the exclusion of this portion of transportation capacity from the supply, releasing wasted highway toll capacity, and improving the capacity utilization rate and order matching success rate of intercity ridesharing. Simultaneously, by uniformly tracking the fulfillment status and managing the trip for the two sub-orders, passengers perceive it as a single order and a single trip, ensuring the continuity and consistency of the transfer process.

[0178] It should be noted that the units, devices, or modules described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. For ease of description, the above devices are described by dividing them into various modules according to their functions. Of course, in implementing this specification, the functions of each module can be implemented in one or more software and / or hardware, or a module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are illustrative. For example, the division of units is a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical, mechanical, or other forms.

[0179] Based on the above-described ridesharing method, this specification also provides a computer device in its embodiments. (See attached document.) Figure 10 As shown, the computer device 1000 includes a network communication port 1001, a processor 1002, and a memory 1003. These structures are connected by internal cables so that each structure can perform specific data interaction.

[0180] The computer device 1000 can be a server in the ride-sharing relay system, used to execute the steps performed by the server side in the aforementioned method embodiments. In actual deployment, the computer device 1000 can be either a single physical server or a server cluster composed of multiple servers. When a server cluster is used, multiple servers interact with each other and schedule tasks through an internal network to jointly complete functions such as acquiring the main ride-sharing order, determining the relay node, splitting the order, matching transportation capacity, and tracking and managing the fulfillment status.

[0181] The processor 1002 can be specifically used to obtain ride-sharing orders for intercity travel; the ride-sharing order includes a starting point and a destination; a relay node is determined based on the starting point and the destination; the ride-sharing order is split into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination; a first transportation capacity is matched for the high-speed segment order; and a second transportation capacity is matched for the final segment order.

[0182] The memory 1003 can be used to store the corresponding instruction program, as well as related data such as target data.

[0183] Based on the above method, the relevant structural performance of computer equipment can be effectively utilized to improve the data processing speed of electronic devices and efficiently realize data processing for ride-sharing relay.

[0184] In this embodiment, the network communication port 1001 can be a virtual port bound to different communication protocols, thereby enabling the sending or receiving of different data. For example, the network communication port can be a port responsible for web data communication, a port responsible for FTP data communication, or a port responsible for email data communication. Furthermore, the network communication port can also be a physical communication interface or communication chip. For example, it can be a wireless mobile network communication chip, such as GSM or CDMA; it can also be a Wi-Fi chip; or it can be a Bluetooth chip.

[0185] In this embodiment, the processor 1002 can be implemented in any suitable manner. For example, the processor can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, etc. This specification is not limiting.

[0186] In this embodiment, the memory 1003 may include multiple layers. In a digital system, anything that can store binary data can be a memory. In an integrated circuit, a circuit with storage function but no physical form is also called a memory, such as RAM, FIFO, etc. In a system, a storage device with a physical form is also called a memory, such as a memory stick, TF card, etc.

[0187] This specification also provides a computer-readable storage medium based on any of the above-described ridesharing methods. The computer-readable storage medium stores computer program instructions that, when executed, can: obtain a cross-city ridesharing order; the ridesharing order includes a starting point and a destination; determine a relay node based on the starting point and destination; split the ridesharing order into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination; match a first vehicle to the high-speed segment order; and match a second vehicle to the final segment order.

[0188] In this embodiment, the storage medium includes, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions. The network communication unit can be an interface configured according to standards specified in the communication protocol for network connection communication.

[0189] In this embodiment, the specific functions and effects implemented by the program instructions stored in the computer-readable storage medium can be explained in comparison with other embodiments, and will not be repeated here.

[0190] This specification also provides a computer program product, which includes at least a computer program that, when executed by a processor, can perform the following method steps: obtaining a ride-sharing order for intercity travel; the ride-sharing order includes a starting point and a destination; determining a relay node based on the starting point and the destination; splitting the ride-sharing order into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination; matching a first vehicle to the high-speed segment order; and matching a second vehicle to the final segment order.

[0191] While this specification provides the steps of operation for the methods described in the embodiments or flowcharts, more or fewer steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is one possible order of execution among many steps and does not represent the only possible order. In actual device or client product execution, the methods may be executed sequentially or in parallel as shown in the embodiments or drawings (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that includes a list of elements does not include those elements, but also includes other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded. The terms "first," "second," etc., are used to denote names and do not indicate any particular order.

[0192] Those skilled in the art will also know that, besides implementing the controller using purely computer-readable program code, the same functions can be achieved by logically programming the method steps, making the controller function as logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers (PLCs), and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the devices within it used to implement various functions can also be considered structures within that hardware component. Alternatively, the devices used to implement various functions can be considered as both software modules implementing the method and structures within a hardware component.

[0193] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer-readable storage media, including storage devices.

[0194] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this specification can be implemented by means of software plus necessary general-purpose hardware servers. Based on this understanding, the technical solutions of this specification can essentially be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments of this specification.

[0195] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. This specification can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0196] Although this specification has been described by way of examples, those skilled in the art will recognize that many variations and modifications are possible without departing from the spirit of this specification, and it is intended that the appended claims cover such variations and modifications without departing from the spirit of this specification.

Claims

1. A ridesharing relay method, characterized in that, include: Obtain ride-sharing orders for intercity travel; The ride-sharing order includes a starting point and a destination; Based on the starting point and the ending point, the relay node is determined; The ride-sharing order is split into a high-speed segment order from the origin to the relay node and a final segment order from the relay node to the destination; Match the first transport capacity to the order for the aforementioned high-speed segment; Match a second transport capacity to the last segment of the sub-order; The order status of the high-speed segment and the order of the last segment are tracked and the trip is managed in a unified manner.

2. The method according to claim 1, characterized in that, The unified tracking of fulfillment status and trip management for the high-speed segment orders and the final segment orders includes: Generate the total amount to be paid for the ridesharing order; Receive a one-time payment confirmation from the passenger for the total price to be paid.

3. The method according to claim 1, characterized in that, The step of determining the relay node based on the start and end points includes: Based on the origin and destination, determine the multiple highway exit nodes along the route of the ride-sharing order; The node closest to the destination among multiple high-speed exit nodes is selected as the relay node.

4. The method according to claim 1, characterized in that, The step of determining the relay node based on the start and end points includes: Based on the origin and destination, determine multiple candidate nodes along the route of the ride-sharing order; Calculate the succession index for each candidate node; The node with the highest successor index among multiple candidate nodes is selected as the successor node.

5. The method according to claim 4, characterized in that, The calculation of the succession index for each candidate node includes: The relayability index of each candidate node is calculated based on at least one of the multiple node evaluation factors. The node evaluation factors include terminal capacity supply density, highway detour distance, node stopping safety, node transfer convenience, terminal travel distance, and node traffic congestion index.

6. The method according to claim 5, characterized in that, The method further includes: After a ridesharing order is completed, update multiple relay evaluation factors for each candidate node; Based on the updated relay evaluation factors of each candidate node, the relayability index of each candidate node is updated.

7. The method according to claim 4, characterized in that, The second capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity; The method further includes: Calculate the availability index of various secondary transportation capabilities corresponding to each candidate node; The step of selecting the node with the highest successor index among multiple candidate nodes as the successor node includes: If the availability index of multiple secondary transportation resources corresponding to the node with the highest relay index does not meet the preset availability conditions, the node with the highest relay index among the candidate nodes whose availability index of multiple secondary transportation resources meets the preset availability conditions will be taken as the relay node.

8. The method according to claim 7, characterized in that, The method further includes: During high-speed travel, update the relay index of each unpassed candidate node and the availability index of various secondary transportation capabilities corresponding to each unpassed candidate node; Adjust relay nodes based on the updated relayability and availability indices.

9. The method according to claim 1, characterized in that, The first capacity includes ride-sharing capacity; the second capacity includes ride-sharing capacity, taxi capacity, and public transportation capacity. The process of matching the second transportation capacity for the final sub-order includes: Calculate the availability index for each type of secondary transport capacity; The second capacity with the highest availability index is matched to the last sub-order.

10. The method according to claim 9, characterized in that, The calculation of the availability index for each type of second capacity includes: The availability index of each second capacity is calculated based on at least one of multiple capacity evaluation factors for each type of second capacity; the capacity evaluation factors include terminal journey distance, terminal capacity supply density, expected waiting time, and passenger capacity preference.

11. The method according to claim 10, characterized in that, The method further includes: Determine the mode priority of each type of secondary transportation based on at least one of the following: the time period of the last segment order, the capacity supply during that time period, and the passenger's historical capacity preference profile; The calculation of the availability index for each second capacity based on at least one of multiple capacity evaluation factors for each second capacity includes: The availability index for each type of secondary capacity is calculated based on the mode priority of each type of secondary capacity and at least one of the multiple capacity evaluation factors for each type of secondary capacity.

12. The method according to claim 1, characterized in that, The method further includes: During high-speed travel, if the location of the first matched transport capacity and the relay node meet the preset triggering conditions, the relay of the second matched transport capacity will be triggered.

13. The method according to claim 1, characterized in that, The method further includes: During high-speed travel, the relay time of the matched second transport is adjusted based on the feedback information of the location and speed of the matched first transport.

14. The method according to claim 1, characterized in that, The method further includes: If the second capacity matching for the final sub-order fails or is cancelled, a rematch will be performed using the same capacity mode. If matching within the same capacity mode fails, a downgraded matching across different capacity modes will be performed. If multiple secondary transport options are unavailable at the relay node and the first transport option for the high-speed segment order has not arrived at the relay node, a new relay node is determined.

15. A ridesharing relay device, characterized in that, include: The acquisition module is used to acquire ride-sharing orders for intercity travel; The ride-sharing order includes a starting point and a destination; The determination module is used to determine the relay node based on the starting point and the ending point; The splitting module is used to split the ride-sharing order into a high-speed segment order from the starting point to the relay node and a final segment order from the relay node to the destination. The first matching module is used to match the first transportation capacity for the high-speed segment order; The second matching module is used to match a second transportation capacity for the final segment sub-order; The tracking and management module is used to perform unified tracking of the fulfillment status and trip management for the high-speed segment orders and the last segment orders.

16. A computer device, characterized in that, include: The system includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to implement the ridesharing method according to any one of claims 1 to 14.

17. A computer-readable storage medium storing computer instructions thereon, characterized in that, When the instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 14.

18. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 14.

Images