CN119441642A

CN119441642A - Method for displaying and generating multi-trip ticket purchasing plan, and computer program product

Info

Publication number: CN119441642A
Application number: CN202411294644.6A
Authority: CN
Inventors: 刘媛
Original assignee: Zhejiang Feizhu Network Technology Co ltd
Current assignee: Zhejiang Feizhu Network Technology Co ltd
Priority date: 2024-09-13
Filing date: 2024-09-13
Publication date: 2025-02-14

Abstract

Embodiments of the present specification provide a method for displaying and generating a multi-trip ticket purchase plan and a computer program product. When the method is applied to a client of a travel service platform, the method comprises: initiating a search request for a multi-trip ticket purchase plan to a server of the travel service platform, the search request at least including a departure place and at least two travel destinations; receiving at least two groups of multi-trip ticket purchase plans returned by the server, 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; and displaying at least a part of the received multi-trip ticket purchase plans.

Description

Presentation and generation method of multi-journey ticket buying scheme and computer program product

Technical Field

One or more embodiments of the present disclosure relate to the field of internet technology, and in particular, to a method and a computer program product for displaying and generating a multi-journey ticket buying scheme.

Background

Users often need to travel outside, either public or private. For this reason, users need to purchase traffic tickets between different places to meet their traffic travel needs between different places. The travel service platform may provide ticketing services to users for querying and purchasing the traffic ticket described above by the user.

In the related art, the travel service platform supports only inquiry and purchase of one-way travel ticketing schemes. The single trip ticketing scheme contains information about traffic tickets from one location to another, such as from the departure location to the trip destination. However, in addition to single-trip travel, the user may sometimes need to make multiple trips, i.e., two or more trips at the same time, so that there are multiple trips between the departure point and each of the trips, and the user only has to query the corresponding multiple trips for each of the trips, and finally determine the multiple trips to be adopted after the comparison. Therefore, the multiple inquiry results in complex operation and long time consumption of the user, and the manual operation of the user may cause missing of the multiple travel ticket buying schemes corresponding to part of the travel routes, which is not beneficial to the user to determine the most suitable multiple travel ticket buying scheme.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide the following technical solutions:

According to a first aspect of one or more embodiments of the present disclosure, a method for displaying a multi-journey ticket purchasing scheme is provided, which is applied to a client of a travel service platform, and includes:

Initiating a search request of a multi-travel ticket buying scheme to a service end of the travel service platform, wherein the search request at least comprises a departure place and at least two travel destinations;

Receiving at least two groups of multi-travel ticket buying schemes returned by the service end, wherein each group of multi-travel ticket buying schemes corresponds to one 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-pass travel ticketing scheme is displayed.

According to a second aspect of one or more embodiments of the present disclosure, a method for generating a multipass travel ticketing scheme is provided, which is applied to a service end of a travel service platform, and includes:

receiving a search request of a multi-travel ticket buying scheme initiated by a client of the travel service platform, wherein the search request at least comprises a departure place and at least two travel destinations;

generating at least two groups of multi-travel ticketing schemes, wherein each group of multi-travel ticketing schemes corresponds to one 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;

and returning the generated multi-journey ticket buying scheme to the client side so as to enable the client side to display at least one part of the generated multi-journey ticket buying scheme.

According to a third aspect of one or more embodiments of the present description, a computer program product is presented, comprising a computer program/instruction which, when executed by a processor, implements the steps of the method according to the first or second aspect.

According to the embodiment, the service end of the travel service platform can provide corresponding multi-travel ticket buying schemes for various travel routes between the departure place and each travel destination respectively according to the multi-travel scenes, so that a user can check each group of multi-travel ticket buying schemes through the client end of the travel service platform only by executing one query operation to inform the departure place and each travel destination, the comparison and purchase of the user are facilitated, the operation of the user is greatly simplified, the time consumption for inquiring and buying tickets is reduced, and the user is facilitated to determine the most suitable multi-travel ticket buying scheme.

Drawings

FIG. 1 is a schematic diagram of a system architecture upon which a travel service platform is dependent, as provided by an exemplary embodiment.

FIG. 2 is a flow chart of a method for presenting a multi-pass travel ticketing scheme, as provided by an exemplary embodiment.

Fig. 3 is a schematic diagram of a ticketing scheme search page in an air ticket scenario, provided by an exemplary embodiment.

FIG. 4 is a schematic diagram of a transition page provided by an exemplary embodiment.

Fig. 5-6 are diagrams of a tab page based search results page provided in an exemplary embodiment.

Fig. 7 is a flowchart of a method for generating a multi-trip ticket buying plan according to an exemplary embodiment.

Fig. 8 is a schematic diagram of an apparatus according to an exemplary embodiment.

Fig. 9 is a block diagram of a presentation device for a multi-journey ticketing scheme provided by an example embodiment.

Fig. 10 is a block diagram of an apparatus for generating a multi-pass travel ticketing scheme, as provided by an exemplary embodiment.

Detailed Description

User information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, presented data, etc.) referred to in this specification are both information and data authorized by the user or sufficiently authorized by the parties, and the collection, use and processing of relevant data requires compliance with relevant laws and regulations and standards of the relevant country and region, and is provided with corresponding operation portals for the user to choose authorization or denial.

FIG. 1 is a schematic diagram of a system architecture upon which a travel service platform is dependent, as provided by an exemplary embodiment. As shown in fig. 1, the system architecture may include a server 11, a network 12, several electronic devices, such as a PC (Personal Computer ) 13, a cell phone 14, and so on.

The server 11 may be a physical server comprising a separate host, or the server 11 may be a virtual server carried by a cluster of hosts. During operation, the server 11 may run a server-side program of the travel service platform to be implemented as a server side of the travel service platform.

The PC13 and the mobile phone 14 are only some types of electronic devices that can be used by the user. Indeed, it should be apparent that a user may also use electronic devices such as tablet devices, notebook computers, personal computers (PDAs), wearable devices (e.g., smart glasses, smart watches, etc.), and the like, as one or more embodiments of the present disclosure are not limited in this regard. During operation, the electronic device may run a client-side program of the travel service platform to implement a client of the travel service platform. Wherein, the application program of the client side of the travel service platform can be started and run on the electronic equipment. The client-side program may be a native application installed on the electronic device, or the client-side program may be an applet, a quick application, or other similar form. Of course, when using web page technology such as HTML5 or the like, the relevant functions may be implemented through the pages presented by the browser, where the browser may be a stand-alone browser application, or may be a browser module embedded in some applications.

The network 12 for interaction between the electronic devices such as the PC13 and the mobile phone 14 and the server 11 may be a wired or wireless network specifically selected to implement communication based on the communication mode supported by the corresponding electronic devices, which is not limited in this specification. For example, the PC13 may support both wired and wireless communications, and may employ a wired or wireless network for communications as desired, while the handset 14 typically supports only wireless communications, and may employ a wireless network for communications.

In the related art, a travel service platform supports a user searching for a one-way travel ticketing scheme. The method comprises the steps that a client of a travel service platform can provide a ticket buying scheme searching page for a user, the user can fill the ticket buying scheme searching page according to a departure place and a travel destination of the user, and accordingly, the service end of the travel service platform can execute searching operation, the inquired one-way travel ticket buying scheme is returned to the client and is displayed in a searching result page of the client for the user to check and purchase.

However, if the user has two or more travel destinations, the search process becomes cumbersome. For example, the user needs to determine all possible travel routes by himself, wherein the first travel route is 'A ground- & gt B ground- & gt C ground', the second travel route is 'A ground- & gt C ground- & gt B ground', and the user needs to split each travel section and search for a single-way travel ticket buying scheme corresponding to each travel section respectively for each route, then manually combine multiple-way travel ticket buying schemes corresponding to each travel route and finally buy after comparison. Specifically, for the first travel route, the user needs to search for a single-trip travel ticket booking scheme of "a place of departure is a place of departure and a destination is B place of departure", a single-trip travel ticket booking scheme of "B place of departure is B place of destination is C place of destination", and then combine to obtain a multi-trip travel ticket booking scheme. Similarly, for the second travel route, the user needs to search for a single-trip ticketing scheme of "origin a, destination C", a single-trip ticketing scheme of "origin C, destination B", respectively, and then combine to obtain a multi-trip ticketing scheme. If the number of travel destinations is greater, the number of travel routes is greater, the splitting and searching process for each travel route is more complex, the operation required by the user to determine each multi-travel ticketing scheme becomes very tedious, time-consuming and laborious, and omission of, for example, a part of the travel routes and the corresponding multi-travel ticketing schemes is easily caused, so that the user cannot determine the most suitable multi-travel ticketing scheme.

Therefore, the technical scheme of the specification provides a technical scheme suitable for a multi-travel scene, and can be operated by a user in the process of searching the multi-travel ticket buying scheme, so that the searching efficiency is improved, and the user is assisted to determine the most suitable multi-travel ticket buying scheme.

The technical scheme of the present specification will be described in detail with reference to fig. 2.

FIG. 2 is a flow chart of a method for presenting a multi-pass travel ticketing scheme as provided by an exemplary embodiment, the method being applied to a client of a travel service platform. As shown in fig. 2, the method may include the steps of:

step 202, a search request of a multi-journey travel ticket buying scheme is initiated to a service end of the travel service platform, wherein the search request at least comprises a departure place and at least two travel destinations.

The client of the travel service platform can display a ticket buying scheme searching page, wherein the ticket buying scheme searching page comprises setting controls for various searching conditions. The user may define the corresponding search criteria based on the set control. The client may initiate the search request described above based on user-defined search criteria. The search request includes a user-defined search condition, so that the server side of the travel service platform can execute the search operation according to the search condition. For example, the search criteria includes at least a user-defined origin and at least two travel destinations.

The setting control for the search condition may take any form. For example, the setting control may be an input box so that a user may input a corresponding search condition therein. For another example, the setup control may be a selection box such that a user may view predefined alternatives and select one or more alternatives therefrom as search criteria. In some cases, the setup controls have initially included and exhibited search criteria defined by default or based on preset rules, without additional definition if the user approves the search criteria, thereby simplifying user operation, and of course, if not approved, the user may redefine.

For example, fig. 3 is a schematic diagram of a ticket buying scheme search page in an air ticket scenario according to an exemplary embodiment. As shown in fig. 3, under the "multi-city upstream" tab page, a search request to initiate a multi-journey ticketing scheme may be supported. At the same time, the ticketing scheme search page is also compatible with search operations of a one-way travel ticketing scheme, such as a user can switch to a "one-way" tab page or a "round-trip" tab page to initiate a one-way travel ticketing scheme when there is only a single origin and a single travel destination. Of course, in other embodiments, the client of the travel service platform may respectively present a ticket buying scheme search page corresponding to a one-way travel ticket buying scheme and a multi-way travel ticket buying scheme, which is not limited in this specification.

Taking "departure place" as an example, the city specifically defined in fig. 3 is "hangzhou". This may be entered by the user directly by way of an input method or voice, or may be selected by the user from an alternative city (not shown) provided by the client. Or through the electronic equipment (such as a mobile phone and the like) where the client of the travel service platform is located, the city where the user is located can be automatically located to be Hangzhou under the condition that the locating function is started, so that the departure place is directly predefined to be Hangzhou without manual input or selection of the user. Of course, the user may redefine as other cities at any time.

Taking "travel destination" as an example, the cities specifically defined in fig. 3 are "Chiang Mai +singapore", i.e., two cities of "Chiang Mai" and "singapore". Similar to the "departure place" described above, the user may define the "travel destination" herein by manually inputting or selecting, and will not be described here again. Furthermore, "Chiang Mai +singapore" here may also be predefined. For example, the travel service platform may calculate the travel popularity of each city based on the ticket sales data, the ticket query data, the city search data, the hotel reservation data, etc., and may determine the popular city identified by the travel service platform based on the preference of each ticket or other dimensions, so that the popular city is predefined as the "travel destination" and may be used as the recommendation or reference information provided to the user.

The city involved in the multi-trip ticketing scheme may include only the origin and at least two travel destinations described above. In this case, each multi-trip ticketing scheme actually includes a one-trip ticketing scheme from the origin to the first travel destination in the corresponding travel route, and a one-trip ticketing scheme between the various travel destinations in the corresponding travel route. For example, taking fig. 3 as an example, when the departure place is Hangzhou and the travel destination is Chiang Mai and Singapore respectively, one travel route is Hangzhou, chiang Mai and Singapore, and correspondingly, in a multi-travel ticket buying scheme determined according to the method, the single-pass ticket buying scheme corresponding to the first travel destination from the departure place to the corresponding travel route is specifically referred to as a single-pass ticket buying scheme corresponding to Hangzhou and the destination is Chiang Mai, and the single-pass ticket buying scheme corresponding to each travel destination from the corresponding travel route is specifically referred to as Chiang Mai and the destination is Singapore.

Further, the search condition may further include a return location defined by the user, and the search request may further include the return location. Regarding the manner in which the user defines the return place, reference may be made to the above description regarding the departure place and the travel destination, and the description is not repeated here. In this case, each multi-trip ticketing scheme includes a one-trip ticketing scheme from a last travel destination in a corresponding travel route to a return destination in addition to the aforementioned "one-trip ticketing scheme from a departure point to a first travel destination in the corresponding travel route" and "one-trip ticketing scheme between respective travel destinations in the corresponding travel route". For example, when the departure place is Hangzhou, the travel destination is Chiang Mai, the Singapore is Singapore, and the return place is Hangzhou, one travel route is Hangzhou, chiang Mai, singapore, hangzhou, and accordingly, in the multi-travel ticket buying scheme determined according to the foregoing "one-way ticket buying scheme from the departure place to the first travel destination in the corresponding travel route", particularly the one-way ticket buying scheme from the departure place to the Hangzhou is Chiang Mai, the one-way ticket buying scheme from the departure place to the travel destinations in the corresponding travel route "particularly the one-way ticket buying scheme from the departure place to Chiang Mai, the destination to the Singapore is the one-way ticket buying scheme from the last travel destination in the corresponding travel route to the return place". It will be appreciated that the resulting multi-trip ticket booking scheme corresponds to a "trip" ticket involving only the user's travel, and not a "return" ticket, if only the origin and travel destination are included, and to a "round trip" ticket involving both the "trip" and the "return" ticket, if further included. On the client side of the travel service platform, the user can choose whether to define the return place according to the actual requirement, and the specification is not limited to the definition.

Note that, for each single-trip ticket buying scheme included in the multi-trip ticket buying scheme, in fact, the ticket buying scheme from one place to another place may be a direct ticket buying scheme from one place to another place, or a transit ticket buying scheme from one place to another place after transit through at least one transit place, which is not limited in this specification. For example, as shown in FIG. 3, consider a one-way travel ticketing scheme from Hangzhou to Chiang Mai, which may correspond to a straight flight from Hangzhou to Chiang Mai or a transfer flight from Hangzhou to Kunming and then to Chiang Mai.

The service end of the travel service platform may maintain price information of the traffic shifts and corresponding traffic tickets obtained from various traffic service parties. The price of traffic tickets often fluctuates dynamically with date. Therefore, the ticket purchase price of the finally presented multi-trip ticket purchase scheme is necessarily related to the departure date corresponding to each one-trip ticket purchase scheme contained in the ticket purchase scheme. For each trip segment in the multi-trip scene, the server needs to search from at least a part of the traffic shifts and the price information of the corresponding traffic ticket maintained by the server based on the departure place, the destination and the departure date under the trip segment to obtain a one-way trip ticket purchasing scheme corresponding to the trip segment.

As previously described, the search request includes at least a departure point and at least two travel destinations. Based on each travel route determined in the method, each travel section can be split, and the departure place and destination under each travel section can be determined. Similarly, when the search request further includes a return destination, a further increase in travel distance from the last travel destination in the corresponding travel distance to the return destination corresponds to each travel distance. Then, for each leg, it is apparent that the corresponding departure and destination can be determined.

The server may determine the departure date for each of the travel segments based on a variety of ways.

In an embodiment, the search condition may further include departure date description information and play duration description information, and the corresponding search request may further include departure date description information and play duration description information. Wherein the departure date description information is used to describe a precise date of departure from a departure place (departure place contained in a search request) or a future period in which the departure date is located, and the play duration description information is used to describe a total play duration at least two travel destinations (travel destinations contained in the search request) or a separate play duration at each travel destination.

The departure date description information describes the initial departure date of the whole multi-journey travel. In the respective travel route sections, the initial departure date is the departure date of the first travel route section. The exact date described above, i.e., the user may directly define the initial departure date as a specific date, such as "2024, 10, 27". The future time period described above, i.e., the time range in which the user can define the initial departure date, such as "future 1 month", "future half year", "future 1 year", and the like. Taking the example of "1 month in the future", assuming that the day on which the search request is sent is "2024, 8, 27, then it indicates that the time range of the initial departure date is 2024, 8, 27, to 2024, 9, 27, and the server will search accordingly.

If the playing time length description information describes the individual playing time length at each travel destination, the starting date corresponding to each travel section of each travel route can be determined by combining the initial starting date. For example, assuming that the initial departure date is 2024, 9, 1, the travel route is "Hangzhou→ Chiang Mai →Singapore→Hangzhou", and the individual play time period is 3 days at Chiang Mai and 4 days at Singapore, it can be determined that in the first travel segment "Hangzhou→ Chiang Mai", the departure is Hangzhou, the destination is Chiang Mai, the departure date is 2024, 9, 1, in the second travel segment "Chiang Mai →Singapore", the departure is Chiang Mai, the destination is Singapore, the departure date is 2024, 9, 4, and in the third travel segment "Singapore→Hangzhou", the departure is Singapore, the destination is Hangzhou, and the departure date is 2024, 9, 8. Of course, there are many ways of calculating the departure date for the travel section where the departure point is the travel destination, such as the second and third travel sections described above.

For example, for a certain travel segment where the departure point is the travel destination, the departure date may be the date the travel destination was reached + the individual play duration at the travel destination. For example, in the second trip section "Chiang Mai →singapore" described above, since day Chiang Mai is reached after day 1 of day 2024 was started from Hangzhou, after the individual play period 3 days was superimposed, the date of departure from Chiang Mai was calculated to be day 2024, month 9 and day 4. For another example, the day of arrival at a travel destination may be counted in the individual play duration for that travel destination, and then for a travel segment with a departure point of the travel destination, the departure date may be the date of arrival at that travel destination+the individual play duration at that travel destination-1. For example, in the second trip section "Chiang Mai →singapore" described above, since day 2024, month 9 and 1 is Chiang Mai after the departure from Hangzhou, the 3 days of the individual play period include the day 2024, month 9 and 1, and the departure date 2024, month 9 and 3 from Chiang Mai is calculated after the overlapping of the individual play period for 3 days. Of course, whether the day of arrival at the travel destination is credited with a separate play duration may be distinguished based on the arrival time in particular, in which case the day may be credited with a separate play duration if arrived earlier, such as before 10 am, and may not be credited with a separate play duration if arrived later, such as after 6 pm. The foregoing calculation modes are all used for illustration, and the present specification is not limited to the specific calculation mode adopted.

The travel duration description information may actively divide the total travel duration of the at least two travel destinations into individual travel durations corresponding to each travel destination if the total travel duration is described. For example, the dividing scheme may be equal division or close equal division, for example, the total playing time length is 8 days, if two travel destinations exist, the individual playing time length corresponding to each travel destination may be set to be 4 days, for example, the total playing time length is 7 days, and if two travel destinations exist, the individual playing time length corresponding to each travel destination may be set to be 3 days and 4 days respectively. For another example, in the case of a unit time length of 1 day, the partitioning scheme may be generated in all possible manners, for example, the total play time length is 7 days, if there are two travel destinations, then a plurality of partitioning schemes may be obtained, for example, partitioning scheme ① corresponds to 1 day for the first travel destination and 6 days for the second travel destination, partitioning scheme ② corresponds to 2 days for the first travel destination and 5 days for the second travel destination, partitioning scheme ③ corresponds to 3 days for the first travel destination and 4 days for the second travel destination, partitioning scheme ④ corresponds to 4 days for the first travel destination and 3 days for the second travel destination, partitioning scheme ⑤ corresponds to 5 days for the first travel destination and 2 days for the second travel destination, and partitioning scheme ⑥ corresponds to 6 days for the first travel destination and 1 day for the second travel destination. The above-mentioned division modes are only used as examples, and the specific division modes are not limited in this specification. In summary, after determining the individual play duration corresponding to each travel destination based on the total play duration, the foregoing embodiment may be referred to, where the departure date corresponding to each travel section of each travel route may be determined by further combining the initial departure date described above, which is not described herein.

In addition, the individual play duration or the total play duration described in the play duration description information may be a specified duration range in addition to the precise duration in the above embodiment (e.g., the individual play duration is 3 days, the total play duration is 7 days, etc.). Then, the server may take each possible duration value in the duration range as the corresponding individual play duration or the total play duration, so as to determine, in combination with the foregoing embodiment, each departure date corresponding to each possible duration value. For example, designating a single play duration of 2-4 days at a certain travel destination, the server may set the single play duration to 2 days, 3 days, and 4 days, respectively, for determining the respective departure dates. For another example, designating a total length of play at a certain travel destination as 6-10 days, the server may set the total length of play to 6, 7, 8, 9, and 10 days, respectively, for determining the respective departure dates.

In some embodiments, the search request may not include departure date description information and play duration description information, or other information for the server to determine the departure date corresponding to each of the travel segments. Then, the server may set the departure date corresponding to each travel section based on the preset rule, for example, the default initial departure date is "1 month in the future", and the default total playing duration is "3-15 days", so as to search for a matching multi-travel ticket purchasing scheme according to the foregoing embodiment.

As previously described, the service side of the travel service platform may maintain pricing information for the traffic shifts and corresponding traffic tickets obtained from various traffic service parties and query from these information based on search requests to obtain a multi-pass travel ticketing scheme. In an airplane travel scene, a traffic service party is an airline company (abbreviated as a flight carrier), and a traffic shift is a flight. In a train trip scenario, the traffic service party is a railway carrier and the traffic shift is a train shift. In a ship travel scenario, the traffic service party is a shipping company and the traffic shift is a shipping shift. In an automobile travel scene, the traffic service party is an automobile passenger transport company, and the traffic shift is an automobile passenger transport shift. For other types of travel scenarios, no list is made here. The one-way travel ticket purchasing schemes contained in the multi-way travel ticket purchasing scheme can relate to the same type of traffic travel scene, such as an airplane travel scene, the corresponding one-way travel ticket purchasing scheme is a ticket purchasing scheme aiming at an airplane ticket, or can relate to multiple types of traffic travel scenes, such as a part of the traffic travel scene is an airplane travel scene, the other part of the traffic travel ticket purchasing scheme is a train travel scene, and the like, and the multi-way ticket purchasing scheme is a mixed ticket purchasing scheme aiming at the airplane ticket and the train ticket.

Although in the above embodiment, it is mentioned that the client of the travel service platform may present the ticket buying scheme search page shown in fig. 3 to the user, so that the user may define the search condition in the page, and further initiate the search request to the server. In other embodiments, however, the client of the travel service platform does not necessarily need to display the ticket buying scheme search page or the like, and may also initiate a search request to the server. For example, the client may provide a voice input function, so that the user only needs to input the search condition in the form of voice, and the client may send the voice input by the user or the text information obtained by conversion to the server, and initiate a search request to the server. Of course, the client of the travel service platform may also provide other types of input functions, may obtain the search condition defined by the user, and initiate a search request to the server, which is not limited in this specification.

Step 204, receiving at least two sets of multi-travel ticket buying schemes returned by the service end, wherein each set of multi-travel ticket buying schemes corresponds to one 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.

As previously described, for a user-defined origin, at least two travel destinations, at least two travel routes may be formed due to the possibility of a change in the order of arrangement between the travel destinations (i.e., the order in which travel is performed between the travel destinations). In general, if there are n travel destinations (n.gtoreq.2 and n is an integer), then the category of travel route formed is n ≡ (i.e., factoring of n). Wherein the user defines whether to return, has no effect on the number of travel routes formed.

The difference between different kinds of travel routes is mainly caused by the different arrangement sequence between at least two travel destinations. In the case where the number of travel destinations reaches three or more, the arrangement order may be different between all the travel destinations for different types of travel routes, or may be different between only a part of the travel destinations, which may eventually result in the formation of different types of travel routes. For example, assuming that the departure point is A and the travel destinations are B, C and D, it is possible to form travel route 1) as A.fwdarw.B.fwdarw.C.fwdarw.D, travel route 2) as A.fwdarw.B.fwdarw.C, travel route 3) as A.fwdarw.C.fwdarw.B, travel route 4) as A.fwdarw.C.fwdarw.D.fwdarw.B, travel route 5) as A.fwdarw.D.fwdarw.C.fwdarw.B, travel route 6) as A.fwdarw.D.fwdarw.B.fwdarw.C. Wherein, for example, travel route 1) is not the same as travel route 4) in the order of travel destinations, and for example, travel route 1) is the second station in the corresponding travel route as compared to travel route 2) but travel destinations C and D are not the same in order, which can facilitate the formation of a different type of travel route.

The at least two sets of multi-travel ticketing schemes returned by the server may be all kinds of travel routes formed based on the departure place and the at least two travel destinations contained in the search request. Or at least two sets of multi-travel ticket buying schemes returned by the service end, and the corresponding travel lines can be part types of travel lines formed based on the departure place and at least two travel destinations contained in the search request. Even if only the multi-travel ticket buying scheme corresponding to part of travel lines is returned, the user operation is simplified to a certain extent, the inquiry and ticket buying efficiency of the user is improved, and the user is not required to initiate search requests one by one for the part of travel lines.

At step 206, the received at least a portion of the multi-trip ticketing scheme is displayed.

There is often a certain waiting period after the search request is initiated and before the received multipass travel ticketing scheme is presented. During this waiting period, the client may show a transition page to indicate to the user that the travel service platform is processing search requests that it submitted, and may at the same time provide some ancillary descriptive information to the user. For example, in the transition page shown in FIG. 4, the auxiliary description information may include search conditions shown at the top of the page, such as user-defined departure place "Hangzhou", travel destination "Chiang Mai +Singapore", departure date "1 month departure in the future" and total play duration "play 3-15 days", etc., function introduction information shown at the middle of the page, etc.

The client can display all received multi-travel ticket buying schemes, and can display only part of the multi-travel ticket buying schemes. When the multi-travel ticket buying schemes are displayed, the client side does not necessarily display all the multi-travel ticket buying schemes at the same time, and can display the multi-travel ticket buying schemes step by step in multiple times. In the case of a partial multi-pass ticketing scenario, there may be cases where the client does not limit the presentation of the multi-pass ticketing scenario, and the multi-pass ticketing scenario is presented step by step in the manner described above, but the user may have decided on the multi-pass ticketing scenario to be purchased or initiated a new search request after viewing the partial multi-pass ticketing scenario, so that the remaining multi-pass ticketing scenario has not yet been presented, and thus only a partial multi-pass ticketing scenario is presented, or where the client itself screens the multi-pass ticketing scenarios that can be presented, such as presenting only at least one multi-pass ticketing scenario that is relatively advantageous in the specified dimensions of the group for each group of multi-pass ticketing scenarios, as will be described in more detail below.

The client can display the multi-journey travel ticket buying scheme in the search result page. The multiple travel ticketing schemes may be arranged in any manner in the search results page, and this is not limiting of the present description.

For example, all multi-trip ticketing schemes may be arranged in order from top to bottom in the search results page. Correspondingly, the user can browse the multi-travel ticket buying schemes in sequence only by sliding and turning pages of the search result page. Or the multiple travel ticketing schemes of each group can be respectively displayed in different display areas of the search result page. For example, when two groups of multi-journey travel ticket buying schemes exist, two display areas can be included in the search result page, so that each group of multi-journey travel ticket buying schemes are respectively displayed in the corresponding display areas, and a user can synchronously or independently slide and turn pages in different display areas.

For another example, the client may display the at least two sets of multi-travel ticketing schemes by searching at least two tab pages included in the results page. For example, in the search results page 50 shown in fig. 5, a set of multi-travel ticketing schemes corresponding to the travel route "hangzhou→ Chiang Mai →singapore" is shown on the left Tab page, and a set of multi-travel ticketing schemes corresponding to the travel route "hangzhou→singapore→ Chiang Mai" is shown on the right Tab page, of course, only the left Tab page is fully shown in fig. 5, and only the Tab Bar (Tab Bar) is shown on the right Tab page. The search results page 50 may obviously also show more tab pages as more travel routes are provided.

For ease of distinction and viewing, the Tab Title (Tab Title) shown at the Tab column of each Tab page may contain at least one of descriptive information of the travel route corresponding to the respective set of multi-travel ticketing schemes, an optimal value of the respective set of multi-travel ticketing schemes in a specified dimension. For example, as shown in FIG. 5, in the tab field 51 of the left tab page, the description information of the travel route may include the travel route name "route 1", the travel destination contained in the travel route and its arrangement order "Chiang Mai- > Singapore", of course, the arrangement order between "Chiang Mai" and "Singapore" is specifically characterized in FIG. 5 by three dimensions, 1) placing "Chiang Mai" on the left side of "Singapore" based on the general reading order from left to right, equivalent to placing "Chiang Mai" in front of "Singapore", 2) between "Chiang Mai" and "Singapore", an arrow mark from "Chiang Mai" to "Singapore" is added, and 3) a mark containing "first" is added for "Chiang Mai" and a mark containing "later" for "Singapore". And the label column 51 contains an optimal value in a designated dimension, the designated dimension may be specifically a ticket purchase price, and the optimal value in the ticket purchase price refers to a multi-travel ticket purchase scheme with the lowest price in a group of multi-travel ticket purchase schemes corresponding to the travel route of "Hangzhou- > Chiang Mai- > Singapore", such as the optimal value shown in FIG. 5 is ", 1889". Of course, the contents specifically shown in the tag field 51 in FIG. 5 are "N1889", and it is indicated by "N1" that in addition to the multi-travel ticketing scheme with the ticket purchase price of "1889, there are alternative multi-travel ticketing schemes on the travel route, except that the ticket purchase price is relatively higher. Of course, with respect to the specified dimensions described above, in addition to ticket prices, any dimension that can represent a predominance difference between different multi-trip ticket buying schemes can be included, and one or more dimensions can be included simultaneously. For example, the designated dimension may include at least one of ticket purchase price, number of turns, turn duration, in-transit duration, departure period, arrival period, etc., which is not limited by the present description.

The departure period may indicate a time interval in which the departure time is located. Of course, if the starting time and the ending time of the time interval coincide, the departure period may be the departure time itself, as a special case. Some departure periods are more attractive to the user, such as those that are neither too early nor too late to require the user to be late to stay up to night. The merits of the departure period can be defined based on the normal work and rest law, for example, 24 hours of the whole day can be divided into 3 departure periods from 0 to 6, from 8 to 22 and from 22 to 24, and the departure period from 8 to 22 is defined to be relatively better, and the other 2 departure periods are defined to be relatively worse. For the relatively more preferable 8 points to 22 points, it is further possible to divide the time period into a plurality of more detailed departure time periods and define the relative merits, and the other 2 relatively worse departure time periods are similar, which are not listed here. The arrival time period, similar to the above description of the departure time period, may be divided into different arrival times and define corresponding advantages and disadvantages, which are not described herein.

Similarly, in the tab field 52 of the right tab page, the same type of information as the tab field 51 may be shown, and will not be described in detail here.

The client may use any manner such as text, graphics, etc. when displaying the multi-journey ticket purchasing scheme, which is not limited in this specification. For example, each received set of multi-travel ticketing schemes may be displayed separately by displaying the corresponding set of multi-travel ticketing schemes in text form in a text display area within a search results page, displaying a map in a graphical display area within the search results page, and labeling selected multi-travel ticketing schemes within the text display area in the map. Through the coordinated display of the characters and the graphics, a user can read the detailed content of the corresponding multi-travel ticket buying scheme from the characters, and can acquire more visual scheme presentation through the graphics, so that the user can better know the corresponding multi-travel ticket buying scheme.

For example, the above display manner based on the tab pages may be used as the text display area and the graphics display area respectively located in each tab page, and the form of the tab pages is not essential. For example, in the search result page 50 shown in fig. 5, a tab page corresponding to the tab field 51 is shown, and the tab page includes a graphic display area 511 and a text display area 512. In the text display area 512, various multi-travel ticket purchasing schemes described in text form are sequentially arranged from top to bottom, for example, in the uppermost multi-travel ticket purchasing scheme, the multi-travel ticket purchasing scheme is shown as '09.01 to 09.07 for 7 days, which indicates that from the departure date of Hangzhou is 09.01, the return date of return Hangzhou is 09.07, the total travel time is 7 days', 1889 'which indicates the ticket purchasing price of the multi-travel ticket purchasing scheme, the travel ticket-receiving scheme is' Hangzhou-Chiang Mai:50-20:25 for 2h10m ', the departure time of the first travel section is Hangzhou, the destination is Chiang Mai, the departure time of the corresponding flight is 14:50, 20:25, the corresponding flight is Kunming, the transit time is 2 hours and 10 minutes, the travel time of return Hangzhou is' Chiang Mai-Singapped 11:15-15:20, the travel time of second travel section is Chiang Mai, the travel time of the destination is Singapped, the corresponding travel time of take-15:15:15, the corresponding to 03:08, the straight travel time of the Singapore is 3:03, the corresponding travel time of the Singapore, and the corresponding travel time of the Singapore is 03:15:03. Other multi-trip ticketing schemes are similar and are not listed here.

Within the graphic presentation area 511, the background graphic may be a map (not specifically shown in the figure). When a multi-travel ticketing plan in the text display area 512 is selected, for example, the selected multi-travel ticketing plan in fig. 5 is the multi-travel ticketing plan arranged at the top as described above in detail, the selected multi-travel ticketing plan can be marked on the map in the graphic display area 511.

When marking the selected multi-journey ticket purchasing scheme on the map, each journey section related to the selected multi-journey ticket purchasing scheme can be marked in the map in the form of a directed line, the end point of the directed line is a departure city and an arrival city of the corresponding journey section, the direction points to the arrival city from the departure city, and corresponding journey description information is shown for each directed line, wherein the journey description information comprises one or more of journey sequence, departure date, arrival date, transit times, journey time consumption, playing duration and the like, and the description is not limited to the specific journey description information. For example, as shown in fig. 5, for the three travel segments as described above, the corresponding directional lines may be respectively shown, specifically may include a line segment with a Hangzhou as a starting endpoint and Chiang Mai as a ending endpoint, and an arrow pointing from Hangzhou to Chiang Mai is marked on the line segment, and since the transfer in Hangzhou is involved, the line segment is specifically further divided into two segments from Hangzhou to HangMin and from HangMin to Chiang Mai. Similarly, the directed line also comprises a line segment taking Chiang Mai as a starting end point and taking singapore as a ending end point, and an arrow pointing from Chiang Mai to singapore is marked on the line segment, and a line segment taking singapore as a starting end point and Hangzhou as a ending end point, and an arrow pointing from singapore to Hangzhou is marked on the line segment. And, corresponding to the first leg of the Hangzhou to Chiang Mai, FIG. 5 shows a rounded rectangle at the corresponding directional line containing the travel description information for that leg, specifically including the identification of the "first" word in "Chiang Mai" and its front, indicating that the travel order is "first", the "09.01 thursday" indicating the departure date, the "1 turn" indicating the number of turns, and the "total 7h" indicating that the travel takes 7 hours. Of course, as previously described, the trip description information may also include other items, such as an arrival date may be indicated by "09.01 tuesday", a length of play may be noted at the corresponding end point of the travel destination (e.g., "4 days of play" noted at "Chiang Mai), etc., although not all are shown in the fig. 5 embodiment. Similar travel descriptions are also shown in fig. 5 for other travel segments, which are not listed here.

As previously described, for each set of multi-travel ticketing schemes, the client may only present at least one multi-travel ticketing scheme that is relatively more advantageous in a specified dimension within the set. For example, as shown in fig. 5, for a designated dimension of ticket prices, a multi-leg travel ticket purchase scheme with the lowest ticket price among the set of multi-leg travel ticket purchase schemes, such as the multi-leg travel ticket purchase scheme arranged uppermost in the text display area 512, may be shown. Further, in order to enable the customer to clearly know the designated dimension corresponding to the multi-travel ticket buying scheme, the advantage information of the illustrated multi-travel ticket buying scheme in the corresponding designated dimension can be marked. For example, for the multi-journey ticketing scheme described above with the uppermost arranged in text display area 512, the "lowest price" label is shown in FIG. 5 to indicate its dominance information in the designated dimension of ticketing price.

Of course, with respect to the specified dimensions described above, in addition to ticket prices, any dimension that can represent a predominance difference between different multi-trip ticket buying schemes can be included, and one or more dimensions can be included simultaneously. For example, the specified dimension includes at least one of ticket purchase price, number of times of transit, duration of transit, departure period, arrival period, etc., which is not limited by the present specification. Still illustrated in connection with fig. 5 is a second multi-pass ticketing scheme arranged in text display area 512 that has the lowest price among all multi-pass ticketing schemes with 1 transit times, corresponding to a more advantageous in the specified dimension of the combination of ticketing price and transit times, for which the label shown is "low price and transit fast", and a third multi-pass ticketing scheme (only part of which is shown) arranged in text display area 512 that has the advantage in the specified dimension of the duration in transit (i.e., the duration the user spends in the riding vehicle), i.e., the duration in transit is relatively shortest, for which the label shown is "fastest".

As described above, if the search request includes the travel time length description information, and the travel time length description information is used to describe the total travel time length, there are a plurality of division schemes divided into at least two travel destinations in the search request, and each group of the multi-travel ticket-buying schemes includes the multi-travel ticket-buying schemes respectively corresponding to the respective division schemes. Correspondingly, a corresponding individual play duration setting control can be displayed for at least one travel destination for setting the individual play duration of the corresponding travel destination, the play duration alternatives are displayed in response to the triggering of the individual play duration setting control corresponding to any travel destination, and the multi-way travel ticket buying schemes of the corresponding group are screened and displayed according to the selected play duration alternatives. In this manner, the user may filter based on individual play durations to view the multi-travel ticketing schemes in which he is interested. For example, as shown in fig. 5, in text display area 512, a separate play duration setting control shown as "Chiang Mai stay days" and a separate play duration setting control shown as "singapore stay days" may be included for setting Chiang Mai and singapore corresponding separate play durations, respectively. The user can set the individual playing time length of part (one or more) of the travel destinations, can set the individual playing time length of all the travel destinations, and the client can screen and display the multi-travel ticket buying schemes meeting the requirements.

It should be noted that, in describing the search result page 50, the tab page corresponding to "line 1" is mainly described in connection with fig. 5. If the user is interested in "line 2", the tab bar 52 may be triggered to switch to the tab page corresponding to "line 2", for example, refer to fig. 6. In fig. 6, a graphic display area 521 and a text display area 522 may be specifically included. Regarding the graphic display area 521, reference may be made to the description previously associated with the graphic display area 511, and regarding the text display area 522, reference may be made to the description previously associated with the text display area 512, which is not repeated here.

In the search results page 50 shown in fig. 5-6, the bottom of the page is presented with a "reservation ticket" control. After selecting a certain interesting multi-journey travel ticket buying scheme, a user can check and buy the ticket related to the corresponding multi-journey travel ticket buying scheme by triggering a preset ticket booking control. The travel service platform can assist the user to purchase a plurality of air tickets related to the corresponding multi-travel ticket purchasing scheme together without the need of the user to purchase each air ticket independently, so that the operation of the user is simplified, and the convenience of purchasing the air tickets is improved.

FIG. 7 is a flowchart of a method for generating a multi-pass travel ticketing scheme, which is applied to a server side of a travel service platform, according to an exemplary embodiment. As shown in fig. 7, the method may include the steps of:

Step 702, receiving a search request of a multi-travel ticket buying scheme initiated by a client of the travel service platform, wherein the search request at least comprises a departure place and at least two travel destinations;

step 704, generating at least two groups of multi-travel ticket buying schemes, wherein each group of multi-travel ticket buying schemes corresponds to one 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;

And step 706, returning the generated multi-travel ticket buying scheme to the client side for the client side to display at least a part of the generated multi-travel ticket buying scheme.

It should be noted that, in the foregoing embodiments described in connection with the drawings of fig. 2, the technical solution of the present disclosure is described from the perspective of the client side, while fig. 7 describes the same technical solution from the perspective of the server side, that is, the two are identical in overall design, but have some differences in the described aspects, so all the contents described in the embodiments of the client side are practically applicable to the embodiments of the server side shown in fig. 7. Therefore, in understanding the embodiment shown in fig. 7, reference may be made to the foregoing embodiment on the client side, and a detailed description is omitted here.

In summary, in the scenario of multi-travel, the service end of the travel service platform can provide corresponding multi-travel ticket purchasing schemes for various travel routes between the departure place and each travel destination, so that the user can check each group of multi-travel ticket purchasing schemes through the client end of the travel service platform only by executing a query operation to inform the departure place and each travel destination, thereby facilitating comparison and purchase of the user, greatly simplifying user operation, reducing time consumption for querying and purchasing tickets, and being beneficial to the user to determine the most suitable multi-travel ticket purchasing scheme.

Fig. 8 is a schematic block diagram of an apparatus according to an exemplary embodiment. Referring to fig. 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 storage 810, although other hardware required for other functions may be included. One or more embodiments of the present description may be implemented in a software-based manner, such as by the processor 802 reading a corresponding computer program from the non-volatile memory 810 into the memory 808 and then running. Of course, in addition to software implementation, one or more embodiments of the present disclosure do not exclude other implementation manners, such as a logic device 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 may also be hardware or a logic device.

Referring to fig. 9, a display device for a multi-journey ticket purchasing scheme may be applied to the apparatus shown in fig. 8, specifically, to a client of a travel service platform, so as to implement the technical scheme of the present disclosure. The apparatus may include:

A request initiating unit 901, configured to initiate a search request of a multi-travel ticket purchasing scheme to a service end of the travel service platform, where the search request at least includes a departure place and at least two travel destinations;

a scenario receiving unit 902, configured to receive at least two sets of multi-travel ticketing scenarios returned by the server, where each set of multi-travel ticketing scenarios corresponds to a travel route formed by the departure place and the at least two travel destinations, and an arrangement order of the at least two travel destinations in different travel routes is different;

the scenario display unit 903 displays at least a part of the received multi-journey ticket buying scenario.

Optionally, the scheme display unit 903 is specifically configured to:

Respectively displaying at least two groups of multipass travel ticket buying schemes through at least two tag pages contained in the search result page;

the label title shown in the label column of each label page comprises at least one of the descriptive information of the travel route corresponding to the corresponding group of multi-travel ticket buying schemes and the optimal value of the corresponding group of multi-travel ticket buying schemes in the appointed dimension;

the specified dimension comprises at least one of ticket purchase price, transfer times, transfer time length, in-transit time length, departure time period and arrival time period.

Optionally, the scheme display unit 903 displays each received multi-trip ticket purchase scheme in the following manner:

In a text display area in the search result page, arranging and displaying the corresponding group of multi-travel ticket buying schemes in text form;

And displaying a map in a graphic display area in the search result page, and marking the selected multi-journey travel ticket purchasing scheme in the text display area in the map.

Optionally, the marking the selected multipass travel ticket purchasing scheme in the text display area in the map includes:

Marking each travel section related to the selected multi-travel ticket purchasing scheme in a map in the form of a directed line, wherein the end point of the directed line is a departure city and an arrival city of the corresponding travel section, and the direction points to the arrival city from the departure city;

And (5) corresponding travel description information is shown for each directed line, wherein the travel description information comprises one or more of travel sequence, departure date, arrival date, number of times of transfer, travel time consumption and play duration.

Optionally, the scheme display unit 903 is specifically configured to:

For each group of multi-journey ticket buying schemes, only at least one multi-journey ticket buying scheme which is relatively more advantageous in a specified dimension in the group is displayed, wherein the specified dimension comprises at least one of ticket buying price, transit times, transit time length, departure time period and arrival time period;

or for each set of multi-travel ticketing schemes, only at least one multi-travel ticketing scheme that is relatively more advantageous in a specified dimension within the set is displayed, and the illustrated multi-travel ticketing scheme is annotated with dominance information in the corresponding specified dimension.

Optionally, the search request also comprises a return ground;

Each multi-trip ticketing scheme includes a one-trip ticketing scheme from the departure point to a first travel destination in the corresponding travel route, a one-trip ticketing scheme between the respective travel destinations in the corresponding travel route, and a one-trip ticketing scheme from a last travel destination in the corresponding travel route to the return point.

Optionally, the search request also comprises departure date description information and play duration description information;

The departure date description information is used for describing the accurate date of departure from the departure place or the future time period where the departure date is located;

the travel duration description information is used to describe a total duration of travel at the at least two travel destinations or a separate duration of travel at each travel destination.

Optionally, in the case that the play duration description information is used to describe the play total duration, there are multiple dividing schemes for dividing the play total duration into at least two travel destinations, and each group of multi-travel ticket buying schemes includes a multi-travel ticket buying scheme corresponding to each dividing scheme, where the apparatus further includes:

a control display unit for displaying, for at least one travel destination, a corresponding individual play duration setting control for setting individual play durations at the corresponding travel destination;

the alternative display unit is used for displaying the play duration alternative in response to the fact that the independent play duration setting control corresponding to any travel destination is triggered;

and the screening unit screens and displays the multipass travel ticket buying schemes of the corresponding groups according to the selected play duration alternatives.

Referring to fig. 10, the generating device for a multi-journey ticket buying scheme may be applied to the apparatus shown in fig. 8, specifically, the service end of the travel service platform, so as to implement the technical scheme of the present disclosure. The apparatus may include:

a request receiving unit 1001, configured to receive a search request of a multi-travel ticket purchasing scheme initiated by a client of the travel service platform, where the search request includes at least a departure place and at least two travel destinations;

A scenario generation unit 1002 that generates at least two sets of multipass travel ticket buying scenarios, each set of multipass travel ticket buying scenarios corresponding to one 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 being different;

and the scheme returning unit 1003 returns the generated multi-journey ticket buying scheme to the client side so as to enable the client side to display at least one part of the generated multi-journey ticket buying scheme.

Based on the same conception as the above method, the present specification also provides an electronic device comprising a processor, a memory for storing executable instructions of the processor, wherein the processor implements the steps of the method according to any of the embodiments described above by executing the executable instructions.

Based on the same conception as the above method, the present specification also provides a computer readable storage medium having stored thereon computer instructions which when executed by a processor perform the steps of the method according to any of the above embodiments.

Based on the same conception as the above method, the present specification also provides a computer program product comprising a computer program/instruction which, when executed by a processor, implements the steps of the method according to any of the embodiments described above.

Claims

1. The display method of the multi-journey travel ticket buying scheme is characterized by being applied to a client side of a travel service platform and comprising the following steps of:

2. The method of claim 1, wherein the presenting the received at least a portion of the multi-trip ticketing scheme comprises:

3. The method of claim 1, wherein each received set of multi-travel ticketing schemes is separately presented by:

4. The method of claim 3, wherein marking the selected multi-trip ticketing scheme in the text display area in the map comprises:

5. The method of claim 1, wherein the presenting the received at least a portion of the multi-trip ticketing scheme comprises:

6. The method of claim 1, wherein the step of determining the position of the substrate comprises,

The search request also includes a return ground;

7. The method of claim 1, wherein the step of determining the position of the substrate comprises,

The search request also comprises departure date description information and play duration description information;

8. The method of claim 7, wherein in the case where the travel duration description information is used to describe the total travel duration, there are a plurality of division schemes for the total travel duration that are divided into the at least two travel destinations, each set of multi-travel ticketing schemes including multi-travel ticketing schemes respectively corresponding to the respective division schemes, the method further comprising:

presenting, for at least one travel destination, a respective individual travel duration setting control for setting individual travel durations at the respective travel destination;

Responsive to a separate play duration setting control corresponding to any travel destination being triggered, displaying a play duration alternative;

And screening and displaying the multi-journey travel ticket buying schemes of the corresponding groups according to the selected play duration alternatives.

9. The method for generating the multipass travel ticket buying scheme is characterized by being applied to a service end of a travel service platform and comprising the following steps:

10. A computer program product comprising computer programs/instructions which, when executed by a processor, implement the steps of the method according to any of claims 1-9.