A ride sharing method and related apparatus

Abstract

The application discloses a carpooling method and related device, and aims at a first account having placed a first car order. In a first car order page, first notification information and travel information of a second car order are displayed. The first notification information is used to obtain whether the first account wants to invite others to share a car. The travel information of the second car order is used to represent specific conditions of the second car order, so that a user of the first account can first know the conditions of the car order to be shared with himself, and then decide whether to agree to share the car. In response to obtaining a consent to merge operation implemented by the first account through the first notification information, a first carpooling result is displayed, and if the first carpooling result indicates that carpooling is successful, the first car order is updated to a merged order. Therefore, the user is provided with the right to choose what car order to share, so that the user can choose whether to agree to share the car according to his own intention, and the carpooling satisfaction and experience are improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a carpooling method and related apparatus. Background Technology

[0002] Currently, online ride-hailing has become a common way for people to travel. In practical applications, apps such as ride-hailing platforms support users in hailing rides online.

[0003] With the continuous development of online ride-hailing, carpooling services have gradually emerged, allowing one car to serve multiple people simultaneously, especially those who board and alight at different locations. Related technologies include features such as "carpooling mode" and "ridesharing mode." Users can pre-select these modes before placing an order to share a car with others, thus increasing the chances of getting a ride and splitting the fare.

[0004] However, the carpooling services provided by the relevant technologies are unable to determine carpooling orders that satisfy users, resulting in a poor carpooling experience for users. Summary of the Invention

[0005] To address the aforementioned technical issues, this application provides a carpooling method and related apparatus, which facilitates the determination of combined orders that satisfy users, thereby improving carpooling satisfaction and the carpooling experience.

[0006] The embodiments of this application disclose the following technical solutions:

[0007] On the one hand, embodiments of this application provide a carpooling method, the method comprising:

[0008] In response to receiving the first ride-hailing order initiated by the first account, the first ride-hailing page is displayed, and the first pick-up and drop-off information is displayed on the first ride-hailing page. The first pick-up and drop-off information is used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order.

[0009] The first ride-hailing page displays the first notification information and the trip information of the second ride-hailing order, and the first ride-hailing order and the second ride-hailing order meet the conditions for carpooling;

[0010] In response to receiving the consent to merge operation performed by the first account through the first notification information, the first carpooling result is displayed;

[0011] If the first carpooling result indicates that the carpooling was successful, the first ride-hailing order will be updated to a merged order obtained by combining the first ride-hailing order and the second ride-hailing order, and the first vehicle will be used to pick up and drop off the passenger corresponding to the merged order.

[0012] In another aspect, embodiments of this application provide a carpooling device, the device including a display unit and an update unit:

[0013] The display unit is used to respond to the receipt of the first ride-hailing order initiated by the first account, display the first ride-hailing page, and display the first pick-up and drop-off information on the first ride-hailing page. The first pick-up and drop-off information is used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order.

[0014] The display unit is also used to display the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page, wherein the first ride-hailing order and the second ride-hailing order meet the conditions for carpooling;

[0015] The display unit is also used to display the first carpooling result in response to receiving the consent to merge operation performed by the first account through the first notification information;

[0016] The update unit is used to update the first ride-hailing order to a merged order obtained by merging the first ride-hailing order and the second ride-hailing order if the first ride-sharing result indicates that the ride-sharing was successful. The first vehicle is used to pick up and drop off the passenger corresponding to the merged order.

[0017] On the other hand, embodiments of this application provide a computer device, the computer device including a processor and a memory:

[0018] The memory is used to store computer programs and to transfer the computer programs to the processor;

[0019] The processor is configured to execute the method described in any of the foregoing aspects according to instructions in the computer program.

[0020] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program, which, when run by a computer device, causes the computer device to perform the methods described in any of the foregoing aspects.

[0021] On the other hand, embodiments of this application provide a computer program product, including a computer program that, when run on a computer device, causes the computer device to perform the methods described in any of the foregoing aspects.

[0022] As can be seen from the above technical solution, for the first account that has already hailed a ride, the first ride-hailing page displays the first notification information and the trip information of the second ride-hailing order. The first notification information is used to determine whether the first account agrees to merge the second ride-hailing order with its own first ride-hailing order; that is, the first notification information is used to determine whether the first account wants to invite others to share a ride. Furthermore, the trip information of the second ride-hailing order indicates the specific details of the second ride-hailing order, thus showing what kind of ride-hailing order it is. It is evident that by proactively recommending a second ride-sharing option to the first account that has already hailed a ride, and simultaneously displaying the trip information of the second ride-hailing order, the user of the first account can first understand the details of the ride-sharing order to them before deciding whether to agree to share. Accordingly, in response to the first account's agreement to merge via the first notification information, the first ride-sharing result is displayed, and if the first ride-sharing result indicates a successful share, the first ride-hailing order is updated to a merged order. Based on this, users are given the option to choose which ride-sharing orders to share with, allowing them to decide whether or not to agree to share based on their own preferences. This helps to determine combined orders that satisfy users, improving ride-sharing satisfaction and the overall experience. Furthermore, because the second ride-sharing order is proactively recommended to the first account that has already booked a ride, in scenarios with insufficient capacity, once the first account agrees to share, there is a chance of a successful ride-sharing, allowing other users who are currently trying to book a ride but haven't yet found one to quickly get a ride, thus improving travel efficiency. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram illustrating an application scenario of a carpooling method provided in an embodiment of this application;

[0025] Figure 2a The first part of a recommendation-based carpooling interaction diagram provided in this application embodiment;

[0026] Figure 2b The second part of a recommendation-based carpooling interaction diagram provided in this application embodiment;

[0027] Figure 3 A flowchart illustrating a carpooling method provided in this application embodiment;

[0028] Figure 4 A schematic diagram of an interactive control in a first notification message provided in an embodiment of this application;

[0029] Figure 5 This application provides an illustration of a method for recommending multiple second ride-hailing orders at once.

[0030] Figure 6 A schematic diagram illustrating another instance of recommending multiple second ride-hailing orders at once, provided as an embodiment of this application;

[0031] Figure 7 A schematic diagram illustrating carpooling fare information provided in this application embodiment;

[0032] Figure 8 This application provides an embodiment of a diagram illustrating the determination of a first quantity when a first account has already hailed a ride.

[0033] Figure 9 This application provides another schematic diagram illustrating the determination of a first quantity when a first account has already hailed a ride.

[0034] Figure 10 This application provides a schematic diagram illustrating the settings for a carpooling recommendation service.

[0035] Figure 11 A schematic diagram illustrating a carpooling recommendation for a first account that has not yet managed to hail a ride, provided as an embodiment of this application;

[0036] Figure 12 This application provides an illustration of a method for recommending multiple third-party ride-hailing orders at once.

[0037] Figure 13 This application provides an embodiment of a schematic diagram illustrating the determination of a first quantity of rides when the first account has not yet hailed a ride.

[0038] Figure 14 This application provides another schematic diagram illustrating the determination of a first quantity when the first account has not yet hailed a ride.

[0039] Figure 15 This is a schematic diagram of a selection control provided in an embodiment of this application;

[0040] Figure 16 This application provides a schematic diagram of a carpooling trip as an embodiment of the present application.

[0041] Figure 17 A schematic diagram of an interaction process based on carpooling provided for an embodiment of this application;

[0042] Figure 18 A structural diagram of a carpooling device provided in an embodiment of this application;

[0043] Figure 19 A structural diagram of a terminal provided in an embodiment of this application;

[0044] Figure 20 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0045] The embodiments of this application will now be described with reference to the accompanying drawings.

[0046] Carpooling refers to multiple people traveling together in a vehicle to increase the chances of hailing a ride, speed up the journey, and share the fare. In related technologies, ride-hailing platforms offer features such as "carpooling mode" and "ridesharing mode." Users can pre-select this type of ride-hailing model before placing an order; such orders are called carpooling orders. Ride-hailing platforms automatically merge multiple carpooling orders to achieve carpooling.

[0047] However, this carpooling method provided by the relevant technology relies on the ride-hailing platform to automatically match passengers; users do not participate in the carpooling process and simply passively accept the matchmaking result. This can easily lead to situations where the matched result does not meet the user's expectations, resulting in a poor carpooling experience and negatively impacting the user's riding experience.

[0048] To address this, this application provides a carpooling method and related apparatus. For a first account that has already booked a first vehicle, a second carpooling order is proactively recommended, and the trip information of the second order is simultaneously displayed. This allows the user of the first account to understand the details of the carpooling order before deciding whether to accept it. Based on this, users are given the option to choose which carpooling orders to share with, enabling them to select whether to accept carpooling according to their preferences. This helps to determine a combined order that satisfies the user, improving carpooling satisfaction and overall carpooling experience.

[0049] Compared to related technologies, the carpooling method provided in this application allows users to participate in the carpooling process and have the autonomy to choose who they carpool with, rather than passively accepting the carpooling result arranged by the ride-hailing platform. Therefore, it is conducive to improving carpooling satisfaction and carpooling experience.

[0050] Furthermore, because the system proactively recommends a second ride-sharing order to the first account that has already secured a ride, it increases the chances of a successful ride-sharing once the first account agrees to carpool in scenarios with insufficient capacity. This allows other users who are trying to hail a ride but haven't yet found one to quickly get a ride, thus improving travel efficiency. Therefore, while allowing users to make their own choices, the system still achieves its goals of accelerating travel and sharing fares through carpooling.

[0051] The carpooling method provided in this application can be implemented using computer equipment, which can be a terminal or a server. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminals include, but are not limited to, smartphones, smartwatches, computers, smart voice interaction devices, smart home appliances, and in-vehicle terminals. The terminal and server can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0052] This application's embodiments can be applied to various ride-hailing scenarios. For example, for user-initiated ride-hailing orders of a specific type, when the user has already hailed a ride, other ride-hailing orders that have not yet been booked can be recommended to the user, allowing them to choose whether to accept ride-sharing. Similarly, for user-initiated ride-sharing orders, regardless of whether the user has already hailed a ride or not, ride-sharing orders can be recommended, allowing the user to decide whether to accept ride-sharing.

[0053] It should be noted that in the specific embodiments of this application, the process of carpooling may involve user information and other related data. When the above embodiments of this application are applied to specific products or technologies, it is necessary to obtain separate consent or permission from the user, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0054] Figure 1 This illustration shows an application scenario of the carpooling method provided in the embodiments of this application. Figure 1 In the scenario shown, terminal 100 (such as the aforementioned smartphone, smartwatch, etc.) is used as an example of the aforementioned computer device for illustration:

[0055] exist Figure 1 In the example, for the first account that has already booked a ride (e.g., user A), the car (license plate number 11111) that user A booked is on its way to the first pick-up point. At this time, a second ride-sharing order that can be shared is recommended to user A. Specifically:

[0056] The first ride-hailing page displays a notification informing user A that "there are passengers with similar trips within 500 meters of you. Inviting them to share a ride will automatically add them and intelligently split the bill." The notification also includes an "Invite Now" control for user A to initiate the invitation. Furthermore, the first ride-hailing page displays the trip information for the second ride-hailing order. Figure 1In the example, the trip information for the second ride-hailing order is the second pick-up point corresponding to the second ride-hailing order, informing user A that "this passenger boarded here, and their trip is similar to yours; you can invite them to ride together."

[0057] Since the ride-hailing page displays an electronic map, showing the second pick-up point allows user A to intuitively understand where the second ride-sharing order is located and how far it is from them, thus helping user A decide whether to agree to share the ride. Correspondingly, if user A wants to agree to share the ride, they can easily click the "Invite Now" button in the first notification message.

[0058] Finally, if the carpooling is successful, user A's original first ride-hailing order can be updated to a combined order resulting from merging the first and second ride-hailing orders. For example... Figure 1 In the example, the first ride-hailing page displays "The driver has arrived at the first pick-up point and will be heading to the second pick-up point" and "The route for you has been replanned." Specifically, the original route has been updated to the route corresponding to the merged order. The original route indicated "from the first pick-up point → the first destination," while the route corresponding to the merged order indicates "from the first pick-up point → the second pick-up point → the first destination → the second destination."

[0059] It is evident that for user A who has already hailed a ride, a carpooling recommendation is proactively provided, and user A can choose whether or not to accept the carpooling based on their own preferences or needs. Based on this, user A can directly participate in the carpooling process of their ride-hailing, and independently choose which second ride-hailing orders to carpool with (e.g.,...). Figure 1 The second pick-up point shown is one that user A agrees to carpool with. Other options may not meet user A's needs, so user A may choose not to carpool. Therefore, when carpooling is successful, the combined order is more likely to satisfy user A, thus increasing carpooling satisfaction.

[0060] Furthermore, because the second ride-hailing order was proactively recommended to user A, in scenarios with insufficient transportation capacity, user A had the opportunity to successfully carpool once they clicked "Invite Now," thus enabling users with second ride-hailing orders who had not yet been able to hail a ride to quickly find a car to share, thereby improving travel efficiency.

[0061] against Figure 1 It should also be noted that this embodiment is merely an example and does not impose any limitations. For instance, it is not limited to recommending a second ride-hailing order only when user A's hailed car is heading to the first pick-up point. Similarly, it is not limited to the first notification information being limited to the image shown, or the trip information for the second ride-hailing order being limited to the second pick-up point, etc.

[0062] Understandably, in Figure 1In the example, a carpooling service is offered to user A who has already booked a ride, allowing them to choose their own ride. Similarly, a carpooling service can also be offered to user B for the second account corresponding to the second ride order (e.g., user B).

[0063] To better understand this, this application also provides a recommendation-based carpooling interaction diagram. First, it should be noted that, due to space limitations, this diagram is divided into two parts and placed across multiple pages. Specifically: Figure 2a The first part of the schematic diagram of a recommendation-based carpooling interaction is shown, and as follows: Figure 2b The second part of the diagram illustrating a recommendation-based carpooling interaction is shown, where "Node 1" indicates that the two parts are connected to form a complete "recommendation-based carpooling interaction diagram". For ease of explanation later, the complete "recommendation-based carpooling interaction diagram" formed by connecting these two parts is denoted as Figure 2. Specifically:

[0064] Server 200 can correspond to the service provider of a ride-hailing platform, used to provide ride-hailing services to users. Terminal 201 can correspond to the first account (i.e., user A), and terminal 202 can correspond to the second account (i.e., user B). In practical applications, if terminal 201 and server 200 are connected via a network, and if terminal 202 and server 200 are also connected via a network, then user A can obtain ride-hailing services provided by the ride-hailing platform through terminal 201, and user B can obtain ride-hailing services provided by the ride-hailing platform through terminal 202. For ease of understanding, in the example in Figure 2, assume that the passenger corresponding to the first ride-hailing order is user A, and the passenger corresponding to the second ride-hailing order is user B. Specifically:

[0065] Step 1: The user initiates a ride-hailing order through the terminal.

[0066] User A can initiate their first ride-hailing order through terminal 201. Upon successful order placement and dispatch of a vehicle with license plate number 11111, the terminal 201 will display a "First Ride-Hailing" page, as shown in [A-①]. In other words, User A has successfully hailed a ride.

[0067] User B can initiate a second ride-hailing order through terminal 202. After the order is successfully placed, the ride-hailing platform will dispatch a car for User B. Correspondingly, a second ride-hailing page will be displayed on terminal 202, as shown in [B-①]. That is, User B is currently trying to hail a ride but has not yet received one.

[0068] Step 2: Server 200 (ride-hailing platform) determines that A and B are similar trips.

[0069] In other words, if the first and second ride-hailing orders meet the criteria for carpooling, then carpooling recommendations can be proactively offered to these two users. For example, similar trips can be defined as: the pick-up points of the two users are close to each other, their destinations are also close to each other, and their routes are also quite similar.

[0070] Step 3: Server 200 sends a carpooling recommendation to terminal 201.

[0071] That is, the system proactively provides user A with a second ride-sharing order. Specifically, it displays the first notification information and the second pick-up point on the first ride-sharing page. At this time, the terminal 201 can display the first ride-sharing page as shown in [A-②].

[0072] Next, if user A agrees to carpool, they can click the "Invite Now" button. Accordingly, terminal 201 sends an invitation to server 200 to inform the ride-hailing platform that user A has agreed to carpool.

[0073] Step 4: Server 200 sends a carpooling recommendation to terminal 202.

[0074] That is, after user A agrees to carpool, the system proactively provides user B with the first ride-sharing order that can be shared. Specifically, the second ride-sharing page displays the second notification information and the first pick-up point. At this time, the terminal 202 can display a second ride-sharing page as shown in [B-②].

[0075] Next, if user B agrees to carpool, they can click the "Accept Invitation" button. Correspondingly, terminal 202 sends an acceptance invitation to the server to inform the ride-hailing platform that user B has accepted the carpooling.

[0076] Step 5: Server 200 (ride-hailing platform) confirms successful carpooling.

[0077] After confirming a successful carpool, server 200 can notify terminals 201 and 202 of the carpooling success. A successful carpool means that user A and user B are sharing the same vehicle with license plate number 11111. To help users A and B understand their travel plans after the carpool, terminal 201 displays the first ride-hailing page as shown in [A-③], and terminal 202 displays the second ride-hailing page as shown in [B-③]. Specifically, [A-③] and [B-③] display the same information: "The driver has arrived at the first pick-up point and is about to proceed to the second pick-up point," "License plate number 11111," and the replanned route: "First pick-up point → Second pick-up point → First destination → Second destination."

[0078] Based on this, when proactively offering carpooling recommendations to user A who has already hailed a ride, the system will ask user A if they want to agree to carpool and will inform them of user B's pick-up point. In this way, user A can initiate an invitation if they want to carpool with user B, and decline if they don't, allowing user A to choose who to carpool with and improving user A's carpooling satisfaction.

[0079] Similarly, when proactively offering carpooling recommendations to user B who hasn't yet secured a ride, the service will ask if user B wants to share a ride and will inform them of user A's pick-up point. In this way, user B can accept the invitation if they want to ride with user A, or decline if they don't, allowing user B to choose their own ride and improving their carpooling satisfaction.

[0080] It is evident that both users who have successfully hailed a ride and those who haven't have the right to choose who to share with, allowing them to carpool according to their own preferences. Furthermore, once both parties agree and confirm a successful carpool, user A has someone to share the fare, and user B can immediately get in the car and also has someone to share the fare. Based on this, user carpooling satisfaction is improved, while travel efficiency is also increased.

[0081] Regarding the example in Figure 2, it should be noted that Figure 2 is merely an example and does not impose any limitations. For instance, the order in which user A and user B initiate ride-hailing orders, and the timing of sending carpooling recommendations to terminal 202, are all just examples and do not impose any limitations.

[0082] Figure 3 A flowchart of a carpooling method provided in this application embodiment is used to illustrate the method, with a terminal as an example of the aforementioned computer device. The method includes S301-S304:

[0083] S301: In response to receiving the first ride-hailing order initiated by the first account, display the first ride-hailing page and display the first pick-up and drop-off information on the first ride-hailing page.

[0084] In practical applications, ride-hailing platforms can provide users with ride-hailing services, such as through applications or mini-programs. When a user needs a ride, they can initiate a ride order on the platform, and the platform can then dispatch a vehicle to pick them up and drop them off.

[0085] For the first ride-hailing order initiated by the first account, the information can be used to identify the ride from the first pick-up point to the first destination, as well as the initiation time. Additionally, the first ride-hailing page can display ride-related information (such as the route automatically planned by the ride-hailing platform, the vehicle being matched for the first ride-hailing order, the matched vehicle, the driver's location, the trip progress, and the fare), allowing users to stay informed about their ride status.

[0086] Furthermore, the first pick-up and drop-off information can be used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order. That is, it informs the user that the first vehicle is the one used to pick up and drop off the passenger corresponding to their ride-hailing order. In practical applications, specifically, the first pick-up and drop-off information can be used to identify that the first vehicle is heading to the first pick-up point corresponding to the first ride-hailing order, i.e., the driver is heading to the location where the user boarded; or, the first pick-up and drop-off information can be used to identify that the passenger corresponding to the first ride-hailing order has boarded the first vehicle, and that the first vehicle is heading to the first destination corresponding to the first ride-hailing order, i.e., it has picked up the user and is heading to the location where the user alights.

[0087] It should be noted that this application does not impose any restrictions on the type of the first ride-hailing order. As an example, the first ride-hailing order can be either a carpooling order or a private ride-hailing order. A carpooling order means that the first account has pre-selected a mode such as "carpooling" or "ridesharing" before initiating the first ride-hailing order; that is, the first ride-hailing order is for the user to travel with others. A private ride-hailing order means that the first account intends to travel alone when initiating the first ride-hailing order and has not specified carpooling. For example, the user selects a taxi or private car when placing the order.

[0088] Therefore, if the first ride-hailing order is a carpooling order, using this application will allow users to have the right to choose, rather than passively accepting a pre-arranged carpool from the ride-hailing platform. If the second ride-hailing order is a private carpooling order, using this application will proactively provide users with carpooling recommendations, allowing them to choose a carpooling option that suits their preferences and share the fare.

[0089] Furthermore, this application does not impose any limitations on the first account. As an example, any account that has already successfully hailed a ride can serve as the aforementioned first account, allowing for proactive ride-sharing recommendations. As yet another example, to increase the success rate of ride-sharing, the first account's historical ride-hailing orders include ride-sharing orders. That is, the first account is an account that has previously shared rides; such accounts are more likely to accept ride-sharing recommendations, thus improving the success rate.

[0090] S302: Display the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page.

[0091] For the first account that has already booked a ride, a carpooling recommendation service can be proactively offered. Specifically, the terminal can display the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page. If the second ride-hailing order meets the carpooling criteria with the first ride-hailing order, it can be considered that they have similar trips and can travel in the same vehicle.

[0092] Specifically, the first notification information can be used to determine whether the first account agrees to merge the first ride-hailing order with the second ride-hailing order, so that the first vehicle can still be used to pick up and drop off the passenger corresponding to the second ride-hailing order. Furthermore, the second ride-hailing order can refer to a ride-hailing order initiated by the second account (e.g., also initiated on a ride-hailing platform, and this platform is the same as the one on which the first account initiated the first ride-hailing order). Specifically, the status of the second ride-hailing order can be "in the process of hailing a ride but has not yet received a ride." The trip information of the second ride-hailing order can be used to indicate the specific details of the second ride-hailing order, thus reflecting what kind of ride-hailing order it is.

[0093] It is evident that proactively offering carpooling recommendations to the first account that has already booked a ride, asking if the first account agrees to carpooling, and simultaneously informing them of the trip information of the second ride-sharing order that could be shared with them, allows the first account user to understand the details of the ride-sharing order before deciding whether to agree. In this way, users can choose whether to agree according to their own preferences, increasing carpooling satisfaction.

[0094] It should be noted that this application does not impose any limitations on the carpooling conditions, the first notification information, or the trip information corresponding to the second ride-hailing order. For ease of understanding, this application will be described in detail through the following embodiments.

[0095] 1. First, regarding carpooling conditions, the following example is provided:

[0096] Carpooling conditions refer to the criteria used to determine whether different ride-hailing orders can be combined. In practical applications, these conditions can be flexibly set according to actual needs. For ease of understanding, the following examples are provided in this application:

[0097] It is understandable that this application proactively provides carpooling recommendations to users. To increase the likelihood of users accepting the recommendations and thus improve the success rate of carpooling, as an example, carpooling conditions can be set to recommend similar trips as much as possible, avoiding excessive detours caused by carpooling that might discourage users from accepting it. Specifically, if the degree of similarity between the second ride-hailing order and the first ride-hailing order exceeds a certain preset threshold, they can be considered to be basically on the same route and belong to similar trips, thus allowing for carpooling recommendations, meaning that the two meet the carpooling conditions. For ease of understanding, this embodiment uses the first ride-hailing order and the second ride-hailing order as an example to provide the following illustration:

[0098] Example 1-1:

[0099] In practical applications, the pick-up point and destination of a ride-hailing order can reflect the trip details of that order, so it is possible to determine whether the conditions for carpooling are met based on the pick-up point and destination.

[0100] First, the relationship between the first pick-up point corresponding to the first ride-hailing order and the second pick-up point corresponding to the second ride-hailing order is a first relationship, and the relationship between the first destination corresponding to the first ride-hailing order and the second destination corresponding to the second ride-hailing order is a second relationship. Accordingly, the first relationship may include at least one of the following:

[0101] In one example, the distance between the first and second pick-up points is less than a preset distance. That is, the pick-up points are close, and their journeys are more likely to overlap, thus making them more similar trips. Also, for the first account, the pick-up point of the person sharing the ride is closer to their own, making it easier to quickly pick them up after sharing. For example, the preset distance could be set to 1 kilometer.

[0102] In another example, the second pick-up point falls on the route taken by the first vehicle to the first pick-up point. That is, if the carpooling is successful, the second pick-up point can be picked up along the way to the passenger who took the first ride, which helps to avoid taking a detour.

[0103] In another example, the second pick-up point falls on the first route taken by the first vehicle from the first pick-up point to the first destination. That is, if the carpooling is successful, the second passenger can be picked up along the route taken by the passenger who placed the first ride order, which helps to avoid taking a detour.

[0104] Furthermore, the second relationship may include at least one of the following:

[0105] In one example, the distance between the first and second endpoints is less than a preset distance. That is, since their endpoints are close, their journeys are more likely to overlap, and therefore they are more likely to be similar journeys.

[0106] Another example is where the second destination falls on the first route. Here, the first route refers to the path taken by the first vehicle from the first pick-up point to the first destination; it can also be understood as the route taken to deliver the passenger of the first ride-hailing order. Thus, if the ride-sharing is successful, the passenger of the second ride-hailing order can get off along the same route as the passenger of the first ride-hailing order, avoiding a detour.

[0107] Another example is a route from the first destination to the second destination that overlaps less than the first route. That is, after the passenger in the first ride-hailing order gets off, the driver continues to pick up the passenger in the second ride-hailing order, and the driver is unlikely to backtrack, thus minimizing the detour for the second ride-hailing order. The overlap threshold can be flexibly set according to the actual situation. For example, the length of the overlapping segment between the first and second routes can be used as the route overlap, and the overlap threshold could be the overlap length threshold (e.g., 500 meters).

[0108] Corresponding to the above example, satisfying the carpooling conditions can mean satisfying any combination of the aforementioned first relationship and any second relationship. Furthermore, it should be noted that if the first relationship indicates that the second pick-up point falls on the first travel route, and the second relationship indicates that the second destination falls on the first travel route, then the first vehicle's direction of travel from the second pick-up point to the second destination is the same as its direction of travel from the first pick-up point to the first destination. That is, in this case, the passenger for the second ride-hailing order is picked up along the same route, and the passenger for the second ride-hailing order gets off along the same route, rather than needing to turn back to reach the passenger for the second ride-hailing order after dropping off the passenger for the first ride-hailing order.

[0109] Based on the above examples, it is possible to filter ride-sharing orders with similar itineraries as much as possible for carpooling recommendations, avoiding excessive detours after merging, which would affect the user's carpooling experience and delay their travel time. It is precisely because these problems are avoided that the recommendations are more likely to be accepted by users, thus increasing the success rate of carpooling.

[0110] In existing carpooling methods, the ride-hailing platform automatically matches orders from its pool, which may merge orders with significantly different destinations, leading to serious detours. In contrast, this application recommends carpooling services by filtering orders with similar itineraries, which helps reduce detours, avoids increased fares due to excessive detours, and improves the user's carpooling experience.

[0111] Example 1-2:

[0112] In practical applications, users can pre-select a vehicle type according to their needs when hailing a ride, and the ride-hailing platform prioritizes dispatching vehicles that match the user's pre-selected model. For example, some users prefer taxis, while others prefer ride-hailing services. Therefore, in another example, the pre-selected vehicle type corresponding to the ride order can be considered to determine whether to make a carpooling recommendation.

[0113] In practice, if the vehicle type matched with the pre-selected vehicle for the second ride-hailing order is greater than a matching threshold, then they are considered to meet the carpooling criteria and can be recommended for carpooling. This is especially true for second ride-hailing orders that haven't yet secured a ride; the recommended vehicle is more likely to be the user's pre-selected model, making them more likely to accept carpooling and increasing the success rate.

[0114] The vehicle model matching degree can be determined according to the actual situation. For example, if there are multiple pre-selected vehicle models, and the number of identical models in the pre-selected models exceeds a certain limit, then the vehicle model matching degree can be considered to be greater than the matching degree threshold.

[0115] Example 1-3:

[0116] Understandably, after carpooling, the other party will know your pick-up point and destination. Therefore, considering user safety and the likelihood of users accepting the recommendation, in another example, the first pick-up point and the first destination of the first ride-hailing order, as well as the second pick-up point and the second destination of the second ride-hailing order, are all public places.

[0117] In other words, carpooling recommendations should only be made for public locations, while recommendations for non-public locations can be omitted, as this is more likely to be accepted by users and increase the success rate of carpooling. Public locations include restaurants, shopping malls, amusement parks, and train stations. Non-public locations include home addresses and residential areas.

[0118] 2. Secondly, regarding the first notification message, the following example is provided:

[0119] The first notification message can be used to determine whether the first account agrees to merge the first ride-hailing order with the second ride-hailing order, so that the first vehicle can still be used to pick up and drop off the passenger corresponding to the second ride-hailing order. Specifically, the first notification message can allow the user to interact with it to determine whether or not to agree to the merger.

[0120] It should be noted that this application does not impose any limitations on the content, display format, or display location of the first notification information. For ease of understanding, the following examples are provided in this application's embodiments:

[0121] As an example, to help the first account better understand the current carpooling recommendations, the first notification message could include relevant prompts to inform the first account about carpooling recommendations. For example, Figure 1 Examples include "Passengers with similar itineraries within 500 meters of you can be automatically added and intelligently billed by inviting them to ride together."

[0122] As another example, to facilitate user confirmation of whether to agree to the merge, the first notification message may include interactive controls. Specifically, to enable users to easily agree to the merge, the first notification message may include an agreement control, for example... Figure 1 The example shows the "Invite Now" interactive control. Similarly, to allow users to easily refuse consent, the initial notification message can also include a refuse control. For example, it could be... Figure 4 The "Decline Invitation" interactive control in the example could also be... Figure 4 The example shows a close control used to close the first notification message. Of course, in practical applications, the rejection control can be either the "Reject Invitation" interactive control or a close control, depending on the need.

[0123] The display format can be flexibly configured according to actual needs. For example, it can be set to display the first notification information as a message card on the first ride-hailing page. It can also be set as a message pop-up, message floating window, message control, notification bar, etc. Furthermore, the display location can also be flexibly configured according to actual needs. For example, ... Figure 1 Examples of these methods show the first notification information displayed in the map area.

[0124] 3. For the trip information of the second ride-hailing order, the following example is provided:

[0125] The trip information for the second ride-hailing order describes the details of that order and indicates what kind of ride it was. The following example illustrates the specific content of the trip information for the second ride-hailing order:

[0126] As an example, the trip information for a second ride-hailing order may include at least one of the following: the second pick-up point corresponding to the second ride-hailing order, the second destination corresponding to the second ride-hailing order, the passenger information corresponding to the second ride-hailing order, and the trip route from the second pick-up point to the second destination. The passenger information may include, for example, the number of passengers and their category information (such as gender, age, etc.). Furthermore, the trip route from the second pick-up point to the second destination can be referred to as the second trip route, which may refer to the travel route planned by the ride-hailing platform for the second account after initiating the ride-hailing order.

[0127] This allows users to understand the other party's situation, enabling them to independently judge whether the other party meets their needs and decide whether to agree to carpool, thus improving carpooling satisfaction.

[0128] S303: In response to receiving consent for merging from the first account via the first notification message, display the first carpooling result.

[0129] S304: If the first carpooling result indicates that the carpooling was successful, update the first ride-hailing order to the merged order obtained by combining the first ride-hailing order and the second ride-hailing order.

[0130] If the first account agrees to carpooling, the user can agree to merge the ride through the first notification message. In other words, the first notification message allows the user to interact with the account to determine whether or not to agree to merge.

[0131] Accordingly, the terminal can respond to receiving the consent to merge the ride through the first notification information and display the first ride-sharing result. The first ride-sharing result can indicate whether the ride-sharing was successful, specifically whether it was successfully merged with the second ride-hailing order. If the first ride-sharing result indicates successful merging, then the ride-sharing has been successfully completed. At this point, the first ride-hailing order can be updated to a merged order resulting from combining the first and second ride-hailing orders. Accordingly, the aforementioned first vehicle is used to pick up and drop off passengers corresponding to the merged order. That is, it needs to pick up and drop off not only passengers corresponding to the first ride-hailing order but also passengers corresponding to the second ride-hailing order. Furthermore, the merged order can be used to identify the travel route of the first vehicle picking up and dropping off passengers from both the first and second ride-hailing orders.

[0132] Understandably, after a successful carpool, the route can be replanned to avoid detours. For example, a better route would be to go to the first pick-up point, then the second pick-up point, then the first destination, and then the second destination (shorter travel time, fewer detours, less traffic).

[0133] It should also be noted that this application does not impose any restrictions on how the consent merging operation is implemented. As an example, users can agree by clicking the consent control in the first notification message (such as...). Figure 1 The example uses the "Invite Now" interactive control to implement the agreement and merge operation.

[0134] As can be seen from the above technical solution, for the first account that has already hailed a ride, the first ride-hailing page displays the first notification information and the trip information of the second ride-hailing order. The first notification information is used to determine whether the first account agrees to merge the second ride-hailing order with its own first ride-hailing order; that is, the first notification information is used to determine whether the first account wants to invite others to share a ride. Furthermore, the trip information of the second ride-hailing order indicates the specific details of the second ride-hailing order, thus showing what kind of ride-hailing order it is. It is evident that by proactively recommending a second ride-sharing option to the first account that has already hailed a ride, and simultaneously displaying the trip information of the second ride-hailing order, the user of the first account can first understand the details of the ride-sharing order to them before deciding whether to agree to share. Accordingly, in response to the first account's agreement to merge via the first notification information, the first ride-sharing result is displayed, and if the first ride-sharing result indicates a successful share, the first ride-hailing order is updated to a merged order. Based on this, users are given the option to choose which ride-sharing orders to share with, allowing them to decide whether or not to agree to share based on their own preferences. This helps to determine combined orders that satisfy users, improving ride-sharing satisfaction and the overall experience. Furthermore, because the second ride-sharing order is proactively recommended to the first account that has already booked a ride, in scenarios with insufficient capacity, once the first account agrees to share, there is a chance of a successful ride-sharing, allowing other users who are currently trying to book a ride but haven't yet found one to quickly get a ride, thus improving travel efficiency.

[0135] Correspondingly, if no consent to merge is received (e.g., the first account does not perform any operation within a certain period after S302 is implemented), or if the first account receives a rejection of merge via the first notification message, it indicates that the first account does not agree to merge, and therefore the merge will not proceed, thus keeping the first ride-hailing order unchanged. For example, similar to receiving consent to merge, if the user clicks the rejection control in the first notification message (e.g.... Figure 4 The example uses the "Decline Invitation" interactive control (or close control) to implement the refusal to merge operation.

[0136] Alternatively, if the first carpooling result indicates that the carpooling failed, it means that although the first account agreed to carpooling, the carpooling ultimately failed due to other reasons (such as the second account not agreeing to carpooling). In this case, the carpooling will not be merged, and the first ride-hailing order will remain unchanged.

[0137] The above embodiments illustrate the carpooling method provided in this application. For a more comprehensive understanding, this application also provides corresponding embodiments focusing on the following aspects for further explanation. Specifically:

[0138] I. This application does not impose any restrictions on the timing of providing carpooling recommendations to the first account. For ease of understanding, the following example is provided:

[0139] In one example, for the first account that has already hailed a ride, a carpooling recommendation can be provided at any time as long as a suitable second ride order becomes available. That is, for the first account that has already hailed a ride, whether they are waiting for a ride to the pick-up point or already in the ride to their destination, a second ride order can be recommended.

[0140] In yet another example, to ensure a smooth travel experience for the first account holder, it could also be:

[0141] If the first pick-up and drop-off information is used to identify that the first vehicle is heading to the first pick-up point corresponding to the first ride-hailing order, the first notification information and the trip information of the second ride-hailing order will be displayed on the first ride-hailing page. However, if the first pick-up and drop-off information is used to identify that the first vehicle is heading from the first pick-up point to the first destination corresponding to the first ride-hailing order, the first notification information and the trip information of the second ride-hailing order will not be displayed.

[0142] Based on this, for the first account that has already booked a ride, if they are waiting for a ride to their pick-up point, a second ride order can be recommended. If they have already boarded and are heading towards their destination, no further recommendations will be made. This helps ensure a better travel experience for the first account user. Typically, once a user is already in a ride, they want to go directly to their destination and are less likely to accept ride-sharing or waste their time. Therefore, this approach also helps avoid wasting recommendation resources due to rejections after recommendations have been made.

[0143] In practice, while the first vehicle is traveling to the first pick-up point corresponding to the first ride-hailing order, the ride-hailing platform can continuously monitor whether there are similar trips available for carpooling. If a second ride-hailing order is detected, it can be recommended to the first account. Furthermore, while the first vehicle is traveling from the first pick-up point to the first destination corresponding to the first ride-hailing order, the ride-hailing platform can cancel monitoring of the first ride-hailing order, thus ceasing recommendations and saving monitoring resources.

[0144] II. This application does not impose any limit on the number of second ride-hailing orders recommended to the first account. For ease of understanding, the following example is provided:

[0145] As an example, the number of ride-sharing orders can be one. Based on this, a ride-sharing order can be directly recommended to the first account, allowing the user to choose whether or not to share the ride.

[0146] As another example, the number of ride-sharing orders can be multiple. Based on this, multiple ride-sharing orders can be provided to users at once, allowing them to choose according to their needs. This gives users not only the autonomy to agree to ride-sharing but also the autonomy to choose who they share with, which is more conducive to improving ride-sharing satisfaction. In specific implementation:

[0147] The terminal can display a first notification message and trip information corresponding to N second ride-hailing orders on the first ride-hailing page, where N > 1. Correspondingly, in response to the first account's first selection operation for the N second ride-hailing orders, the terminal can determine the M first pre-selected orders selected by the first selection operation, where 1 ≤ M ≤ N. Furthermore, it can obtain the first account's consent to merge the orders with the M first pre-selected orders, as indicated by the first notification message.

[0148] It is evident that recommending multiple carpooling orders to the first account at once, and allowing users to select according to their needs (e.g., selecting M first-selection orders can be considered to meet the user's preferences), gives users not only the autonomy to agree to carpooling but also the autonomy to choose which orders to carpool with, thus improving carpooling satisfaction.

[0149] For more information, please refer to Figure 5 The diagram shown illustrates a method for recommending multiple second ride-hailing orders at once. Figure 5 In the example, taking N=3 as an example, the first account is informed that "there are multiple passengers with similar trips near you, and you can choose to invite them to ride together as needed," along with the pick-up points of these three passengers with similar trips, for the user to choose from. Furthermore, to facilitate user selection, each second ride-hailing order's trip information displays an interactive selection box and prompts such as "First Invitable Order," "Second Invitable Order," and "Third Invitable Order." For example, if the user selects "First Invitable Order" and "Third Invitable Order," i.e., M=2, they can then click "Agree to Invite," indicating their agreement to merge the order with these two.

[0150] Also see Figure 6 As shown, with Figure 5 The examples differ in their display methods. Users can choose according to their needs; please refer to the above explanation for details. It should also be noted that... Figure 5 , Figure 6 These are merely examples and are not intended to be limiting.

[0151] It is understood that this application does not impose any limitations on the setting of N. For example, N can be set based on the number of remaining passengers in the first vehicle. Based on this, N can also be different for different first ride-hailing orders. For example, the more remaining passengers a vehicle can accommodate, the larger N can be set.

[0152] Since the number of passengers a given vehicle can accommodate is fixed, when a user can select from N second ride-hailing orders, if the number of passengers in the selected second ride-hailing order plus the number of passengers in the first ride-hailing order is less than or equal to the number of passengers the first vehicle can accommodate, the remaining unselected second ride-hailing orders become unavailable. If the user then cancels their original selection of a second ride-hailing order, the remaining unselected second ride-hailing orders become available again. This system helps users make a selection from the N second ride-hailing orders.

[0153] To better illustrate the example of recommending multiple second ride-hailing orders at once, the following example is also provided:

[0154] As an example, to assist users in making choices, the estimated carpooling cost can be displayed to the user before they agree to merge, thus helping them select which of the M pre-selected orders to include.

[0155] In specific implementation, before receiving the consent to merge operation implemented through the first notification information, the terminal can respond to the first selection operation instruction to select M first pre-selected orders and display carpooling fare information on the first ride-hailing page. The carpooling fare information is used to indicate the estimated cost when the first ride-hailing order is successfully carpooled with the M first pre-selected orders.

[0156] Based on this, when users select certain second ride-hailing orders, they can see the estimated cost of successfully sharing these rides. This helps users choose which of the aforementioned M first pre-selected orders to share, from the perspective of cost sharing. Typically, the estimated cost may differ depending on which ride-hailing order is chosen. Therefore, this helps users select the first pre-selected orders whose estimated costs meet their expectations, improving ride-sharing satisfaction.

[0157] In this regard, as mentioned above Figure 6 For example, the embodiments also provide such as Figure 7 The image shown is a schematic diagram displaying carpooling fare information. Specifically:

[0158] When a user selects passengers at both pick-up point 1 and pick-up point 3, the system displays "Estimated total fare: 95 yuan, estimated payment: 28 yuan." If the user selects only passengers at pick-up point 3, the system displays "Estimated total fare: 85 yuan, estimated payment: 43 yuan." This information assists the user in making their selection. Of course, Figure 7 This is merely an example and is not intended to be limiting.

[0159] In addition, before receiving the consent to merge the rides via the first notification, the terminal can select M pre-selected orders in response to the first selection operation instruction and display carpooling time information on the first ride-hailing page. This carpooling time information indicates the estimated time when the first ride-hailing order successfully shares a ride with the M pre-selected orders. Specifically, this includes the estimated total time and the estimated time for the passengers in the first ride-hailing order from boarding to alighting. Based on this, the terminal assists the user in making selections from a time perspective.

[0160] For the example of recommending multiple second ride-hailing orders at once, after the first account agrees to merge the second ride-hailing order with M first pre-selected orders, the following example illustrates how the merged order is updated when the ride-sharing is confirmed to be successful:

[0161] One example:

[0162] It is understandable that the first account's agreement to merge with M first pre-selected orders only represents the first account's intention. In actual carpooling, the intentions of second accounts, etc., can also be considered. Therefore, as an example, in the specific implementation of the aforementioned S304, if the first carpooling result indicates successful carpooling with K target orders from the M first pre-selected orders, the first ride-hailing order can be updated to a merged order obtained by merging the first ride-hailing order with the K target orders.

[0163] That is, the M first pre-selected orders refer to the ride-hailing orders that the first account wants to merge with, and the K target orders refer to the ride-hailing orders that are actually successfully merged. The merged orders obtained at this time can be used to identify the passengers of the first ride-hailing order picked up and dropped off by the first vehicle, as well as the travel routes of the passengers corresponding to the K target orders.

[0164] Another example:

[0165] To facilitate understanding, this example uses the first ride-hailing order as a carpooling order, as mentioned above. For carpooling orders, other carpooling orders can be recommended to facilitate successful carpooling. That is, multiple second ride-hailing orders can all be carpooling orders. Furthermore, since the second ride-hailing order is inherently a carpooling order, after the first account that has already booked a ride has selected and agreed to the carpooling, the carpooling can be confirmed directly, improving carpooling efficiency and allowing those who haven't yet booked a ride to quickly find a place to go.

[0166] In specific implementation, S303 may include: the terminal, in response to receiving the consent to merge operation implemented through the first notification information, displays a first carpooling result indicating successful carpooling with M first pre-selected orders. Correspondingly, S304 may include: the terminal updating the first ride-hailing order to a merged order obtained by merging the first ride-hailing order with the M first pre-selected orders.

[0167] That is, for the first ride-sharing order, the second ride-sharing order will also be recommended. After the first account agrees to merge with M first pre-selected orders, the ride-sharing will be confirmed as successful, thus improving ride-sharing efficiency.

[0168] In practical applications, for ride-sharing orders initiated by users, the assigned vehicle may have already been assigned to another vehicle. Therefore, when recommending ride-sharing for the first ride-sharing order, the aforementioned "first account" could refer to the first account assigned to the first vehicle. This allows the first account to choose other ride-sharing orders. Of course, in practice, the "first account" could also be an account that frequently uses ride-sharing services. This allows users who frequently use ride-sharing services to independently choose other ride-sharing orders when they continue to book ride-sharing, thereby improving their ride-sharing experience.

[0169] Third, to avoid overloading, the number of passengers can also be determined. This application does not impose any restrictions on how the number of passengers is determined. For ease of understanding, the following example is provided:

[0170] 3.1 Taking the aforementioned first ride-hailing order as an example, where the order type is carpooling.

[0171] Before a ride-sharing order is initiated, the user usually needs to fill in the number of passengers. Therefore, if the first ride-sharing order is a ride-sharing order, the ride-hailing platform can know the number of passengers corresponding to the first ride-sharing order.

[0172] Furthermore, for the first vehicle that has been selected, the ride-hailing platform also specifies the number of passengers that the first vehicle can accommodate. Therefore, when recommending a ride to the first account, the platform can consider the number of passengers that can still be accommodated and recommend a second ride-hailing order that, after agreeing to carpool, will not exceed the number of passengers that the first vehicle can accommodate.

[0173] For example, in the aforementioned embodiment of recommending N second ride-hailing orders that are also carpooling for the first ride-hailing order, the information of the number of passengers can be combined to determine which second ride-hailing orders that have not yet been booked can be used as the N second ride-hailing orders to be recommended.

[0174] 3.2 Taking the aforementioned first ride-hailing order as an example, where the order type is a specific type.

[0175] For ride-hailing orders of this type, users typically do not need to specify the number of passengers before initiating the ride. Therefore, for this type of ride-hailing order, it is necessary to determine the number of passengers to ensure that the ride is not overloaded. That is, the number of passengers must be determined to ensure that the total number of passengers does not exceed the vehicle's capacity when a ride-sharing is successfully completed. This application provides the following two examples of determining the number of passengers:

[0176] First example:

[0177] When proactively offering carpooling recommendations, a ride can only be completed if the first account agrees. Therefore, as an example, the number of passengers could be determined upon receiving consent to merge.

[0178] In specific implementation, upon receiving the consent to merge the rides via the first notification information, the terminal can display a quantity acquisition control on the first ride-hailing page. This control retrieves the number of passengers corresponding to the first ride-hailing order and supports user interaction to input the number of passengers. Correspondingly, in response to a confirmation operation on the quantity acquisition control, the terminal can obtain a first quantity of passengers corresponding to the first ride-hailing order. Furthermore, if it is determined that the second account corresponding to the second ride-hailing order agrees to merge the first and second ride-hailing orders, and the sum of the first and second quantities is less than or equal to the number of passengers the first vehicle can accommodate, then a first ride-sharing result indicating successful carpooling is displayed. Here, the second quantity refers to the number of passengers corresponding to the second ride-hailing order.

[0179] Based on this, when the first account that has already booked a ride agrees to carpool, the system proactively inquires about the number of passengers in the first account. This ensures that the carpooling is successful only when both parties agree and the total number of passengers after carpooling does not exceed the capacity, thus guaranteeing that the carpooling is valid and protecting users' travel needs.

[0180] It should be noted that the method for obtaining the second quantity can also depend on the type of the second ride-hailing order. For example, if the second ride-hailing order is a private order, the quantity can be obtained by displaying a quantity acquisition control on the second ride-hailing page when the second account agrees to carpooling (as shown in the example in Figure 2, where "Accept Invitation" is clicked). Please refer to the example above for clarification.

[0181] For the first example, in order to facilitate understanding, embodiments of this application also provide, as follows: Figure 8The diagram illustrates how to determine the initial number of passengers when the first account has already booked a ride. Specifically, after the user clicks "Invite Now" (i.e., agrees to carpool), a control is displayed to retrieve the number of passengers, allowing the user to input the number of passengers (e.g., clicking "-" or "+" to adjust the number of passengers) and then click "Submit." Figure 8 In the example, the first quantity = 2.

[0182] Second example:

[0183] To avoid situations where users agree to carpooling but the carpool fails due to overloading, another example is to determine the number of passengers before making the recommendation.

[0184] In practice, if the first ride-hailing order is of a special type, the following may also be included before displaying the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page:

[0185] The terminal can display a quantity acquisition control on the first ride-hailing page. Correspondingly, in response to a confirmation operation on the quantity acquisition control, the terminal can obtain the first quantity of passengers corresponding to the first ride-hailing order. At this point, ride-hailing orders that will not cause overloading and have not yet been booked can be filtered based on the first quantity and designated as second ride-hailing orders to be recommended to the first account. After recommendation, the sum of the first and second quantities is less than or equal to the number of passengers that the first vehicle can accommodate, where the second quantity is the number of passengers corresponding to the second ride-hailing order.

[0186] Therefore, by determining the number of passengers before making a ride recommendation, a second ride-sharing order can be determined based on the number of passengers, ensuring that the vehicle is not overloaded after the user agrees to carpool. This avoids the situation described above where the user agrees to carpool but the carpool fails due to overloading, thus improving the user's carpooling experience.

[0187] It should be noted that the method for obtaining the second quantity can also be related to the type of the second ride-hailing order. For example, if the second ride-hailing order is a specific type, the quantity can be obtained by displaying a quantity retrieval control on the second ride-hailing page before recommending the first ride-hailing order. Please refer to the example above for clarification.

[0188] For the second example, in order to facilitate understanding, embodiments of this application also provide, as follows: Figure 9 The illustration shows another approach to determining the initial number of passengers when the first account has already booked a ride. Specifically, before the recommendations (i.e., displaying the first notification information and the trip information of the second ride order), a quantity retrieval control is displayed so that the user can input their number of passengers (e.g., clicking "-" or "+" to adjust the number of passengers) and then click "Submit". Figure 9In the example, the first quantity is 2. Then, the first account is recommended to see the first notification message and the trip information for the second ride-hailing order.

[0189] IV. This application does not impose any restrictions on how a successful carpooling is determined. For ease of understanding, the following example is provided:

[0190] One example:

[0191] To ensure a smooth ride-sharing experience for both parties, as an example, the first account that has already secured a ride can choose whether or not to agree to the ride-sharing. Similarly, the second account that hasn't secured a ride can also choose whether or not to agree to the ride-sharing. With this approach, both parties must agree to merge the ride when the ride-sharing is confirmed.

[0192] In practice, the terminal can respond to the first account's agreement to merge the ride-sharing order via the first notification information by displaying a carpooling waiting message. This message indicates that a carpooling is in progress, such as "Carpooling in progress, please wait a moment." Next, if it is determined that the second account corresponding to the second ride-hailing order agrees to merge the first and second ride-hailing orders, it means both parties agree to carpool. At this point, the terminal can display the first carpooling result indicating successful carpooling and then remove the carpooling waiting message. For example, as shown in Figure 2, user B clicked "Accept Invitation," indicating that the second account also agreed to merge the first and second ride-hailing orders and share the first vehicle.

[0193] Conversely, if it is determined that the second account corresponding to the second ride-hailing order refuses to merge the first and second ride-hailing orders, it means that the other party is unwilling to share a ride. Therefore, the first ride-hailing result, used to indicate a failed ride-hailing, can be displayed, and the display of ride-hailing waiting information can be removed. That is, it indicates that this ride-hailing attempt has failed. In this case, the first ride-hailing order remains unchanged.

[0194] Based on this, users who have not yet been able to hail a ride can also have the right to choose whose car to share with, allowing them to carpool according to their own preferences and improving carpooling satisfaction.

[0195] Other examples:

[0196] To ensure effective carpooling, factors such as the number of passengers can be considered. When carpooling is successful, the number of passengers corresponding to the merged order can be less than or equal to the number of passengers that the first vehicle can accommodate.

[0197] In practical implementation, to ensure that overloading is not prevented, recommendations can be made based on the number of passengers, and the number of passengers can be determined before determining whether the carpooling is successful when passengers agree to share. For details on these aspects, please refer to the foregoing detailed descriptions of the relevant embodiments.

[0198] Furthermore, when recommending a second ride-sharing order of the same type to the first ride-sharing order (which is also a carpooling order), the first account can immediately complete the carpooling process upon agreeing to it. For details, please refer to the detailed description in the aforementioned embodiments.

[0199] V. This application does not impose any restrictions on users' ability to personalize carpooling recommendation services. For ease of understanding, the following example is provided:

[0200] The carpooling method provided in this application proactively offers carpooling recommendations to users. However, some users prefer to travel alone and are not comfortable sharing rides with others. To meet the needs of different users, the ride-hailing platform's application or mini-program can support personalized settings for the carpooling recommendation service, specifically including enabling, disabling, or disabling during specific time periods. When enabled, the service proactively offers carpooling recommendations for ride-hailing orders initiated by that account; when disabled, carpooling recommendations are no longer offered.

[0201] To facilitate user settings, in one possible implementation, upon receiving a rejection of the merging operation from the first account via a first notification, the terminal can display settings controls for the carpooling recommendation service on the first ride-hailing page. Correspondingly, in response to the settings operation performed through these controls, the terminal disables the carpooling recommendation service for ride-hailing orders initiated by the first account within the set time period. The set time period is determined based on the settings operation, i.e., the user-defined period during which they wish to disable the carpooling recommendation service. For example, the user might select one of "Don't recommend again today," "Don't recommend again within a week," or "Never recommend again," and then determine the corresponding set time period accordingly.

[0202] Based on this, we first proactively offer carpooling recommendations to users, allowing them to become aware of this service during their ride-hailing process. Then, when a user declines a carpool, assuming they may not prefer carpooling, we display settings controls on the ride-hailing page, enabling them to personalize their ride immediately upon declining. This timing of displaying the settings controls directly on the ride-hailing page eliminates the need for users to navigate to other pages or search for carpooling recommendations within applications or mini-programs, making personalization more convenient.

[0203] For more information, please refer to Figure 10 The diagram shown illustrates the settings for a ride-sharing recommendation service. Figure 10In the example, the first notification message also includes the aforementioned "Reject Invitation" rejection control. When the user clicks "Reject Invitation," the user rejects the merging operation. At this time, the first ride-hailing page displays the settings control for the carpooling recommendation service, specifically informing the user that "you can customize the carpooling recommendation service" and providing four options: "Always On," "Do Not Recommend Today," "Do Not Recommend for a Week," and "Never Recommend" (this is just an example and is not intended to limit the scope).

[0204] For example, when a user selects "Don't recommend again for a week" and then clicks the close button (shown as "×" in the image), the setting is complete. Correspondingly, the aforementioned setting period can be a week starting from the current time. If the user initiates a ride-hailing order during this period, other ride-sharing options will no longer be recommended to them.

[0205] Understandably, since the user has already declined the ride-sharing offer, it's possible to remove the display of the first notification message and the trip information for the second ride-hailing order. Also, Figure 10 This is merely an example and is not intended to be limiting.

[0206] The above embodiments illustrate the proactive provision of ride-sharing recommendations to users who have already hailed a taxi. It is understood that recommendations can also be proactively provided to users who are currently trying to hail a taxi but have not yet found one, so that they can quickly secure a ride. For ease of understanding, this application embodiment uses a first account that is currently trying to hail a taxi but has not yet found one as an example, providing the following illustration:

[0207] Firstly, from an overall perspective, providing carpooling recommendations to accounts that have not yet secured a ride can, in practice, include A1-A4:

[0208] A1: Display ride waiting information on the first ride-hailing page.

[0209] The ride-hailing waiting information can be used to identify the vehicle being assigned to the first ride-hailing order. That is, after a user initiates a ride-hailing order, the ride-hailing platform is dispatching a vehicle. In practical applications, this could be implemented by displaying the first ride-hailing page and showing the ride-hailing waiting information upon receiving the first ride-hailing order from the first account.

[0210] A2: While displaying ride-hailing waiting information, that is, while waiting for a ride to be dispatched before hailing one, display the third notification information and the trip information of the third ride-hailing order on the first ride-hailing page.

[0211] The third ride-hailing order meets the carpooling requirements with the first ride-hailing order, indicating that a ride has already been booked, specifically corresponding to the second vehicle. The third notification information is used to determine whether the first account agrees to merge with the third ride-hailing order, i.e., whether they agree to travel together in the second vehicle corresponding to the third ride-hailing order. The trip information of the third ride-hailing order indicates its specific details, thus revealing the nature of the third ride-hailing order.

[0212] A3: In response to receiving the consent to merge from the first account via a third notification, display the second carpooling result.

[0213] A4: If the second carpooling result indicates a successful carpool, update the first ride-hailing order to a merged order obtained by combining the first ride-hailing order and the third ride-hailing order, and display the second pick-up and drop-off information on the first ride-hailing page.

[0214] The second pick-up and drop-off information is used to identify the second vehicle used to pick up and drop off passengers corresponding to the third ride-hailing order and passengers corresponding to the first ride-hailing order. That is, a successful carpool indicates that the passengers of the first ride-hailing order and the passengers of the third ride-hailing order are traveling together in the second vehicle.

[0215] It is evident that for users who haven't yet secured a ride, the system proactively provides a third ride-sharing option and displays the trip information of this third order. This allows users to understand which ride-sharing order they will be sharing with, thus assisting them in deciding whether to accept the ride-sharing. Based on this, users who haven't yet secured a ride also have the right to choose who they share with, which helps them select a ride that suits their preferences and improves ride-sharing satisfaction.

[0216] For more information, please refer to Figure 11 The illustration shows a carpooling recommendation for the first account that has not yet booked a ride. Specifically:

[0217] exist Figure 11 In the example, the trip information of the aforementioned third ride-hailing order includes the third pick-up point, the third destination, and the third route (i.e., the route from the third pick-up point to the third destination), so that users can intuitively understand the other party's situation and thus judge whether it meets their expectations (such as whether it is convenient enough or whether it will cause too much detour), and then decide whether to agree to carpool.

[0218] For example, after a user decides to carpool and clicks "Accept Invitation," the combined order and second pick-up information are displayed after the carpool is successfully completed. Specifically, the combined route is shown as "Third Pick-up Point → First Pick-up Point → Third Destination → First Destination," and the user is informed that "The driver has arrived at the third pick-up point and will be heading to the first pick-up point," as well as the second vehicle's license plate number "22222," etc.

[0219] Understandably, if the first ride-hailing order and the third ride-hailing order are successfully shared, there is no need to dispatch a car for the first ride-hailing order. Consequently, the display of the first pick-up and drop-off information will no longer be required.

[0220] Furthermore, regarding the embodiments provided in the first aspect above, it should also be noted that:

[0221] Regarding the third notification information, no limitations are made; for details, please refer to the detailed description of the relevant embodiments regarding the first notification information, and also to the exemplary description of the second notification information displayed on the second ride-hailing page in the example of Figure 2 above. Regarding the second pick-up and drop-off information, no limitations are made; for details, please refer to the relevant description of the first pick-up and drop-off information above, and also to... Figure 1 Examples include the display of "The driver has arrived at the first pick-up point and will be heading to the second pick-up point" after a successful carpool.

[0222] There are no restrictions on how to implement the consent merging operation through the third notification information. For details, please refer to the aforementioned detailed explanation of implementing the consent merging operation through the first notification information, and also to the exemplary illustration in the example of user B clicking "Accept Invitation" in the second notification information on page [B-②] in Figure 2. There are also no restrictions on taxi waiting information. For example, please refer to the "Calling a driver at full speed, please wait patiently" message on page [B-②] in the example of Figure 2.

[0223] Furthermore, this application does not impose any restrictions on the trip information for third-party ride-hailing orders. For ease of understanding, the following example is provided:

[0224] First, similar to the trip information of the second ride-hailing order mentioned above, the trip information of the third ride-hailing order may include at least one of the following: the third pick-up point corresponding to the third ride-hailing order, the third destination corresponding to the third ride-hailing order, the passenger information corresponding to the third ride-hailing order, and the trip route from the third pick-up point to the third destination.

[0225] Furthermore, since the recommendations are made to users who haven't yet booked a ride, the trip information for the third ride-sharing order can also include the type of vehicle used in the second car. This allows users to be directly informed what type of vehicle they will be traveling in if they agree to carpool, thus assisting them in deciding whether or not to agree to the carpool.

[0226] In practical applications, the trip information for third-party ride-hailing orders can include at least one of the above-mentioned items. This allows users to understand the other party's situation, better judge whether the other party meets their needs, and thus decide whether to agree to carpool, thereby improving carpooling satisfaction.

[0227] When actually hailing a ride, users can specify the vehicle type according to their needs (such as a taxi or a private car). Therefore, in another possible implementation, to improve the success rate of carpooling, a second vehicle matching the user's specified vehicle type can be recommended to users who have not yet hailed a ride. Specifically, taking the recommendation to the first account that has not yet hailed a ride as an example, the aforementioned second vehicle belongs to the pre-selected vehicle type corresponding to the first ride-hailing order. The pre-selected vehicle type corresponding to the first ride-hailing order is the vehicle type specified by the first account for that first ride-hailing order.

[0228] Therefore, the types of vehicles used for carpooling should also meet the user's needs, making them more likely to be accepted by the user and thus improving the success rate of carpooling.

[0229] Secondly, regarding the timing of recommending a third ride-hailing order to the first account that has not yet secured a ride, this application does not impose any restrictions. For ease of understanding, the following example is provided:

[0230] In one example, once it is determined that the first account has not yet booked a ride, a third ride-hailing order can be proactively recommended to it, i.e., the aforementioned A2 can be executed.

[0231] In another example, since the first account hasn't yet booked a ride, the third account's consent is required for a successful carpool. Therefore, the recommendation to the first account can be made only after confirming the third account's agreement to merge the first and third ride orders. That is, when executing step A2 above, it's already confirmed that the third account has agreed to the carpool. In this case, the third notification message also indicates that the third account has agreed to merge the first and third ride orders. This avoids situations where the first account agrees but the third account disagrees, leading to a failed carpool and improving the user's carpooling experience.

[0232] For further details, please refer to the example in Figure 2, which illustrates the timing of recommending the first ride-hailing order to the second account.

[0233] Thirdly, this application does not impose any limit on the number of third-party ride-hailing orders recommended to the first account. For ease of understanding, the following example is provided:

[0234] As an example, the number of third-party ride-hailing orders can be one. Based on this, a ride-sharing order that can be shared is directly recommended to the first account, allowing the user to choose whether or not to share the ride.

[0235] As another example, the number of ride-sharing orders can be multiple. Based on this, multiple ride-sharing orders can be provided to users at once, allowing them to choose according to their needs. This gives users not only the autonomy to agree to ride-sharing but also the autonomy to choose who they ride with, which is more conducive to improving ride-sharing satisfaction. In specific implementation:

[0236] The terminal can display a third notification message and trip information corresponding to R third ride-hailing orders on the first ride-hailing page, where R > 1. Correspondingly, the terminal can respond to the first account's second selection operation regarding the R third ride-hailing orders, confirming that the second selection operation indicates the selection of a second pre-selected order, which is one of the R third ride-hailing orders. Furthermore, it can obtain the first account's consent to merge with the second pre-selected order, implemented through the third notification message. Here, the second pre-selected order refers to the third ride-hailing order specified by the first account that they wish to share a ride with.

[0237] It is evident that when recommending carpooling to users who haven't yet secured a ride, multiple carpooling options are suggested at once, allowing users to choose one based on their needs. This gives users not only the autonomy to choose whether or not to carpool, but also the autonomy to select who they will share the ride with, thus improving carpooling satisfaction.

[0238] It is understandable that, similar to the aforementioned implementation of recommending N second ride-hailing orders to accounts that have already booked a ride, when recommending R third ride-hailing orders to accounts that have not yet booked a ride, information such as carpooling fare and carpooling time can be displayed when the user selects one, to assist the user in deciding which one to choose. For details on this, please refer to the detailed descriptions of the aforementioned related embodiments, which will not be repeated here.

[0239] For an example of recommending R third-party ride-hailing orders at once, please refer to [link / reference]. Figure 12 The diagram shown illustrates a method for recommending multiple third-party ride-hailing orders at once. Figure 12 In the example of R=3, the specific details are as follows:

[0240] The trip information for the three third-party ride-hailing orders corresponds to their respective pick-up points, namely pick-up point 4, pick-up point 5, and pick-up point 6 shown in the image. When a user selects a passenger invitation at pick-up point 4, the system displays "Estimated total cost 55 yuan, estimated payment 28 yuan" and "Estimated arrival time at your destination in 23 minutes." When a user selects a passenger invitation at pick-up point 6, the system displays "Estimated total cost 65 yuan, estimated payment 33 yuan" and "Estimated arrival time at your destination in 30 minutes."

[0241] Based on this, it can better assist users in deciding which option to choose, and after making a selection, they can click "Accept Invitation".

[0242] For the example of recommending R third-party ride-hailing orders at once, in practical implementation, it is also possible to:

[0243] In one example, users can be allowed to choose one of R invitations to accept, which helps to avoid wasting vehicle resources.

[0244] In another example, users can be supported in selecting T (1 < T < R) from R to accept invitations. Correspondingly, ride-sharing can be prioritized (e.g., according to the order in which users selected them, with earlier selections having higher priority), prioritizing ride-sharing with the user with the highest priority. If a ride-sharing is successful, all the better; if not, the user can try to share with the user with the second highest priority. Based on this, the ability to support users selecting multiple rides at once increases the likelihood of successful ride-sharing, thus improving the success rate.

[0245] Fourthly, to avoid overloading, the number of passengers can be determined. This application does not impose any restrictions on how the number of passengers is determined. For ease of understanding, the following example is provided:

[0246] It is understood that the method for determining the number of passengers is similar to the method for determining the number of passengers in the aforementioned embodiment of recommending a second ride order to the first account that has already booked a ride. Please refer to the detailed description of the aforementioned related embodiments.

[0247] To better understand this, we will use the first ride-hailing order as an example, with the following illustration:

[0248] First example:

[0249] A combination can only be formed if the users agree. Therefore, as a first example, the number of passengers could be determined upon receiving consent to merge the rides. In specific implementation:

[0250] The terminal can respond to receiving a consent to merge the rides via a third notification message by displaying a quantity acquisition control on the first ride-hailing page. Accordingly, in response to a confirmation action on the quantity acquisition control, it acquires a first quantity of passengers corresponding to the first ride-hailing order. Furthermore, if it is determined that the third account corresponding to the third ride-hailing order agrees to merge the first and third ride-hailing orders, and the sum of the first and third quantities is less than or equal to the number of passengers the second vehicle can accommodate, a second ride-sharing result indicating a successful carpool is displayed. Here, the third quantity is the number of passengers corresponding to the third ride-hailing order.

[0251] Based on this, when the first account that has not yet booked a ride agrees to carpool, the system proactively inquires about the number of passengers in the first account. This ensures that the carpool is successful only when both parties agree to carpool and the total number of passengers after carpooling does not exceed the capacity, thus guaranteeing that the carpool is valid and protecting users' travel needs.

[0252] For more information, please refer to Figure 13 The diagram illustrates how to determine the initial number of passengers when the first account has not yet secured a ride. Specifically, after the user clicks "Invite Now" (i.e., agrees to carpool), a quantity acquisition control is displayed so that the user can input the number of passengers (e.g., by clicking "-" or "+" to adjust the number of passengers) and then click "Submit". For example, the initial quantity = 2.

[0253] Second example:

[0254] To avoid situations where users agree to carpooling but the carpool fails due to overloading, in the second example, the number of passengers can be determined before the recommendation. In practical implementation:

[0255] If the first ride-hailing order is of the exclusive type, then before displaying the third notification information and the trip information of the third ride-hailing order on the first ride-hailing page, it may also include:

[0256] The terminal can display a quantity acquisition control on the first ride-hailing page. Correspondingly, in response to a confirmation operation on the quantity acquisition control, the terminal can obtain the first quantity of passengers corresponding to the first ride-hailing order. At this point, ride-hailing orders that will not cause overloading and have already been booked can be filtered based on the first quantity and recommended as the third ride-hailing order. After recommendation, the sum of the first and third quantities is less than or equal to the number of passengers that the second vehicle can accommodate, where the third quantity is the number of passengers corresponding to the third ride-hailing order.

[0257] Therefore, by determining the number of passengers before making a recommendation, the recommended third ride-sharing order can be determined based on the number of passengers, ensuring that the number of passengers does not exceed the vehicle's capacity after the user agrees to carpool. This avoids the situation mentioned above where the user agrees to carpool but the carpool fails due to overcrowding, thus improving the user's carpooling experience.

[0258] For more information, please refer to Figure 14 The illustration shows another approach to determining the initial number of passengers before the first account has secured a ride. Specifically, before the recommendation (i.e., displaying the third notification information and the trip information of the third ride-hailing order), on the first ride-hailing page displaying the first pick-up and drop-off information, a quantity acquisition control is first displayed so that the user can input their number of passengers (e.g., clicking "-" or "+" to adjust the number of passengers) and then click "Submit," for example, the initial quantity = 2. Afterwards, the recommendation is made to the first account, and the corresponding third notification information and trip information of the third ride-hailing order can be displayed.

[0259] Regarding the embodiments provided in the fourth aspect, it is understood that the third quantity refers to the number of passengers corresponding to the third ride-hailing order, and that the third ride-hailing order indicates that a ride has already been booked (the second vehicle has been booked). Therefore, for the method of determining the third quantity, please refer to the detailed descriptions in sections 3.1 and 3.2 above, which will not be repeated here.

[0260] Fifthly, the service also supports personalized settings for ride-sharing recommendations, and this application does not impose any limitations on this. For ease of understanding, the following example is provided:

[0261] It is understandable that the methods for supporting personalized settings for ride-sharing recommendation services are similar to those in the aforementioned embodiments. For example, ride-hailing platform applications or mini-programs can support personalized settings for ride-sharing recommendation services, specifically including enabling, disabling, or disabling during specific time periods. For details, please refer to the detailed descriptions in the aforementioned embodiments.

[0262] The difference from the aforementioned embodiments lies in the following: For users who have not yet hailed a ride:

[0263] If a user refuses to share a ride for the first time, considering that the user has not yet been able to hail a ride, it is initially assumed that the reason for the refusal is that the third recommended ride-sharing order does not meet the user's expectations. In this case, other ride-sharing orders that have already been booked can be recommended to the user so that the user can quickly find a ride and share a ride with someone who meets their preferences.

[0264] Of course, to ensure a good user experience, if a user repeatedly refuses a ride-hailing order (e.g., three times in a row), it can be assumed that the user does not like carpooling. Therefore, the aforementioned settings controls can be directly displayed on the ride-hailing page so that users can easily complete their personalized settings. For details, please refer to the detailed descriptions of the aforementioned embodiments and... Figure 10 An exemplary description.

[0265] Sixthly, for accounts that have not yet secured a ride, the system recommends available ride-sharing options and continues to dispatch vehicles for the user to choose from. The application provides the following example for this:

[0266] After recommending ride-sharing options to users who haven't yet booked a ride, and before the user makes a choice, it's uncertain whether they will agree to carpooling. To ensure a smooth travel experience, the system can continue to dispatch vehicles. Furthermore, when a vehicle is dispatched, the user can choose between their own booked ride or the recommended carpooling option. This relates to the aforementioned S301, where the first pick-up / drop-off information is displayed on the first ride-hailing page. In specific implementation:

[0267] Before receiving the consent to merge via a third notification, in response to determining that the first vehicle corresponds to the first ride-hailing order, a selection control for the first vehicle is displayed on the first ride-hailing page. That is, after recommending a third ride-hailing order to the user but before the user makes a selection, a vehicle is dispatched for the first ride-hailing order (specifically, the aforementioned first vehicle), hence the display of the selection control for the first vehicle. This selection control allows user interaction to determine whether the first account agrees to the first vehicle being used to pick up and drop off the passenger corresponding to the first ride-hailing order.

[0268] Accordingly, the terminal can respond to a confirmation operation on the selection control, which is used to instruct the first account to agree to the first vehicle for picking up and dropping off the passenger corresponding to the first ride-hailing order. That is, the user has selected to travel by the first vehicle, and the first pick-up and drop-off information can be displayed on the first ride-hailing page, as well as the third notification information and the trip information of the third ride-hailing order can be canceled.

[0269] It is evident that for users who haven't yet secured a ride, the system proactively recommends ride-sharing options and continuously dispatches vehicles. When a user hasn't selected a recommended ride and a vehicle has been dispatched, they can choose the ride they booked themselves. Based on this, two options are provided for users to choose from based on their needs. For example, if they want to share the fare, they can choose a recommended ride-sharing option. Alternatively, if they want to travel alone in the vehicle they booked, they can directly choose the vehicle dispatched by the ride-hailing platform.

[0270] For more information, please refer to Figure 15 The diagram shown illustrates a selection control. Figure 15 In the example, users are given two options: accept the invitation to carpool with others, or book a ride immediately in a vehicle with license plate number 11111. This allows users to choose according to their needs, improving their travel experience.

[0271] For example, in Figure 15 In the example, if a user clicks "Use a car now," it's assumed the user has chosen a ride they've already booked. Therefore, the initial pick-up and drop-off information can be displayed, informing the user that "the driver is on their way, 1 kilometer away, estimated 3 minutes," and showing the license plate number "11111." The route the vehicle is taking to the initial pick-up point and the route from the initial pick-up point to the final destination can also be shown, allowing the user to see the trip video and the location of the initial vehicle. Of course, once the user has chosen a ride they've already booked, the display of third-party notifications and trip information for third-party ride-hailing orders can be canceled to avoid interfering with the user's journey.

[0272] Correspondingly, if a user chooses carpooling, meaning the terminal receives the consent to merge from the first account via a third-party notification, the selection control can be removed. This cancels the assigned vehicle, allowing it to be used for other passengers, thus promoting a more efficient allocation of vehicle resources.

[0273] To ensure users can successfully travel, this application embodiment also provides a timing for canceling the display of the selection control, specifically:

[0274] Upon receiving confirmation of the first account's consent to the carpooling operation via a third notification, and upon receiving a second carpooling result indicating successful carpooling, the terminal cancels the display of the selection control.

[0275] As can be seen, the selection control is only removed from the display when a user selects carpooling and confirms the carpooling is successful. Therefore, if a user selects carpooling but the carpooling fails for other reasons (such as the other party disagreeing), the selection control remains displayed on the first ride-hailing page, allowing the user to still choose a ride and ensuring a successful trip. This approach not only guarantees users' travel needs but also facilitates the rational allocation of vehicle resources.

[0276] Understandably, in actual ride-hailing operations, to maximize the utilization of vehicle resources, the duration of the selection control display can be determined. For example, while displaying the selection control, a countdown timer could be shown simultaneously, such as "The driver will leave in 20 seconds." This encourages users to make their selections as needed as quickly as possible, allowing for a more efficient allocation of vehicle resources after the user's choice (e.g., if the user chooses carpooling, the vehicle can be canceled and reassigned to another ride-hailing order).

[0277] For example, it can be Figure 15 In the example, "Use a car immediately" is changed to "Use a car immediately (the driver will leave in 20 seconds)", and the 20-second countdown result can be dynamically updated before the user makes a selection.

[0278] The above-mentioned embodiments illustrate how to proactively provide carpooling recommendations to users who are trying to hail a ride but have not yet managed to get one.

[0279] It is also understandable that, in the example of Figure 2, the first ride-hailing order represents those who have already hailed a ride, and the second ride-hailing order represents those who have not yet hailed a ride. When recommending rides to the second account, one or multiple first ride-hailing orders can be recommended at once. Alternatively, after recommending a ride but before the second account makes a selection, a vehicle can be dispatched, and a selection control can be displayed after a vehicle is dispatched, allowing user B to choose to carpool or select the ride they have already hailed, etc. For details on these aspects, please refer to the detailed description of the relevant embodiments for recommending rides to the first account that has not yet hailed a ride, which will not be repeated here.

[0280] The above embodiments have provided a detailed description of the carpooling method provided in this application. In summary: when a user hails a ride, the system matches ride-hailing orders with similar itineraries. This involves two aspects: firstly, inquiring if users who have already secured a ride want to invite other nearby users to share; and secondly, inquiring if users who haven't yet secured a ride want to accept invitations from other nearby users. If both parties agree, the two ride-hailing orders can be automatically merged into one, allowing those who have already secured a ride to share the fare, and enabling those who haven't yet secured a ride to depart as quickly as possible.

[0281] Furthermore, for ride-hailing platforms, this helps increase the order matching rate. A high order matching rate means that more people can successfully travel when vehicle resources are limited, thus generating more revenue. It can also alleviate the problem of insufficient transportation capacity during peak hours, where vehicle resources are scarce, causing many people to be unable to hail their own car or have to wait a long time to hail a car.

[0282] Furthermore, the system allows users to choose whether or not to carpool during the matching process, enabling them to agree or decline according to their own preferences. Compared to related technologies where users select "carpooling mode" or "ridesharing mode" to initiate a ride order, and the ride-hailing platform matches users from its order pool, with users passively accepting the matching results, this application is beneficial in improving user satisfaction and the overall carpooling experience.

[0283] Furthermore, the merging process is automatic. Specifically, the pick-up and destination of the ride-hailing order that hasn't yet secured a ride are automatically added to the route of the ride-hailing order that has already secured a ride. For merged orders, the ride-hailing platform can automatically calculate and replan the optimal route (e.g., more time-efficient, or smoother and less congested). Correspondingly, the pick-up and destination of the ride-hailing order that hasn't yet secured a ride can be referred to as waypoints, i.e., other destinations the driver will pass through while picking up and dropping off the passenger.

[0284] In another related technology, a carpooling method allows users who have already hailed a ride to actively add waypoints (such as the pick-up and drop-off points of the other party) to facilitate carpooling. However, this method requires knowing the other party's pick-up and drop-off points and necessitates manual addition by the user, resulting in low carpooling efficiency and a poor user experience. In contrast, this application automatically adds waypoints, eliminating the need for manual addition by the user, which improves carpooling efficiency and enhances the user's carpooling experience.

[0285] It is understandable that after a successful carpooling session, both parties still need to pay the fare upon completion of the combined order (i.e., the combined trip ends). This application provides the following example to illustrate this:

[0286] In practice, ride-hailing platforms can automatically calculate the total fare and the individual fares for both parties sharing the ride. For example, they can calculate the fare based on the distance traveled together versus traveling alone. After confirmation, the platform can initiate payment notifications or automatically deduct the fare.

[0287] To facilitate understanding, this application provides an embodiment using carpooling as an example from the aforementioned example in Figure 2, providing the following... Figure 16 The diagram illustrates a carpooling trip, where user A and user B are sharing a ride. User A's device displays a first ride-hailing page, and user B's device displays a second ride-hailing page. Specifically:

[0288] During the trip, both the first and second ride-hailing pages displayed trip-related information, such as trip details for combined orders and the vehicle's license plate number. Figure 16 In the example, the trip information for the combined order is specifically identified as follows: the first vehicle (license plate number 11111) arrives at the first pick-up point at 12:00, arrives at the second pick-up point at 12:05, is expected to arrive at the first destination at 12:28, and is expected to arrive at the second destination at 12:33.

[0289] After the trip, the ride-hailing platform can intelligently split the fare, allowing for cost-sharing (AA). After payment, the total fare and each party's individual payment will be displayed on their respective ride-hailing pages. See [link / reference] for details. Figure 16 .

[0290] The carpooling method provided in this application has been described in detail through the above embodiments. For a more comprehensive understanding, this application also provides, for example... Figure 17 The diagram shown illustrates an interactive process based on carpooling. Specifically:

[0291] A ride-hailing platform can refer to an online platform that provides ride-hailing services to users, such as taxi booking and ride-hailing services. For example, it can be a ride-hailing application or mini-program running on a device. In practical applications, it can be an aggregation platform capable of processing ride-hailing orders initiated by individual users, calling the trip matching system to search for similar trips, proactively providing carpooling recommendations to users after finding similar trips, merging orders using the trip matching system, updating trip details with transportation providers, using the payment system for intelligent billing and revenue sharing, and processing order status updates after the trip ends.

[0292] A trip matching system is typically a system within a ride-hailing platform. It is mainly used to receive similar trip search requests from the ride-hailing platform, search for similar trips based on information such as the pick-up point and destination of each ride-hailing order, return the search results to the ride-hailing platform, receive order merging requests from the ride-hailing platform, and return merged orders (such as automatically adding the trip information of the second ride-hailing order to the trip information of the first ride-hailing order).

[0293] A transportation provider can refer to both the provider and manager of vehicle resources. They are responsible for receiving ride-hailing dispatch information from ride-hailing platforms (to dispatch vehicles to users), accessing map services to obtain the optimal route, returning the optimal route to the ride-hailing platform so that the merged trip can begin based on the optimal route, and also for actual vehicle dispatching and driver management, as well as notifying ride-hailing platforms of changes in transportation capacity.

[0294] Map services provide map-related capabilities such as electronic maps, location services, and navigation to help users plan their routes, assist with travel, and avoid detours. They are also used to connect transportation capacity for driver and passenger information sharing optimization. Specifically, they receive requests from transportation providers for optimal routes and automatically calculate and return the optimal route based on the trip information of merged orders.

[0295] The payment system processes payment requests initiated by users on ride-hailing platforms. Specifically, it receives fare calculation and deduction requests from the ride-hailing platform, intelligently calculates the fare for both parties in a carpool based on the trip information of combined orders, executes automatic deductions, and notifies users of successful deductions.

[0296] Next, with Figure 17 For example, the interaction process between the parties involved in carpooling will be illustrated:

[0297] S1701: User A initiates their first ride-hailing order on the ride-hailing platform.

[0298] Accordingly, the ride-hailing platform records the first pick-up point and the first destination for user A and generates the first ride-hailing order.

[0299] S1702: User B initiates a second ride-hailing order on the ride-hailing platform.

[0300] Correspondingly, the ride-hailing platform records the second pick-up point and second destination for user B and generates a second ride-hailing order.

[0301] S1703: Search for similar trips.

[0302] The ride-hailing platform calls the trip matching system to search for similar trips. For example, a similar trip is defined as a trip where the distance between two pick-up points is less than 1 kilometer and the distance between two destinations is less than 1 kilometer.

[0303] S1704: Return to a similar itinerary.

[0304] The trip matching system returns similar trips to ride-hailing platforms. Figure 17 In the example, the first ride-hailing order and the second ride-hailing order are similar trips.

[0305] S1705: Inquire whether to invite user B to ride together.

[0306] The ride-hailing platform notifies user A of passengers with similar itineraries and asks user A if they would like to invite user B to ride with them.

[0307] S1706: Inviting user B to ride together.

[0308] User A clicks "Invite Now" on the ride-hailing platform to invite User B to ride with them.

[0309] S1707: Inquire whether to accept user A's invitation.

[0310] The ride-hailing platform notified user B that a passenger with a similar itinerary was inviting them to ride together, and asked user B whether they would accept user A's invitation.

[0311] S1708: Accept user A's invitation.

[0312] User B clicks "Accept Invitation" on the ride-hailing platform, accepting User A's invitation.

[0313] S1709: Merge the first ride-hailing order and the second ride-hailing order.

[0314] The ride-hailing platform uses its trip matching system to merge the first and second ride-hailing orders. Specifically, it might cancel the second ride-hailing order in user B's ride-hailing call and add the trip information of user B's second ride-hailing order to the trip information of user A's first ride-hailing order.

[0315] S1710: Return merged order.

[0316] The trip matching system returns the merged order to the ride-hailing platform.

[0317] S1711: Updated itinerary.

[0318] The ride-hailing platform updates the trip information to the transportation providers, specifically by informing them of the combined orders, including two pick-up points (i.e., the first pick-up point and the second pick-up point) and two drop-off points (i.e., the first destination and the second destination).

[0319] S1712: Obtain the optimal route.

[0320] For combined orders, transportation providers use map services to replan better travel routes.

[0321] S1713: Return to the optimal route.

[0322] Correspondingly, the map service provider returns the optimal route to the transportation provider so that the provider can inform the driver to pick up and drop off user A and user B using the optimal route.

[0323] S1714: The combined order's journey has ended.

[0324] After the trip was completed, the transportation provider informed the ride-hailing platform that the combined order had ended.

[0325] S1715: Intelligent billing and deduction.

[0326] The ride-hailing platform calls the payment system to intelligently split bills and deduct fees (e.g., automatic deduction).

[0327] S1716: Payment successful, and payment details for both parties.

[0328] S1717: Payment successful, and payment details for both parties.

[0329] The ride-hailing platform notified both user A and user B that the payment had been successfully deducted, along with the payment details for both parties.

[0330] Understandable Figure 17 This is merely an example and is not intended to impose any limitations. For example, the implementation order of S1701 and S1702, and the implementation order of S1716 and S1717, can all be determined according to the actual situation.

[0331] It should be noted that, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0332] based on Figure 3 Corresponding to the carpooling method provided in the embodiments, this application also provides a carpooling device 1800, which includes a display unit 1801 and an update unit 1802:

[0333] The display unit 1801 is used to respond to the acquisition of the first ride-hailing order initiated by the first account, display the first ride-hailing page, and display the first pick-up and drop-off information on the first ride-hailing page. The first pick-up and drop-off information is used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order.

[0334] The display unit 1801 is also used to display the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page, wherein the first ride-hailing order and the second ride-hailing order meet the conditions for carpooling.

[0335] The display unit 1801 is also used to display the first carpooling result in response to receiving the consent to merge operation performed by the first account through the first notification information;

[0336] The update unit 1802 is used to update the first ride-hailing order to a merged order obtained by merging the first ride-hailing order and the second ride-hailing order if the first ride-sharing result indicates that the ride-sharing was successful. The first vehicle is used to pick up and drop off the passenger corresponding to the merged order.

[0337] In one possible implementation, the display unit is further configured to:

[0338] In response to receiving the consent to merge operation performed by the first account through the first notification information, carpooling waiting information is displayed;

[0339] If it is determined that the second account corresponding to the second ride-hailing order agrees to merge the first ride-hailing order and the second ride-hailing order, the first ride-sharing result indicating successful ride-sharing is displayed, and the ride-sharing waiting information is canceled from being displayed;

[0340] If it is determined that the second account corresponding to the second ride-hailing order refuses to merge the first ride-hailing order with the second ride-hailing order, the first ride-sharing result indicating the ride-sharing failure is displayed, and the display of the ride-sharing waiting information is canceled.

[0341] In one possible implementation, the display unit is further configured to:

[0342] The first ride-hailing page displays the first notification information and the trip information corresponding to N second ride-hailing orders, where N > 1;

[0343] In response to the first selection operation of the first account for N second ride-hailing orders, it is determined that the first selection operation indicates the selection of M first pre-selected orders, 1≤M≤N;

[0344] Obtain the consent to merge operation implemented by the first account through the first notification information, agreeing to merge with M of the first pre-selected orders.

[0345] In one possible implementation, the update unit is further configured to:

[0346] If the first carpooling result indicates that the carpooling was successfully completed with K target orders from the M first pre-selected orders, the first ride-hailing order will be updated to a merged order obtained by combining the first ride-hailing order with the K target orders.

[0347] In one possible implementation, the display unit is further configured to:

[0348] In response to the first selection operation instruction to select M of the first pre-selected orders, carpooling fare information is displayed on the first ride-hailing page. The carpooling fare information is used to indicate the estimated cost when the first ride-hailing order is successfully carpooled with the M of the first pre-selected orders.

[0349] In one possible implementation, if the first ride-hailing order is a carpooling type, then the N second ride-hailing orders each correspond to the carpooling type. The display unit is further configured to:

[0350] In response to receiving the consent merge operation implemented through the first notification information, a first carpooling result is displayed to indicate that the carpooling with M of the first pre-selected orders has been successful;

[0351] The updating unit is further configured to update the first ride-hailing order to a merged order obtained by merging the first ride-hailing order with M first pre-selected orders.

[0352] In one possible implementation, if the first ride-hailing order is of a specific type, the display unit is further configured to:

[0353] In response to receiving the consent merge operation implemented through the first notification information, a quantity acquisition control is displayed on the first ride-hailing page;

[0354] In response to a determination operation on the quantity acquisition control, the first quantity of ride-hailing objects corresponding to the first ride-hailing order is acquired;

[0355] If it is determined that the second account corresponding to the second ride-hailing order agrees to merge the first ride-hailing order with the second ride-hailing order, and the sum of the first quantity and the second quantity is less than or equal to the number of passengers that the first vehicle can accommodate, a first ride-sharing result is displayed to indicate that the ride-sharing was successful, and the second quantity is the number of passengers corresponding to the second ride-hailing order.

[0356] In one possible implementation, if the first ride-hailing order is of a specific type, the display unit is further configured to:

[0357] Display a quantity acquisition control on the first ride-hailing page;

[0358] In response to a determination operation on the quantity acquisition control, the first quantity of ride-hailing objects corresponding to the first ride-hailing order is acquired;

[0359] Wherein, the sum of the first quantity and the second quantity is less than or equal to the number of passengers that the first vehicle can accommodate, and the second quantity is the number of passengers corresponding to the second ride-hailing order.

[0360] In one possible implementation, the display unit is further configured to:

[0361] In response to receiving the first account's refusal to merge operation via the first notification information, a settings control for the carpooling recommendation service is displayed on the first ride-hailing page;

[0362] In response to the setting operation performed through the setting control, the carpooling recommendation service is turned off for ride-hailing orders initiated by the first account within the set time period, wherein the set time period is determined based on the setting operation.

[0363] In one possible implementation, the display unit is further configured to:

[0364] If the first pick-up and drop-off information is used to identify that the first vehicle is heading to the first pick-up point corresponding to the first ride-hailing order, the first notification information and the trip information of the second ride-hailing order are displayed on the first ride-hailing page;

[0365] If the first pick-up and drop-off information is used to identify that the first vehicle is traveling from the first pick-up point to the first destination corresponding to the first ride-hailing order, the first notification information and the trip information of the second ride-hailing order will not be displayed.

[0366] In one possible implementation, the trip information of the second ride-hailing order includes at least one of the following: the second pick-up point corresponding to the second ride-hailing order, the second destination corresponding to the second ride-hailing order, the object information of the passenger corresponding to the second ride-hailing order, and the trip route from the second pick-up point to the second destination.

[0367] In one possible implementation, the relationship between the first pick-up point corresponding to the first ride-hailing order and the second pick-up point corresponding to the second ride-hailing order is a first relationship, and the relationship between the first destination corresponding to the first ride-hailing order and the second destination corresponding to the second ride-hailing order is a second relationship, wherein the first relationship includes at least one of the following:

[0368] The travel distance between the first pick-up point and the second pick-up point is less than a preset distance; or...

[0369] The second pick-up point falls on the route taken by the first vehicle to the first pick-up point; or,

[0370] The second pick-up point is located on the first travel route of the first vehicle from the first pick-up point to the first destination;

[0371] And, the second relationship includes at least one of the following:

[0372] The distance between the first endpoint and the second endpoint is less than the preset distance; or...

[0373] The second destination falls on the first travel route; or,

[0374] The overlap between the route from the first destination to the second destination and the first route is less than the overlap threshold;

[0375] Wherein, if the first relationship indicates that the second pick-up point falls on the first travel route and the second relationship indicates that the second destination falls on the first travel route, then the direction of travel of the first vehicle from the second pick-up point to the second destination is the same as the direction of travel from the first pick-up point to the first destination.

[0376] In one possible implementation, the display unit is further configured to:

[0377] The first ride-hailing page displays ride-hailing waiting information, which is used to identify the vehicle that is being identified for the first ride-hailing order;

[0378] During the process of displaying the taxi waiting information, the third notification information and the trip information of the third taxi order are displayed on the first taxi page, and the third taxi order and the first taxi order meet the carpooling conditions;

[0379] In response to receiving the consent to merge operation performed by the first account through the third notification information, the second carpooling result is displayed;

[0380] The updating unit is further configured to, if the second carpooling result indicates a successful carpool, update the first ride-hailing order to a merged order obtained by merging the first ride-hailing order and the third ride-hailing order, and display second pick-up and drop-off information on the first ride-hailing page, wherein the second pick-up and drop-off information is used to identify the second vehicle that picks up and drops off the passenger corresponding to the third ride-hailing order and the passenger corresponding to the first ride-hailing order.

[0381] In one possible implementation, the display unit is further configured to:

[0382] If, before obtaining the consent merge operation implemented through the third notification information, in response to determining that the first vehicle corresponds to the first ride-hailing order, a selection control for the first vehicle is displayed on the first ride-hailing page;

[0383] In response to a confirmation operation on the selection control, the first pick-up and drop-off information is displayed on the first ride-hailing page, and the display of the third notification information and the trip information of the third ride-hailing order is canceled.

[0384] In one possible implementation, the display unit is further configured to:

[0385] In response to receiving the consent to merge from the first account via the third notification information, and the second carpooling result indicating successful carpooling, the selection control is deselected.

[0386] In one possible implementation, the display unit is further configured to:

[0387] The first ride-hailing page displays the third notification information and the trip information corresponding to R third ride-hailing orders, where R > 1;

[0388] In response to the second selection operation of the first account for R of the third ride-hailing orders, it is determined that the second selection operation indicates the selection of a second pre-selected order, wherein the second pre-selected order is one of the R of the third ride-hailing orders;

[0389] Obtain the consent to merge operation from the first account via the third notification information, agreeing to merge with the second pre-selected order.

[0390] In one possible implementation, if the first ride-hailing order is of a specific type, the display unit is further configured to:

[0391] In response to receiving the consent merge operation implemented through the third notification information, a quantity acquisition control is displayed on the first ride-hailing page;

[0392] In response to a determination operation on the quantity acquisition control, the first quantity of ride-hailing objects corresponding to the first ride-hailing order is acquired;

[0393] If it is determined that the third account corresponding to the third ride-hailing order agrees to merge the first ride-hailing order with the third ride-hailing order, and the sum of the first quantity and the third quantity is less than or equal to the number of passengers that the second vehicle can accommodate, a second ride-sharing result is displayed to indicate that the ride-sharing was successful, where the third quantity is the number of passengers corresponding to the third ride-hailing order.

[0394] In one possible implementation, if the first ride-hailing order is of a specific type, the display unit is further configured to:

[0395] Display a quantity acquisition control on the first ride-hailing page;

[0396] In response to a determination operation on the quantity acquisition control, the first quantity of ride-hailing objects corresponding to the first ride-hailing order is acquired;

[0397] Wherein, the sum of the first quantity and the third quantity is less than or equal to the number of passengers that the second vehicle can accommodate, and the third quantity is the number of passengers corresponding to the third ride-hailing order.

[0398] In one possible implementation, the trip information of the third ride-hailing order includes at least one of the following: the third pick-up point corresponding to the third ride-hailing order, the third destination corresponding to the third ride-hailing order, the object information of the passenger corresponding to the third ride-hailing order, the trip route from the third pick-up point to the third destination, and the model of the second vehicle.

[0399] In one possible implementation, the second vehicle's model belongs to the pre-selected model corresponding to the first ride-hailing order.

[0400] In one possible implementation, the first account's historical ride-hailing orders include ride-sharing orders.

[0401] As can be seen from the above technical solution, for the first account that has already hailed a ride, the first ride-hailing page displays the first notification information and the trip information of the second ride-hailing order. The first notification information is used to determine whether the first account agrees to merge the second ride-hailing order with its own first ride-hailing order; that is, the first notification information is used to determine whether the first account wants to invite others to share a ride. Furthermore, the trip information of the second ride-hailing order indicates the specific details of the second ride-hailing order, thus showing what kind of ride-hailing order it is. It is evident that by proactively recommending a second ride-sharing option to the first account that has already hailed a ride, and simultaneously displaying the trip information of the second ride-hailing order, the user of the first account can first understand the details of the ride-sharing order to them before deciding whether to agree to share. Accordingly, in response to the first account's agreement to merge via the first notification information, the first ride-sharing result is displayed, and if the first ride-sharing result indicates a successful share, the first ride-hailing order is updated to a merged order. Based on this, users are given the option to choose which ride-sharing orders to share with, allowing them to decide whether or not to agree to share based on their own preferences. This helps to determine combined orders that satisfy users, improving ride-sharing satisfaction and the overall experience. Furthermore, because the second ride-sharing order is proactively recommended to the first account that has already booked a ride, in scenarios with insufficient capacity, once the first account agrees to share, there is a chance of a successful ride-sharing, allowing other users who are currently trying to book a ride but haven't yet found one to quickly get a ride, thus improving travel efficiency.

[0402] This application also provides a computer device, which can be a terminal, taking a smartphone as an example:

[0403] Figure 19 The diagram shown is a block diagram of a portion of the structure of a smartphone provided in an embodiment of this application. (Reference) Figure 19 The smartphone includes components such as a radio frequency (RF) circuit 1110, a memory 1120, an input unit 1130, a display unit 1140, a sensor 1150, an audio circuit 1160, a Wi-Fi module 1170, a processor 1180, and a power supply 1190. The input unit 1130 may include a touch panel 1131 and other input devices 1132, the display unit 1140 may include a display panel 1141, and the audio circuit 1160 may include a speaker 1161 and a microphone 1162. Those skilled in the art will understand that... Figure 19 The smartphone structure shown does not constitute a limitation on smartphones and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0404] The memory 1120 can be used to store software programs and modules. The processor 1180 executes various functions and data processing of the smartphone by running the software programs and modules stored in the memory 1120. The memory 1120 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the smartphone (such as audio data, phonebook, etc.). In addition, the memory 1120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0405] The processor 1180 is the control center of the smartphone, connecting various parts of the smartphone via various interfaces and lines. It performs various functions and processes data by running or executing software programs and / or modules stored in the memory 1120 and calling data stored in the memory 1120. Optionally, the processor 1180 may include one or more processing units; preferably, the processor 1180 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1180.

[0406] In this embodiment, the steps performed by the processor 1180 in the smartphone can be based on Figure 19 The structure shown is implemented.

[0407] The computer device provided in this application embodiment can also be a server. Please refer to [link / reference]. Figure 20 As shown, Figure 20 This is a structural diagram of the server 1200 provided in this application embodiment. The server 1200 can vary significantly due to different configurations or performance. It may include one or more processors, such as a central processing unit (CPU) 1222, and a memory 1232, and one or more storage media 1230 (e.g., one or more mass storage devices) for storing application programs 1242 or data 1244. The memory 1232 and storage media 1230 can be temporary or persistent storage. The program stored in the storage media 1230 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the CPU 1222 may be configured to communicate with the storage media 1230 and execute the series of instruction operations in the storage media 1230 on the server 1200.

[0408] Server 1200 may also include one or more power supplies 1226, one or more wired or wireless network interfaces 1250, one or more input / output interfaces 1258, and / or one or more operating systems 1241, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0409] In this embodiment, the central processing unit 1222 in server 1200 can perform the following steps:

[0410] In response to receiving the first ride-hailing order initiated by the first account, the first ride-hailing page is displayed, and the first pick-up and drop-off information is displayed on the first ride-hailing page. The first pick-up and drop-off information is used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order.

[0411] The first ride-hailing page displays the first notification information and the trip information of the second ride-hailing order, and the first ride-hailing order and the second ride-hailing order meet the conditions for carpooling;

[0412] In response to receiving the consent to merge operation performed by the first account through the first notification information, the first carpooling result is displayed;

[0413] If the first carpooling result indicates that the carpooling was successful, the first ride-hailing order will be updated to a merged order obtained by combining the first ride-hailing order and the second ride-hailing order, and the first vehicle will be used to pick up and drop off the passenger corresponding to the merged order.

[0414] According to one aspect of this application, a computer-readable storage medium is provided for storing a computer program that, when executed by a computer device, causes the computer device to perform the carpooling methods described in the foregoing embodiments.

[0415] According to one aspect of this application, a computer program product is provided, comprising a computer program stored in a computer-readable storage medium. A processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the methods provided in various optional implementations of the above embodiments.

[0416] The descriptions of the processes or structures corresponding to the above figures each have their own emphasis. For parts of a process or structure that are not described in detail, please refer to the relevant descriptions of other processes or structures.

[0417] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application 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 of this application described herein can be implemented, for example, 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, system, product, or apparatus 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 apparatus.

[0418] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0419] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0420] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0421] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0422] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0423] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A carpooling method, characterized in that, The method includes: In response to receiving the first ride-hailing order initiated by the first account, the first ride-hailing page is displayed, and the first pick-up and drop-off information is displayed on the first ride-hailing page. The first pick-up and drop-off information is used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order. The first ride-hailing page displays the first notification information and the trip information of the second ride-hailing order, and the first ride-hailing order and the second ride-hailing order meet the conditions for carpooling; In response to receiving the consent to merge operation performed by the first account through the first notification information, the first carpooling result is displayed; If the first carpooling result indicates that the carpooling was successful, the first ride-hailing order will be updated to a merged order obtained by combining the first ride-hailing order and the second ride-hailing order, and the first vehicle will be used to pick up and drop off the passenger corresponding to the merged order.

2. The method according to claim 1, characterized in that, The response to receiving the consent to merge from the first account via the first notification information, and displaying the first carpooling result, includes: In response to receiving the consent to merge operation performed by the first account through the first notification information, carpooling waiting information is displayed; If it is determined that the second account corresponding to the second ride-hailing order agrees to merge the first ride-hailing order and the second ride-hailing order, the first ride-sharing result indicating successful ride-sharing is displayed, and the ride-sharing waiting information is canceled from being displayed; If it is determined that the second account corresponding to the second ride-hailing order refuses to merge the first ride-hailing order with the second ride-hailing order, the first ride-sharing result indicating the ride-sharing failure is displayed, and the display of the ride-sharing waiting information is canceled.

3. The method according to claim 1, characterized in that, The step of displaying the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page includes: The first ride-hailing page displays the first notification information and the trip information corresponding to N second ride-hailing orders, where N > 1; The method further includes: In response to the first selection operation of the first account for N second ride-hailing orders, it is determined that the first selection operation indicates the selection of M first pre-selected orders, 1≤M≤N; Obtain the consent to merge operation implemented by the first account through the first notification information, agreeing to merge with M of the first pre-selected orders.

4. The method according to claim 3, characterized in that, If the first carpooling result indicates a successful carpool, the first ride-hailing order will be updated to a merged order obtained by combining the first ride-hailing order and the second ride-hailing order, including: If the first carpooling result indicates that the carpooling was successfully completed with K target orders from the M first pre-selected orders, the first ride-hailing order will be updated to a merged order obtained by combining the first ride-hailing order with the K target orders.

5. The method according to claim 3, characterized in that, Before obtaining the consent merge operation implemented through the first notification information, the method further includes: In response to the first selection operation instruction to select M of the first pre-selected orders, carpooling fare information is displayed on the first ride-hailing page. The carpooling fare information is used to indicate the estimated cost when the first ride-hailing order is successfully carpooled with the M of the first pre-selected orders.

6. The method according to claim 3, characterized in that, If the first ride-hailing order is a carpooling type, then the N second ride-hailing orders each correspond to the carpooling type. The step of responding to receiving the consent to merge from the first account via the first notification information and displaying the first carpooling result includes: In response to receiving the consent merge operation implemented through the first notification information, a first carpooling result is displayed to indicate that the carpooling with M of the first pre-selected orders has been successful; The step of updating the first ride-hailing order to a merged order obtained by combining the first ride-hailing order and the second ride-hailing order includes: The first ride-hailing order is updated to a merged order obtained by combining the first ride-hailing order with M of the first pre-selected orders.

7. The method according to claim 1, characterized in that, If the first ride-hailing order is of the exclusive type, the response to receiving the consent to merge from the first account via the first notification information, and displaying the first carpooling result, includes: In response to receiving the consent merge operation implemented through the first notification information, a quantity acquisition control is displayed on the first ride-hailing page; In response to a determination operation on the quantity acquisition control, the first quantity of ride-hailing objects corresponding to the first ride-hailing order is acquired; If it is determined that the second account corresponding to the second ride-hailing order agrees to merge the first ride-hailing order with the second ride-hailing order, and the sum of the first quantity and the second quantity is less than or equal to the number of passengers that the first vehicle can accommodate, a first ride-sharing result is displayed to indicate that the ride-sharing was successful, and the second quantity is the number of passengers corresponding to the second ride-hailing order.

8. The method according to claim 1, characterized in that, If the first ride-hailing order is of the exclusive type, before displaying the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page, the method further includes: Display a quantity acquisition control on the first ride-hailing page; In response to a determination operation on the quantity acquisition control, the first quantity of ride-hailing objects corresponding to the first ride-hailing order is acquired; Wherein, the sum of the first quantity and the second quantity is less than or equal to the number of passengers that the first vehicle can accommodate, and the second quantity is the number of passengers corresponding to the second ride-hailing order.

9. The method according to claim 1, characterized in that, The method further includes: In response to receiving the first account's refusal to merge operation via the first notification information, a settings control for the carpooling recommendation service is displayed on the first ride-hailing page; In response to the setting operation performed through the setting control, the carpooling recommendation service is turned off for ride-hailing orders initiated by the first account within the set time period, wherein the set time period is determined based on the setting operation.

10. The method according to claim 1, characterized in that, The step of displaying the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page includes: If the first pick-up and drop-off information is used to identify that the first vehicle is heading to the first pick-up point corresponding to the first ride-hailing order, the first notification information and the trip information of the second ride-hailing order are displayed on the first ride-hailing page; The method further includes: If the first pick-up and drop-off information is used to identify that the first vehicle is traveling from the first pick-up point to the first destination corresponding to the first ride-hailing order, the first notification information and the trip information of the second ride-hailing order will not be displayed.

11. The method according to any one of claims 1-10, characterized in that, The trip information of the second ride-hailing order includes at least one of the following: the second pick-up point corresponding to the second ride-hailing order, the second destination corresponding to the second ride-hailing order, the passenger information corresponding to the second ride-hailing order, and the trip route from the second pick-up point to the second destination.

12. The method according to any one of claims 1-10, characterized in that, The relationship between the first pick-up point corresponding to the first ride-hailing order and the second pick-up point corresponding to the second ride-hailing order is a first relationship, and the relationship between the first destination corresponding to the first ride-hailing order and the second destination corresponding to the second ride-hailing order is a second relationship. The first relationship includes at least one of the following: The travel distance between the first pick-up point and the second pick-up point is less than a preset distance; or... The second pick-up point falls on the route taken by the first vehicle to the first pick-up point; or, The second pick-up point is located on the first travel route of the first vehicle from the first pick-up point to the first destination; And, the second relationship includes at least one of the following: The distance between the first endpoint and the second endpoint is less than the preset distance; or... The second destination falls on the first travel route; or, The overlap between the route from the first destination to the second destination and the first route is less than the overlap threshold; Wherein, if the first relationship indicates that the second pick-up point falls on the first travel route and the second relationship indicates that the second destination falls on the first travel route, then the direction of travel of the first vehicle from the second pick-up point to the second destination is the same as the direction of travel from the first pick-up point to the first destination.

13. The method according to claim 1, characterized in that, The method further includes: The first ride-hailing page displays ride-hailing waiting information, which is used to identify the vehicle that is being identified for the first ride-hailing order; During the process of displaying the taxi waiting information, the third notification information and the trip information of the third taxi order are displayed on the first taxi page, and the third taxi order and the first taxi order meet the carpooling conditions; In response to receiving the consent to merge operation performed by the first account through the third notification information, the second carpooling result is displayed; If the second carpooling result indicates a successful carpool, the first ride-hailing order is updated to a merged order obtained by combining the first ride-hailing order and the third ride-hailing order, and the second pick-up and drop-off information is displayed on the first ride-hailing page. The second pick-up and drop-off information is used to identify the second vehicle that picks up and drops off the passenger corresponding to the third ride-hailing order and the passenger corresponding to the first ride-hailing order.

14. The method according to claim 13, characterized in that, The step of displaying the first pick-up and drop-off information on the first ride-hailing page includes: If, before obtaining the consent merge operation implemented through the third notification information, in response to determining that the first vehicle corresponds to the first ride-hailing order, a selection control for the first vehicle is displayed on the first ride-hailing page; In response to a confirmation operation on the selection control, the first pick-up and drop-off information is displayed on the first ride-hailing page, and the display of the third notification information and the trip information of the third ride-hailing order is canceled.

15. The method according to claim 14, characterized in that, The method further includes: In response to receiving the consent to merge from the first account via the third notification information, and the second carpooling result indicating successful carpooling, the selection control is deselected.

16. The method according to claim 13, characterized in that, The step of displaying the third notification information and the trip information of the third ride-hailing order on the first ride-hailing page includes: The first ride-hailing page displays the third notification information and the trip information corresponding to R third ride-hailing orders, where R > 1; The method further includes: In response to the second selection operation of the first account for R of the third ride-hailing orders, it is determined that the second selection operation indicates the selection of a second pre-selected order, wherein the second pre-selected order is one of the R of the third ride-hailing orders; Obtain the consent to merge operation from the first account via the third notification information, agreeing to merge with the second pre-selected order.

17. A carpooling device, characterized in that, The device includes a display unit and an update unit: The display unit is used to respond to the receipt of the first ride-hailing order initiated by the first account, display the first ride-hailing page, and display the first pick-up and drop-off information on the first ride-hailing page. The first pick-up and drop-off information is used to identify the first vehicle that picks up and drops off the passenger corresponding to the first ride-hailing order. The display unit is also used to display the first notification information and the trip information of the second ride-hailing order on the first ride-hailing page, wherein the first ride-hailing order and the second ride-hailing order meet the conditions for carpooling; The display unit is also used to display the first carpooling result in response to receiving the consent to merge operation performed by the first account through the first notification information; The update unit is used to update the first ride-hailing order to a merged order obtained by merging the first ride-hailing order and the second ride-hailing order if the first ride-sharing result indicates that the ride-sharing was successful. The first vehicle is used to pick up and drop off the passenger corresponding to the merged order.

18. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the method according to any one of claims 1-16 according to instructions in the computer program.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed by a computer device, causes the computer device to perform the method according to any one of claims 1-16.

20. A computer program product, comprising a computer program, characterized in that, When it is run on a computer device, it causes the computer device to perform the method according to any one of claims 1-16.

Images