Method for displaying and generating multi-pass travel ticket buying scheme, and computer program product

Abstract

The embodiment of the invention provides a method for displaying and generating a multi-pass travel ticket buying scheme and a computer program product, and the method comprises the steps: initiating a search request of the multi-pass travel ticket buying scheme to a server of a travel service platform when the method is applied to a client of the travel service platform, the search request at least comprises a departure place and at least two travel destinations; at least two groups of multi-pass travel ticket buying schemes returned by the server are received, each group of multi-pass travel ticket buying schemes corresponds to a travel route formed by the departure place and the at least two travel destinations, and the arrangement sequences of the at least two travel destinations in different travel routes are different; and displaying at least one part of the received multi-trip ticket buying scheme.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of Internet technology, and more particularly to a method for displaying and generating a multi-trip ticket purchasing plan and a computer program product. Background Art

[0002] Users often need to travel for business or personal reasons. To this end, users need to purchase transportation tickets between different locations to meet their transportation needs between different locations. The travel service platform can provide users with ticket purchase services so that users can query and purchase the above-mentioned transportation tickets.

[0003] In the related art, the travel service platform only supports the query and purchase of one-way travel ticket purchase plans. A one-way travel ticket purchase plan contains information about transportation tickets from one place to another, such as from the departure place to the travel destination. However, in addition to one-way travel, users may sometimes need to make multi-trip trips, that is, there are two or more travel destinations at the same time, so that there are multiple travel routes between the departure place and each travel destination, and the user can only query the corresponding multi-trip travel ticket purchase plan for each travel route separately, and finally determine the multi-trip travel ticket purchase plan that he hopes to adopt after comparison. It can be seen that multiple queries make the user's operation complicated and time-consuming, and the user's manual operation may cause the omission of the multi-trip travel ticket purchase plan corresponding to some travel routes, which is not conducive to the user determining the most suitable multi-trip travel ticket purchase plan for him. Summary of the invention

[0004] In view of this, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a method for displaying a multi-trip ticket purchase plan is proposed, which is applied to a client of a travel service platform, including:

[0006] Initiate a search request for a multi-trip ticket purchase plan to the service end of the travel service platform, wherein the search request includes at least a departure place and at least two travel destinations;

[0007] receiving at least two sets of multi-trip ticket purchase plans returned by the server, each set of multi-trip ticket purchase plans corresponding to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different;

[0008] At least a portion of the received multi-trip ticket purchasing plan is displayed.

[0009] According to a second aspect of one or more embodiments of this specification, a method for generating a multi-trip ticket purchase plan is proposed, which is applied to a service end of a travel service platform, including:

[0010] Receiving a search request for a multi-trip ticket purchase plan initiated by a client of the travel service platform, the search request including at least a departure place and at least two travel destinations;

[0011] generating at least two groups of multi-trip ticket purchase plans, each group of multi-trip ticket purchase plans corresponding to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different;

[0012] The generated multi-trip ticket purchasing plan is returned to the client so that the client can display at least a part of it.

[0013] According to a third aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which implements the steps of the method described in the first aspect or the second aspect when executed by a processor.

[0014] It can be seen from the above embodiments that this specification is aimed at the scenario of multi-trip travel. The service end of the travel service platform can provide corresponding multi-trip travel ticket purchase plans for various travel routes between the departure place and each travel destination, so that the user only needs to perform a query operation once to inform the above-mentioned departure place and each travel destination, and then the user can view each group of multi-trip travel ticket purchase plans through the client of the travel service platform, so as to facilitate the user to compare and purchase, which greatly simplifies the user operation, reduces the time spent on query and ticket purchase, and also helps the user to determine the multi-trip travel ticket purchase plan that best suits him or her. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic diagram of a system architecture on which a travel service platform relies provided by an exemplary embodiment.

[0016] Figure 2 It is a flowchart of a method for displaying a multi-trip ticket purchasing plan provided by an exemplary embodiment.

[0017] Figure 3 It is a schematic diagram of a ticket purchase plan search page in an air ticket scenario provided by an exemplary embodiment.

[0018] Figure 4 It is a schematic diagram of a transition page provided by an exemplary embodiment.

[0019] Figure 5-6 It is a schematic diagram of a search result page based on a tab page provided by an exemplary embodiment.

[0020] Figure 7 It is a flowchart of a method for generating a multi-trip ticket purchasing plan provided by an exemplary embodiment.

[0021] Figure 8 It is a structural schematic diagram of a device provided by an exemplary embodiment.

[0022] Fig. 9 It is a block diagram of a display device for a multi-trip ticket purchasing solution provided by an exemplary embodiment.

[0023] Fig.10 It is a block diagram of a device for generating a multi-trip ticket purchasing plan provided by an exemplary embodiment. DETAILED DESCRIPTION

[0024] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0025] Figure 1 FIG. 1 is a schematic diagram of a system architecture on which a travel service platform is based provided by an exemplary embodiment. Figure 1 As shown, the system architecture may include a server 11, a network 12, and several electronic devices, such as a PC (Personal Computer) 13, a mobile phone 14, and the like.

[0026] The server 11 may be a physical server including an independent host, or the server 11 may be a virtual server carried by a host cluster. During operation, the server 11 may run a program on the server side of the travel service platform to realize the service end of the travel service platform.

[0027] PC13 and mobile phone 14 are only some types of electronic devices that users can use. In fact, users can obviously also use electronic devices such as the following types: tablet devices, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smart watches, etc.), etc., and one or more embodiments of this specification do not limit this. During operation, the electronic device can run the program on the client side of the travel service platform to implement the client of the travel service platform. Among them, the application program of the client of the above-mentioned travel service platform can be started and run on the electronic device. The program on the client side can be a native application installed on the electronic device, or the program on the client side can be a small program, a quick application or other similar forms. Of course, when using web page technologies such as HTML5 or similar, the relevant functions can be realized by the page displayed by the browser, and the browser here can be an independent browser application or a browser module embedded in some applications.

[0028] As for the network 12 for interaction between electronic devices such as PC 13 and mobile phone 14 and server 11, it is possible to select a wired or wireless network to achieve communication based on the communication mode supported by the corresponding electronic device, and this specification does not limit this. For example, PC 13 can support both wired and wireless communication, so it can use a wired or wireless network to achieve communication as needed, while mobile phone 14 usually only supports wireless communication, so it can use a wireless network to achieve communication.

[0029] In the related art, the travel service platform supports users to search for one-way travel ticket purchase plans. Specifically, the client of the travel service platform can provide users with a ticket purchase plan search page, and users can fill in the ticket purchase plan search page according to their own departure place and travel destination; accordingly, the server of the travel service platform will perform the search operation and return the queried one-way travel ticket purchase plan to the client, and display it in the search result page on the client for users to view and purchase.

[0030] However, if the user has two or more travel destinations, the search process will become cumbersome. For example, the user's departure point is A, and the travel destinations include B and C, then the user needs to determine all possible travel routes by himself: the first travel route is "A→B→C", and the second travel route is "A→C→B"; accordingly, the user needs to split each itinerary segment for each route, and search for the one-way travel ticket purchase plan corresponding to each itinerary segment, and then manually combine the multi-trip travel ticket purchase plan corresponding to each travel route, and finally make a purchase after comparison. Specifically, for the first travel route, the user needs to search for the one-way travel ticket purchase plan of "departure point A and destination B" and the one-way travel ticket purchase plan of "departure point B and destination C", and then combine them to obtain the multi-trip travel ticket purchase plan. Similarly, for the second type of travel route, the user needs to search for a one-way travel ticket purchase plan with "departure point A and destination point C" and a one-way travel ticket purchase plan with "departure point C and destination point B" respectively, and then combine them to obtain a multi-trip travel ticket purchase plan. If the number of travel destinations is greater, there will be more combinations of travel routes, and the splitting and searching process for each travel route will also be more complicated. The operations required for the user to determine each multi-trip travel ticket purchase plan will become very cumbersome, time-consuming and laborious, and it is also easy to cause, for example, the omission of some travel routes and their corresponding multi-trip travel ticket purchase plans, making it impossible for the user to determine the most suitable multi-trip travel ticket purchase plan for him.

[0031] Therefore, the technical solution of this specification proposes a technical solution suitable for multi-trip travel scenarios, which can facilitate users' operations in the process of searching for multi-trip ticket purchase plans, improve search efficiency, and assist users in determining the multi-trip ticket purchase plan that best suits them.

[0032] The following will be combined Figure 2 , the technical solution of this specification is described in detail.

[0033] Figure 2 This is a flowchart of a method for displaying a multi-trip ticket purchase plan provided by an exemplary embodiment, and the method is applied to a client of a travel service platform. Figure 2 As shown, the method may include the following steps:

[0034] Step 202, initiating a search request for a multi-trip ticket purchase plan to the service end of the travel service platform, the search request at least including a departure place and at least two travel destinations.

[0035] The client of the travel service platform can display a ticket purchase plan search page, which includes setting controls for various search conditions. The user can define the corresponding search conditions based on the setting controls. The client can initiate the above search request based on the user-defined search conditions. The search request includes the user-defined search conditions so that the server of the travel service platform can perform the search operation accordingly. For example, the search conditions at least include the departure place defined by the user and at least two travel destinations.

[0036] The setting control for the search condition can be in any form. For example, the setting control can be an input box, in which the user can enter the corresponding search condition. For another example, the setting control can be a selection box, in which the user can view predefined options and select one or more options as search conditions. In some cases, the setting control initially includes and displays the search conditions defined by default or based on preset rules, and if the user approves these search conditions, there is no need to define them additionally, thereby simplifying the user operation; of course, if the user does not approve, the user can redefine them.

[0037] For example, Figure 3 FIG. 1 is a schematic diagram of a ticket purchase solution search page in an air ticket scenario provided by an exemplary embodiment. Figure 3 As shown, under the "Multi-city Tour" tab, a search request for initiating a multi-trip ticket purchase plan can be supported. At the same time, the ticket purchase plan search page is also compatible with the search operation of the one-way travel ticket purchase plan. For example, the user can switch to the "One-way" tab or the "Round Trip" tab to initiate a one-way travel ticket purchase plan, at which time there is only a single departure point and a single travel destination. Of course, in other embodiments, the client of the travel service platform can display the ticket purchase plan search pages corresponding to the one-way travel ticket purchase plan and the multi-trip travel ticket purchase plan respectively, and this specification does not limit this.

[0038] Take "Departure Place" as an example. Figure 3 The specific city defined in the text is "Hangzhou". This can be directly input by the user through input method or voice, or it can be selected by the user from the alternative cities provided by the client (not shown in the figure). Alternatively, through the electronic device (such as a mobile phone, etc.) where the client of the travel service platform is located, when the positioning function is turned on, the city where the user is located can be automatically located as "Hangzhou", thereby directly pre-defining the "departure place" as "Hangzhou" without the need for manual input or selection by the user. Of course, the user can redefine it to other cities at any time.

[0039] Take “travel destination” as an example. Figure 3The cities specifically defined in the data are "Chiang Mai + Singapore", namely the two cities of "Chiang Mai" and "Singapore". Similar to the above-mentioned "place of departure", users can define the "travel destination" here by manual input or selection, which will not be repeated here. In addition, the "Chiang Mai + Singapore" here can also be predefined. For example, the travel service platform can calculate the travel popularity of each city based on air ticket sales data, air ticket query data, city search data, hotel reservation data, etc., or it can determine the popular cities recognized by the travel service platform based on the discount range of air tickets in various places, or other dimensions, thereby predefining them as the above-mentioned "travel destinations", which can be used as recommendations or reference information provided to users.

[0040] The cities involved in the multi-trip ticket purchase plan may only include the above-mentioned departure place and at least two travel destinations. In this case, each multi-trip ticket purchase plan actually includes: a one-way ticket purchase plan from the departure place to the first travel destination in the corresponding travel route, and a one-way ticket purchase plan between each travel destination in the corresponding travel route. Figure 3 For example, when the departure point is Hangzhou and the travel destinations are Chiang Mai and Singapore respectively, a travel route is: Hangzhou→Chiang Mai→Singapore; accordingly, in a multi-trip travel ticket purchase plan determined based on this: corresponding to the above-mentioned "one-way ticket purchase plan from the departure point to the first travel destination in the corresponding travel route", it specifically points out the one-way ticket purchase plan with the departure point being Hangzhou and the destination being Chiang Mai, corresponding to the above-mentioned "one-way ticket purchase plan between each travel destination in the corresponding travel route", it specifically points out the one-way ticket purchase plan with the departure point being Chiang Mai and the destination being Singapore.

[0041] Furthermore, the above search conditions may also include a return destination defined by the user; accordingly, the above search request may also include the return destination. Regarding how the user defines the return destination, you can refer to the above descriptions of the departure place and the travel destination, which will not be repeated here. In this case, each multi-trip travel ticket purchase plan includes, in addition to the aforementioned "one-way ticket purchase plan from the departure place to the first travel destination in the corresponding travel route" and "one-way ticket purchase plan between each travel destination in the corresponding travel route", it also includes: a one-way ticket purchase plan from the last travel destination in the corresponding travel route to the return destination. For example, still using Figure 3For example, when the departure point is Hangzhou, the travel destinations are Chiang Mai and Singapore respectively, and the return point is Hangzhou, a travel route is: Hangzhou→Chiang Mai→Singapore→Hangzhou; accordingly, in a multi-trip travel ticket purchase plan determined based on this: corresponding to the above-mentioned "one-way ticket purchase plan from the departure point to the first travel destination in the corresponding travel route", it specifically points out the one-way ticket purchase plan with the departure point being Hangzhou and the destination being Chiang Mai, corresponding to the above-mentioned "one-way ticket purchase plan between each travel destination in the corresponding travel route", it specifically points out the one-way ticket purchase plan with the departure point being Chiang Mai and the destination being Singapore, corresponding to the above-mentioned "one-way ticket purchase plan from the last travel destination in the corresponding travel route to the return point", it specifically points out the one-way ticket purchase plan with the departure point being Singapore and the destination being Hangzhou. It is understandable that if only the departure place and the destination are included, but not the return place, the multi-trip ticket purchase plan obtained is equivalent to the transportation ticket only involving the "outbound" during the user's travel process, but not the transportation ticket for the "return"; and if the return place is further included, the multi-trip ticket purchase plan obtained is equivalent to the transportation ticket for the "round trip" during the user's travel process: it includes both the transportation ticket for the "outbound" and the transportation ticket for the "return". On the client of the travel service platform, the user can choose whether to define the return place according to actual needs, and this specification does not limit this.

[0042] It should be noted that each one-way travel ticket purchase plan included in the multi-trip travel ticket purchase plan is actually a ticket purchase plan from one location to another location. The ticket purchase plan can be a direct ticket purchase plan from one location to another location, or a transfer ticket purchase plan from one location to another location after transferring at least one transfer location. This specification does not limit this. Figure 3 As shown, a one-way travel ticket purchase plan from Hangzhou to Chiang Mai is taken as an example: the ticket purchase plan can correspond to a direct flight from Hangzhou to Chiang Mai, or a connecting flight from Hangzhou to Kunming and then to Chiang Mai.

[0043] The service end of the travel service platform can maintain the price information of the transportation schedules and corresponding transportation tickets obtained from various transportation service providers. The price of transportation tickets often fluctuates dynamically with the change of dates. Therefore, the ticket price of the multi-trip travel ticket purchase plan finally presented must be related to the departure date corresponding to each single-trip travel ticket purchase plan contained therein. For each itinerary segment in the multi-trip travel scenario, the server needs to search from at least a part of the transportation schedules and corresponding transportation ticket price information maintained by it based on the departure place, destination and departure date under the itinerary segment to obtain the single-trip travel ticket purchase plan corresponding to the itinerary segment.

[0044] As mentioned above, the search request contains at least a departure point and at least two travel destinations. Based on each travel route determined in this way, each itinerary segment can be split and the departure point and destination under each itinerary segment can be determined. Similarly, when the search request further contains a return point, it is equivalent to adding a further itinerary segment to each travel route, that is, the itinerary segment from the last travel destination in the corresponding travel route to the return point. Then, for each itinerary segment, it is obvious that the corresponding departure point and destination can be determined.

[0045] The service end may determine the departure date corresponding to each itinerary segment in a variety of ways.

[0046] In one embodiment, the search condition may further include departure date description information and play time description information; accordingly, the search request may further include: departure date description information and play time description information. The departure date description information is used to describe: the precise date of departure from the departure place (the departure place included in the search request) or the future time period of the departure date; and the play time description information is used to describe: the total play time at at least two travel destinations (the travel destinations included in the search request) or the individual play time at each travel destination.

[0047] The departure date description information describes the initial departure date of the entire multi-trip trip. In each segment of each travel route, the initial departure date is the departure date of the first segment. The above-mentioned precise date means that the user can directly define the initial departure date as a specific date, such as "October 27, 2024". The above-mentioned future time period means that the user can define the time range of the initial departure date, such as "next month", "next six months", "next year", etc. Taking "next month" as an example, assuming that the day the search request is issued is "August 27, 2024", it means that the time range of the initial departure date is: August 27, 2024 to September 27, 2024, and the server will search accordingly.

[0048] If the play duration description information describes the separate play duration at each travel destination, then combined with the above-mentioned initial departure date, the departure date corresponding to each itinerary segment of each travel route can be clearly determined. For example, assuming that the initial departure date is September 1, 2024, the travel route is "Hangzhou→Chiang Mai→Singapore→Hangzhou", and the separate play duration in Chiang Mai is set to 3 days and the separate play duration in Singapore is set to 4 days, then it can be determined that: in the first itinerary segment "Hangzhou→Chiang Mai", the departure place is Hangzhou, the destination is Chiang Mai, and the departure date is September 1, 2024; in the second itinerary segment "Chiang Mai→Singapore", the departure place is Chiang Mai, the destination is Singapore, and the departure date is September 4, 2024; in the third itinerary segment "Singapore→Hangzhou", the departure place is Singapore, the destination is Hangzhou, and the departure date is September 8, 2024. Of course, for itineraries where the departure place is the travel destination, such as the second and third itineraries mentioned above, there may be many ways to calculate the departure date.

[0049] For example, for a segment with the departure point being the travel destination, the departure date can be: the date of arrival at the travel destination + the duration of the solo play at the travel destination. For example, in the second segment "Chiang Mai → Singapore" mentioned above, since Chiang Mai can be reached on the same day after departing from Hangzhou on September 1, 2024, the departure date from Chiang Mai is calculated to be September 4, 2024 after adding the solo play duration of 3 days. For another example, the day of arrival at a travel destination can be included in the solo play duration of the travel destination. Then, for a segment with the departure point being the travel destination, the departure date can be: the date of arrival at the travel destination + the duration of the solo play at the travel destination - 1. For example, in the second itinerary "Chiang Mai → Singapore" mentioned above, the trip departs from Hangzhou on September 1, 2024 and arrives in Chiang Mai on the same day. Therefore, the three days of the independent play time include the day "September 1, 2024". Therefore, after adding the three days of independent play time, the departure date from Chiang Mai is calculated to be September 3, 2024. Of course, whether the day of arrival at the travel destination is included in the independent play time can be specifically distinguished based on the arrival time: if it arrives earlier, such as before 10 am on the same day, then the day can be included in the independent play time. If it arrives later, such as after 6 pm on the same day, then the day can not be included in the independent play time. The above calculation methods are all used for illustration, and this manual does not limit the specific calculation method used.

[0050] If the play duration description information describes the total play duration in at least two of the above travel destinations, the travel service platform server can proactively divide it into the individual play duration corresponding to each travel destination. For example, the division scheme can be equal or nearly equal: for example, if the total play duration is 8 days and there are two travel destinations, the individual play duration corresponding to each travel destination can be set to 4 days; for another example, if the total play duration is 7 days and there are two travel destinations, the individual play duration corresponding to each travel destination can be set to 3 days and 4 days respectively. For another example, when the unit duration is 1 day, a division scheme can be generated in all possible ways: for example, if the total duration of the tour is 7 days and there are two travel destinations, multiple division schemes can be obtained, such as division scheme ① for 1 day for the first travel destination and 6 days for the second travel destination, division scheme ② for 2 days for the first travel destination and 5 days for the second travel destination, division scheme ③ for 3 days for the first travel destination and 4 days for the second travel destination, division scheme ④ for 4 days for the first travel destination and 3 days for the second travel destination, division scheme ⑤ for 5 days for the first travel destination and 2 days for the second travel destination, and division scheme ⑥ for 6 days for the first travel destination and 1 day for the second travel destination. The above division method is only used as an example, and the specific division scheme adopted is not limited by this specification. In short, after determining the individual play duration corresponding to each travel destination based on the total duration of the tour, you can refer to the above embodiment: by further combining the above-mentioned initial departure date, you can clarify the departure date corresponding to each itinerary segment of each travel route, which will not be repeated here.

[0051] In addition, the individual play duration or total play duration described in the play duration description information can be not only the precise duration in the above embodiment (such as the individual play duration is 3 days, the total play duration is 7 days, etc.), but also a specified duration range. Then, the server can take each possible duration value within the duration range as the corresponding individual play duration or total play duration, so as to determine the departure dates corresponding to each possible duration value in combination with the above embodiment. For example, if the individual play duration at a certain travel destination is specified to be 2-4 days, then the server can set the individual play duration to 2 days, 3 days and 4 days respectively, so as to determine each departure date. For another example, if the total play duration at a certain travel destination is specified to be 6-10 days, then the server can set the total play duration to 6 days, 7 days, 8 days, 9 days and 10 days respectively, so as to determine each departure date.

[0052] In some embodiments, the above search request may not include the departure date description information and the tour duration description information, or other information for the server to determine the departure date corresponding to each itinerary segment. Then, the server can autonomously set the departure date corresponding to each itinerary segment based on preset rules, such as setting the initial departure date as "one month in the future" and the total tour duration as "3-15 days" by default, so as to search for matching multi-trip ticket purchase solutions in the manner of the above embodiments.

[0053] As mentioned above, the service end of the travel service platform can maintain the price information of the transportation schedules and corresponding transportation tickets obtained from various transportation service providers, and query from this information based on the search request to obtain a multi-trip travel ticket purchase plan. In the airplane travel scenario, the transportation service provider is the airline company (referred to as the airline company) and the transportation schedule is the flight. In the train travel scenario, the transportation service provider is the railway transportation company and the transportation schedule is the train schedule. In the ship travel scenario, the transportation service provider is the shipping company and the transportation schedule is the shipping schedule. In the car travel scenario, the transportation service provider is the bus passenger transport company and the transportation schedule is the bus passenger schedule. For other types of transportation travel scenarios, they are not listed here one by one. Among them, the one-way travel ticket purchasing plans contained in the multi-trip travel ticket purchasing plan may involve the same type of transportation scenario, for example, all are airplane travel scenarios, then the corresponding one-way travel ticket purchasing plan is a ticket purchasing plan for air tickets; or, it may involve multiple types of transportation scenarios, for example, one part is an airplane travel scenario and the other part is a train travel scenario, etc., then the multi-trip ticket purchasing plan is a mixed ticket purchasing plan for air tickets and train tickets.

[0054] Although in the above embodiment, it is mentioned that the client of the travel service platform can show the user Figure 3 The ticket purchase scheme search page shown allows the user to define search conditions in the page and then initiate a search request to the server. However, in other embodiments, the client of the travel service platform does not necessarily need to display the ticket purchase scheme search page or similar pages, and can also initiate a search request to the server. For example, the client can provide a voice input function, so that the user only needs to input the search conditions in the form of voice, and the client can send the user input voice or the converted text information to the server, and initiate a search request to the server. Of course, the client of the travel service platform can also provide other types of input functions, can obtain user-defined search conditions, and initiate a search request to the server, and this specification does not limit this.

[0055] Step 204, receiving at least two sets of multi-trip ticket purchase plans returned by the server, each set of multi-trip ticket purchase plans corresponds to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different.

[0056] As mentioned above, for the departure point and at least two travel destinations defined by the user, since the arrangement order between the travel destinations (i.e., the order of traveling between these travel destinations) may change, at least two travel routes can be formed. Generally speaking, if there are n travel destinations (n≥2 and n is an integer), then the types of travel routes formed are n! (i.e., the factorial of n). Among them, whether the user defines a return point has no effect on the number of travel routes formed.

[0057] The difference between different types of travel routes is mainly caused by the different arrangement order between at least two travel destinations. When the number of travel destinations reaches three or more, the arrangement order between all travel destinations may be different for different types of travel routes, or only the arrangement order between some travel destinations may be different, which will eventually lead to the formation of different types of travel routes. For example, assuming that the departure place is A and the travel destinations are B, C and D, it can be formed as follows: travel route 1) is A→B→C→D, travel route 2) is A→B→D→C, travel route 3) is A→C→B→D, travel route 4) is A→C→D→B, travel route 5) is A→D→C→B, and travel route 6) is A→D→B→C. Among them, for example, compared with travel route 1) and travel route 4), the arrangement order of each travel destination is different. For another example, compared with travel route 2), travel destination B is the second stop in the corresponding travel route, but the order of travel destinations C and D is also different. These can lead to the formation of different types of travel routes.

[0058] The at least two sets of multi-trip ticket purchase solutions returned by the server may correspond to all types of travel routes formed based on the departure place and at least two travel destinations contained in the search request. Alternatively, the at least two sets of multi-trip ticket purchase solutions returned by the server may correspond to some types of travel routes formed based on the departure place and at least two travel destinations contained in the search request. Even if only the multi-trip ticket purchase solutions corresponding to some travel routes are returned, the user operation is simplified to a certain extent, and the user's query and ticket purchase efficiency is improved, without the need for the user to initiate search requests for these travel routes one by one.

[0059] Step 206, displaying at least a portion of the received multi-trip ticket purchase plan.

[0060] There is often a certain waiting time after initiating a search request and before displaying the received multi-trip travel ticket purchase plan. During this waiting time, the client can display a transition page to indicate to the user that the travel service platform is processing the search request submitted by the user, and at the same time provide the user with some auxiliary information. Figure 4 In the transition page shown, auxiliary explanatory information may include: search conditions shown at the top of the page, such as the user-defined departure point "Hangzhou", travel destination "Chiang Mai + Singapore", departure date "departure in the next 1 month" and total travel duration "3-15 days", etc.; function introduction information shown in the middle of the page, etc.

[0061] The client may display all received multi-trip ticket purchase schemes, or may only display some of them. When displaying all multi-trip ticket purchase schemes, the client does not necessarily display all multi-trip ticket purchase schemes at the same time, and may also display these multi-trip ticket purchase schemes step by step in multiple times. When displaying some multi-trip ticket purchase schemes, there may be multiple situations: in one case, the client does not limit the display of multi-trip ticket purchase schemes, and displays all multi-trip ticket purchase schemes step by step in the above manner, but the user may have decided to purchase the multi-trip ticket purchase scheme or initiated a new search request after viewing some multi-trip ticket purchase schemes, so that the remaining multi-trip ticket purchase schemes have not been displayed in time, so only some multi-trip ticket purchase schemes are displayed; in another case, the client itself screens the multi-trip ticket purchase schemes that can be displayed, for example, for each group of multi-trip ticket purchase schemes, only at least one multi-trip ticket purchase scheme that is relatively more advantageous in the specified dimension within the group is displayed, which will be described in detail below.

[0062] The client can display the multi-trip ticket purchase plan in the search result page. The multi-trip ticket purchase plan can be arranged in any way in the search result page, and this specification does not limit this.

[0063] For example, all multi-trip ticket purchase plans can be arranged in order from top to bottom in the search results page. Accordingly, the user only needs to slide and turn the pages of the search results page to browse these multi-trip ticket purchase plans in sequence. Alternatively, each group of multi-trip ticket purchase plans can be displayed in different display areas of the search results page. For example, when there are two groups of multi-trip ticket purchase plans, the search results page can include two display areas, so that each group of multi-trip ticket purchase plans is displayed in a corresponding display area, and the user can slide and turn the pages of different display areas synchronously or independently.

[0064] For another example, the client can display the at least two sets of multi-trip ticket purchase solutions through at least two tabs contained in the search result page. Figure 5 In the search result page 50 shown, a set of multi-trip ticket purchase plans corresponding to the travel route "Hangzhou→Chiang Mai→Singapore" is displayed on the left tab page, and a set of multi-trip ticket purchase plans corresponding to the travel route "Hangzhou→Singapore→Chiang Mai" is displayed on the right tab page. Figure 5 Only the left tab page is fully displayed, while the right tab page only shows its tab bar (Tab Bar). When there are more travel routes, the search result page 50 can obviously also display more tab pages.

[0065] For easy distinction and viewing, the tab title (Tab Title) shown in the tab bar of each tab page may include at least one of the following: description information of the travel route corresponding to the multi-trip travel ticket purchase plan of the corresponding group, and the optimal value of the multi-trip travel ticket purchase plan of the corresponding group in a specified dimension. Figure 5 As shown, in the tab bar 51 of the left tab page, the description information of the travel route may include: the name of the travel route "Route 1", the travel destinations included in the travel route and their arrangement order "Chiang Mai→Singapore"; of course, Figure 5 The order of "Chiang Mai" and "Singapore" is specifically characterized through the following three dimensions: 1) Based on the general reading order from left to right, "Chiang Mai" is placed on the left side of "Singapore", which is equivalent to placing "Chiang Mai" in front of "Singapore"; 2) An arrow pointing from "Chiang Mai" to "Singapore" is added between "Chiang Mai" and "Singapore"; 3) A mark containing "first" is added to "Chiang Mai", and a mark containing "after" is added to "Singapore". And, the optimal value of the specified dimension contained in the label column 51, the specified dimension can specifically be the ticket price, and the optimal value of the ticket price refers to: in a group of multi-trip ticket purchase plans corresponding to the travel route "Hangzhou→Chiang Mai→Singapore", the multi-trip ticket purchase plan with the lowest price, such as Figure 5 The optimal value shown in is "￥1889". Of course, Figure 5The specific content shown in the label bar 51 is "starting from ￥1889", and "starting from" indicates that in addition to the multi-trip ticket purchase plan with a ticket price of ￥1889, there are other optional multi-trip ticket purchase plans on this travel route, but the ticket price will be relatively higher. Of course, with regard to the above-mentioned specified dimensions, in addition to the ticket price, it can also include any other dimensions that can reflect the advantages and differences between different multi-trip ticket purchase plans, and can include one or more dimensions at the same time. For example, the specified dimension may include at least one of the following: ticket price, number of transfers, transfer time, en route time, departure time, arrival time, etc., and this manual does not limit this.

[0066] The departure time period may refer to the time interval in which the departure time is located. Of course, if the start time and the end time of the time interval coincide, then as a special case, the departure time period may be the departure time itself. For departure time periods, some departure time periods are more attractive to users, for example, these departure time periods are neither too early to require users to get up early nor too late to require users to stay up late. The advantages and disadvantages of departure time periods may be defined based on normal work and rest patterns. For example, the 24 hours of the day may be divided into three departure time periods, namely, 0:00 to 6:00, 8:00 to 22:00, and 22:00 to 24:00, and the departure time period from 8:00 to 22:00 may be defined as being relatively better and the other two departure time periods as being relatively worse. For the relatively better 8:00 to 22:00, it may be further divided into more detailed departure time periods and relative advantages and disadvantages may be defined. The other two relatively worse departure time periods are also similar, and they are not listed one by one here. The situation of the arrival time period is similar to the above description of the departure time period, and it may also be divided into different arrival times and corresponding advantages and disadvantages may be defined, and they are not repeated here.

[0067] Similarly, in the tab bar 52 of the right tab page, the same type of information as that in the tab bar 51 may also be displayed, which will not be described in detail here.

[0068] When displaying the multi-trip ticket purchase plan, the client can use any method such as text, graphics, etc., and this specification does not limit this. For example, each group of multi-trip ticket purchase plans received can be displayed separately in the following ways: in the text display area in the search results page, the multi-trip ticket purchase plans of the corresponding group are arranged and displayed in the form of text; in the graphic display area in the search results page, a map is displayed and the multi-trip ticket purchase plan selected in the text display area is marked on the map. Through the coordinated display of text and graphics, users can not only read the details of the corresponding multi-trip ticket purchase plan from the text, but also obtain a more intuitive plan presentation through graphics, which helps users better understand the corresponding multi-trip ticket purchase plan.

[0069] Taking the above-mentioned tab-based display method as an example, the text display area and the graphic display area can be located in each tab page respectively; of course, the tab page format is not required. Figure 5 The search result page 50 shown shows a tab page corresponding to the tab bar 51, and the tab page includes a graphic display area 511 and a text display area 512. In the text display area 512, various multi-trip ticket purchase plans described in text form are arranged from top to bottom. For example, the multi-trip ticket purchase plan arranged at the top shows: "09.01 to 09.07 return, a total of 7 days", indicating that the departure date from Hangzhou is 09.01, the return date to Hangzhou is 09.07, and the total trip is 7 days; "￥1889" indicates the purchase price of the multi-trip ticket purchase plan; "·Hangzhou-Chiang Mai 14:50-20:25 transfer in Kunming for 2h10m", indicating that the departure place of the first itinerary segment is Hangzhou, the destination is Chiang Mai, and the take-off and landing times of the corresponding flights. The time is 14:50 and 20:25 respectively, the corresponding flights are connecting flights and the specific connecting place is Kunming, the connecting time is 2 hours and 10 minutes; "·Chiang Mai-Singapore 11:15-15:20 direct flight" indicates that the departure place of the second itinerary segment is Chiang Mai and the destination is Singapore, the take-off and landing times of the corresponding flights are 11:15 and 15:20 respectively, and the corresponding flights are direct flights; "·Singapore-Hangzhou 03:30-08:50 direct flight" indicates that the departure place of the third itinerary segment is Singapore and the destination is Hangzhou, the take-off and landing times of the corresponding flights are 03:30 and 08:50 respectively, and the corresponding flights are direct flights. Other multi-trip travel ticket purchase plans are similar and will not be listed here one by one.

[0070] In the graphic display area 511, the background graphic may be a map (not specifically shown in the figure). When a multi-trip ticket purchase plan in the text display area 512 is selected, such as Figure 5 The selected multi-trip ticket purchasing plan is the multi-trip ticket purchasing plan arranged at the top and described in detail above, and the selected multi-trip ticket purchasing plan can be marked on the map in the graphic display area 511.

[0071] When marking the selected multi-trip ticket purchase plan on the map, each itinerary segment involved in the selected multi-trip ticket purchase plan can be marked on the map in the form of a directed line, the endpoints of the directed line are the departure city and the arrival city of the corresponding itinerary segment, and the direction is from the departure city to the arrival city; and the corresponding itinerary description information is shown for each directed line, and the itinerary description information includes one or more of the following: itinerary order, departure date, arrival date, number of transfers, itinerary duration, tour duration, etc., which is not limited in this manual. For example Figure 5As shown, for the three journey segments mentioned above, corresponding directed lines can be shown respectively, which can specifically include a line segment with Hangzhou as the starting endpoint and Chiang Mai as the ending endpoint, and an arrow from Hangzhou to Chiang Mai is marked on the line segment. Since it involves a transfer in Kunming, the line segment is specifically divided into two segments from Hangzhou to Kunming and from Kunming to Chiang Mai. Similarly, directed lines also include: a line segment with Chiang Mai as the starting endpoint and Singapore as the ending endpoint, and an arrow from Chiang Mai to Singapore is marked on the line segment, and a line segment with Singapore as the starting endpoint and Hangzhou as the ending endpoint, and an arrow from Singapore to Hangzhou is marked on the line segment. And, corresponding to the first journey segment from Hangzhou to Chiang Mai, Figure 5 A rounded rectangle is shown at the corresponding directed line, which contains the itinerary description information for this itinerary segment, including: "Chiang Mai" and the symbol "first" in front of it, indicating that the itinerary order is "first"; "09.01 Thursday" indicates the departure date; "1 transfer" indicates the number of transfers; "Total 7h" indicates that the trip takes 7 hours. Of course, as mentioned above, the itinerary description information can also include other items, such as "09.01 Thursday" to indicate the arrival date, and the duration of the trip can be marked at the endpoint corresponding to the travel destination (for example, "4 days" is marked at "Chiang Mai"), etc. Figure 5 Not all are shown in the embodiment. For other travel segments, Figure 5 Similar itinerary description information is also displayed in , which will not be listed here one by one.

[0072] As mentioned above, for each group of multi-trip ticket purchase solutions, the client can only display at least one multi-trip ticket purchase solution that is relatively more advantageous in the specified dimension within the group. Figure 5 As shown, for the specified dimension of ticket price, the multi-trip ticket purchase plan with the lowest ticket price in the group of multi-trip ticket purchase plans can be shown. The multi-trip ticket purchase plan can be, for example, the multi-trip ticket purchase plan arranged at the top in the text display area 512. Further, in order to allow customers to clearly understand the specified dimension corresponding to the multi-trip ticket purchase plan, the advantage information of the displayed multi-trip ticket purchase plan in the corresponding specified dimension can be annotated. For example, for the multi-trip ticket purchase plan arranged at the top in the text display area 512, Figure 5 A "lowest price" label is shown in the figure to indicate its superiority information in the specified dimension of ticket purchase price.

[0073] Of course, in addition to the ticket price, the above-mentioned designated dimensions may also include any other dimensions that can reflect the advantages and differences between different multi-trip travel ticket purchase plans, and may include one or more dimensions at the same time. For example, the designated dimensions include at least one of the following: ticket price, number of transfers, transfer time, en route time, departure time, arrival time, etc., and this specification does not limit this. Figure 5 For example: the multi-trip ticket purchasing plan ranked second in the text display area 512 has the lowest price among all multi-trip ticket purchasing plans with one transfer, which is equivalent to having an advantage in the specified dimension of the combination of ticket price and number of transfers. The label displayed for this multi-trip ticket purchasing plan is "low price and convenient transfer"; the multi-trip ticket purchasing plan ranked third in the text display area 512 (only part of the content is shown in the figure) has an advantage in the specified dimension of en route time (i.e., the time the user spends on transportation), that is, its en route time is relatively short, and the label displayed for this multi-trip ticket purchasing plan is "fastest".

[0074] As mentioned above, if the search request includes play time description information, and the play time description information is used to describe the total play time, there are multiple division schemes for the total play time that are divided into at least two travel destinations in the search request, and each group of multi-trip travel ticket purchase schemes includes multi-trip travel ticket purchase schemes corresponding to each division scheme. Accordingly, for at least one travel destination, a corresponding separate play time setting control can be displayed for setting a separate play time at the corresponding travel destination; in response to the separate play time setting control corresponding to any travel destination being triggered, play time options are displayed; and based on the selected play time options, the corresponding group of multi-trip travel ticket purchase schemes are filtered and displayed. In this way, users can filter based on the separate play time in order to view the multi-trip travel ticket purchase schemes that interest them. For example Figure 5 As shown, in the text display area 512, a separate play duration setting control displayed as "Number of days to stay in Chiang Mai" and a separate play duration setting control displayed as "Number of days to stay in Singapore" may be included, so as to set the corresponding separate play durations of Chiang Mai and Singapore respectively. The user may set the separate play durations of only some (one or more) travel destinations, or may set the separate play durations of all travel destinations, and the client may filter and display the multi-trip travel ticket purchase plans that meet the requirements.

[0075] It should be noted that: When describing the search result page 50 above, the main Figure 5 The tab page corresponding to "Route 1" is introduced. If the user is interested in "Route 2", the tab bar 52 can be triggered to switch to the tab page corresponding to "Route 2". For example, please refer to Figure 6 .exist Figure 6 Specifically, it may include a graphic display area 521 and a text display area 522. For the graphic display area 521, reference may be made to the description related to the graphic display area 511 in the foregoing text, and for the text display area 522, reference may be made to the description related to the text display area 512 in the foregoing text, and no further description will be given here.

[0076] exist Figure 5-6 In the search result page 50 shown, a "book air ticket" control is displayed at the bottom of the page. After the user selects a multi-trip travel ticket purchase plan of interest, the user can view and purchase the air tickets involved in the corresponding multi-trip travel ticket purchase plan by triggering the "book air ticket" control. The travel service platform can assist the user in purchasing multiple air tickets involved in the corresponding multi-trip travel ticket purchase plan at one time, without the user having to purchase each air ticket separately, thereby simplifying the user's operation and improving the convenience of purchasing air tickets.

[0077] Figure 7 This is a flowchart of a method for generating a multi-trip ticket purchase plan provided by an exemplary embodiment, and the method is applied to the service end of a travel service platform. Figure 7 As shown, the method may include the following steps:

[0078] Step 702, receiving a search request for a multi-trip ticket purchase plan initiated by a client of the travel service platform, the search request including at least a departure place and at least two travel destinations;

[0079] Step 704, generating at least two groups of multi-trip ticket purchase plans, each group of multi-trip ticket purchase plans corresponding to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different;

[0080] Step 706: Return the generated multi-trip ticket purchase plan to the client so that the client can display at least a part of it.

[0081] It should be noted that: Figure 2 The embodiments described in the accompanying drawings illustrate the technical solution of this specification from the perspective of the client side. Figure 7 The same technical solution is described from the perspective of the server side, that is, the overall design concept of the two is consistent, but there are some differences in the description angles. Therefore, all the contents described in the client side embodiment are actually applicable to Figure 7 Therefore, in the embodiment of the server side. Figure 7 To understand the illustrated embodiments, reference may be made to the above embodiments on the client side, which will not be described in detail here.

[0082] To sum up, this manual is aimed at the scenario of multi-trip travel. The server of the travel service platform can provide corresponding multi-trip ticket purchasing plans for various travel routes between the departure place and each travel destination, so that the user only needs to perform a query operation once to inform the above-mentioned departure place and each travel destination, and then the user can view each group of multi-trip ticket purchasing plans through the client of the travel service platform, so as to facilitate the user to compare and purchase, which greatly simplifies the user operation, reduces the time spent on query and ticket purchase, and also helps the user to determine the multi-trip ticket purchasing plan that best suits him or her.

[0083] Figure 8 is a schematic structural diagram of a device provided by an exemplary embodiment. Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, a memory 808, and a non-volatile memory 810, and may also include hardware required for other functions. One or more embodiments of this specification may be implemented based on software, such as the processor 802 reading the corresponding computer program from the non-volatile memory 810 into the memory 808 and then running it. Of course, in addition to the software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0084] Please refer to Fig. 9 , a display device for multi-trip ticket purchasing scheme can be used for example Figure 8 The device shown is specifically applied to the client of the travel service platform to implement the technical solution of this specification. The device may include:

[0085] A request initiating unit 901 initiates a search request for a multi-trip ticket purchase plan to a server of the travel service platform, wherein the search request includes at least a departure place and at least two travel destinations;

[0086] A plan receiving unit 902 receives at least two sets of multi-trip ticket purchase plans returned by the server, each set of multi-trip ticket purchase plans corresponds to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different;

[0087] The plan display unit 903 displays at least a portion of the received multi-trip ticket purchase plan.

[0088] Optionally, the solution display unit 903 is specifically used for:

[0089] The at least two sets of multi-trip ticket purchasing plans are displayed respectively through at least two tabs included in the search result page;

[0090] The label title shown in the label bar of each label page includes at least one of the following: description information of the travel route corresponding to the multi-trip travel ticket purchase plan of the corresponding group, and the optimal value of the multi-trip travel ticket purchase plan of the corresponding group in a specified dimension;

[0091] The specified dimensions include at least one of the following: ticket price, number of transfers, transfer time, transit time, departure time, and arrival time.

[0092] Optionally, the solution display unit 903 displays each received set of multi-trip ticket purchase solutions separately in the following manner:

[0093] In the text display area of ​​the search result page, the multi-trip travel ticket purchase plans of the corresponding group are arranged and displayed in text form;

[0094] In the graphic display area of ​​the search result page, a map is displayed and the multi-trip ticket purchasing plan selected in the text display area is marked on the map.

[0095] Optionally, marking the selected multi-trip travel ticket purchasing plan in the text display area on the map includes:

[0096] Marking each itinerary segment involved in the selected multi-trip ticket purchase plan on the map in the form of a directed line, wherein the endpoints of the directed line are the departure city and the arrival city of the corresponding itinerary segment, and the direction is from the departure city to the arrival city;

[0097] Corresponding itinerary description information is shown for each directed line, and the itinerary description information includes one or more of the following: itinerary sequence, departure date, arrival date, number of transfers, itinerary duration, and tour duration.

[0098] Optionally, the solution display unit 903 is specifically used for:

[0099] For each group of multi-trip ticket purchase plans, only at least one multi-trip ticket purchase plan that is relatively more advantageous in a specified dimension within the group is displayed; wherein the specified dimension includes at least one of the following: ticket price, number of transfers, transfer time, en route time, departure time, and arrival time;

[0100] Alternatively, for each group of multi-trip ticket purchasing solutions, only at least one multi-trip ticket purchasing solution that is relatively more advantageous in a specified dimension within the group is displayed, and the advantage information of the displayed multi-trip ticket purchasing solution in the corresponding specified dimension is marked.

[0101] Optionally, the search request further includes: a return location;

[0102] Each multi-trip travel ticket purchase plan includes: a one-way ticket purchase plan from the departure point to the first travel destination in the corresponding travel route, a one-way ticket purchase plan between each travel destination in the corresponding travel route, and a one-way ticket purchase plan from the last travel destination in the corresponding travel route to the return point.

[0103] Optionally, the search request further includes: description information of the departure date and description information of the playing time;

[0104] The departure date description information is used to describe: the precise date of departure from the departure place or the future time period of the departure date;

[0105] The play time description information is used to describe: the total play time at the at least two travel destinations or the individual play time at each travel destination.

[0106] Optionally, when the play duration description information is used to describe the total play duration, there are multiple division schemes of the total play duration into the at least two travel destinations, and each group of multi-trip travel ticket purchase schemes includes multi-trip travel ticket purchase schemes corresponding to each division scheme; the device further includes:

[0107] A control display unit, for at least one travel destination, displays a corresponding independent play time setting control for setting an independent play time at the corresponding travel destination;

[0108] An option display unit, in response to a separate play time setting control corresponding to any travel destination being triggered, displays play time options;

[0109] The screening unit screens and displays the multi-trip ticket purchasing plans of the corresponding group according to the selected travel duration options.

[0110] Please refer to Fig.10 , a device for generating a multi-trip ticket purchase plan can be applied to Figure 8 The device shown is specifically applied to the server of the travel service platform to implement the technical solution of this specification. The device may include:

[0111] A request receiving unit 1001 receives a search request for a multi-trip ticket purchase plan initiated by a client of the travel service platform, wherein the search request includes at least a departure place and at least two travel destinations;

[0112] A plan generating unit 1002 generates at least two sets of multi-trip ticket purchasing plans, each set of multi-trip ticket purchasing plans corresponds to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different;

[0113] The solution returning unit 1003 returns the generated multi-trip ticket purchasing solution to the client, so that the client can display at least a part of it.

[0114] Based on the same concept as the above method, this specification also provides an electronic device, including: a processor; a memory for storing processor executable instructions; wherein the processor implements the steps of the method described in any of the above embodiments by running the executable instructions.

[0115] Based on the same concept as the above method, this specification also provides a computer-readable storage medium on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in any of the above embodiments are implemented.

[0116] Based on the same concept as the above method, this specification also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any of the above embodiments when executed by a processor.

Claims

1. A method for displaying a multi-trip ticket purchasing plan, characterized in that: Clients used in travel service platforms include: Initiate a search request for a multi-trip ticket purchase plan to the service end of the travel service platform, wherein the search request includes at least a departure place and at least two travel destinations; receiving at least two sets of multi-trip ticket purchase plans returned by the server, each set of multi-trip ticket purchase plans corresponding to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different; At least a portion of the received multi-trip ticket purchasing plan is displayed.

2. The method according to claim 1, characterized in that The presenting of at least a portion of the received multi-trip ticket purchase scheme includes: The at least two sets of multi-trip ticket purchasing plans are displayed respectively through at least two tabs included in the search result page; The label title shown in the label bar of each label page includes at least one of the following: description information of the travel route corresponding to the multi-trip travel ticket purchase plan of the corresponding group, and the optimal value of the multi-trip travel ticket purchase plan of the corresponding group in a specified dimension; The specified dimensions include at least one of the following: ticket price, number of transfers, transfer time, transit time, departure time, and arrival time.

3. The method according to claim 1, characterized in that Each received set of multi-trip ticket purchase plans is displayed separately in the following ways: In the text display area of ​​the search result page, the multi-trip travel ticket purchase plans of the corresponding group are arranged and displayed in text form; In the graphic display area of ​​the search result page, a map is displayed and the multi-trip ticket purchasing plan selected in the text display area is marked on the map.

4. The method according to claim 3, characterized in that The step of marking the selected multi-trip ticket purchasing plan in the text display area on the map includes: Marking each itinerary segment involved in the selected multi-trip ticket purchase plan on the map in the form of a directed line, wherein the endpoints of the directed line are the departure city and the arrival city of the corresponding itinerary segment, and the direction is from the departure city to the arrival city; Corresponding itinerary description information is shown for each directed line, and the itinerary description information includes one or more of the following: itinerary sequence, departure date, arrival date, number of transfers, itinerary duration, and tour duration.

5. The method according to claim 1, characterized in that The presenting of at least a portion of the received multi-trip ticket purchase scheme includes: For each group of multi-trip ticket purchase plans, only at least one multi-trip ticket purchase plan that is relatively more advantageous in a specified dimension within the group is displayed; wherein the specified dimension includes at least one of the following: ticket price, number of transfers, transfer time, en route time, departure time, and arrival time; Alternatively, for each group of multi-trip ticket purchasing solutions, only at least one multi-trip ticket purchasing solution that is relatively more advantageous in a specified dimension within the group is displayed, and the advantage information of the displayed multi-trip ticket purchasing solution in the corresponding specified dimension is marked.

6. The method according to claim 1, characterized in that The search request also includes: return location; Each multi-trip travel ticket purchase plan includes: a one-way ticket purchase plan from the departure point to the first travel destination in the corresponding travel route, a one-way ticket purchase plan between each travel destination in the corresponding travel route, and a one-way ticket purchase plan from the last travel destination in the corresponding travel route to the return point.

7. The method according to claim 1, characterized in that The search request also includes: departure date description information and play time description information; The departure date description information is used to describe: the precise date of departure from the departure place or the future time period of the departure date; The play time description information is used to describe: the total play time at the at least two travel destinations or the individual play time at each travel destination.

8. The method according to claim 7, characterized in that In the case where the play duration description information is used to describe the total play duration, there are multiple division schemes for the total play duration to be divided into the at least two travel destinations, and each group of multi-trip travel ticket purchase schemes includes multi-trip travel ticket purchase schemes corresponding to each division scheme respectively; the method further includes: For at least one travel destination, displaying a corresponding separate play time setting control for setting the separate play time at the corresponding travel destination; In response to a separate play time setting control corresponding to any travel destination being triggered, displaying play time options; Based on the selected travel duration options, the multi-trip ticket purchasing plans for the corresponding group are filtered and displayed.

9. A method for generating a multi-trip ticket purchasing plan, characterized in that: The server side used in the travel service platform includes: Receiving a search request for a multi-trip ticket purchase plan initiated by a client of the travel service platform, the search request including at least a departure place and at least two travel destinations; generating at least two groups of multi-trip ticket purchase plans, each group of multi-trip ticket purchase plans corresponding to a travel route formed by the departure place and the at least two travel destinations, and the arrangement order of the at least two travel destinations in different travel routes is different; The generated multi-trip ticket purchasing plan is returned to the client, so that the client can display at least a part of it.

10. A computer program product, characterized in that The method comprises a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 9.

Images