Patent Application
20060053054
A portion of the disclosure of this patent document contains material, which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Independent travel service sellers (e.g., Orbitz, Inc., Expedia, Inc.) are travel service sellers that are not related to only one travel service provider. Since they are not related to only one travel service provider, they can generate travel options from many different travel service providers, giving a customer a broader selection of choices. Travel options include itineraries (e.g., a sequence of one or more legs of travel (e.g., flights)) for which a fare can be generated. Independent travel service sellers generally, use automated systems, accessible over the Internet, to determine travel options by applying fares to scheduling information such as flights, routes, itineraries and so forth. Application of fares to scheduling information involves use of certain rules. These rules are used to determine, for example whether a fare can be used for a particular passenger itinerary. One example of such rules in the airline industry are those published by the Airline Tariff Publishing Company (ATPCO). To accommodate automated systems, ATPCO developed data structures for use with such automated systems to determine applicability of fares to schedule information using the rules. ATPCO defines these data structures so that travel providers (e.g., airlines) can define their rules for their fares using predefined fields and values of the ATPCO data structures.
To compete for business and to try to retain travelers, travel providers (e.g., airlines, bus companies, rail companies) have developed frequent traveler programs where the traveler receives some award credit (e.g., miles) for travel with a particular travel provider. These frequent travel programs allow the traveler to redeem this award credit for free tickets, upgrades, and other services. In some cases, travel providers have partnered with one or more other travel providers to increase the benefits of the frequent traveler programs by allowing both award credit and/or redemption to be given by the partners. Typically, to redeem the award credit that a traveler has accumulated, the traveler calls a customer service representative of the travel provider. Internet travel service sellers do not automatically calculate travel availability for redemption of accumulated award credit in frequent traveler programs.
1. According to an aspect of the invention, a method executed in a computer system, includes receiving a query including an indicator of a use of a frequent travel award; and retrieving rules from a data base, the rules for a frequent travel award redemption program, the frequent travel award redemption program being encoded using predefined data structures based on fare by rule data structures defined by a third party fare by rule provider. The method also includes automatically determining a travel itinerary based on the query and the rules encoded using the predefined data structures.
According to an additional aspect of the invention a system includes a computing device adapted to receive a query including an indicator of a use of a frequent travel award. The computing device is adapted to retrieve rules for a frequent travel award redemption program. The frequent travel award redemption program is encoded using predefined data structures based on fare by rule data structures defined by a third party fare by rule provider. The system automatically determines a travel itinerary based on the query and the rules encoded using the predefined data structures.
According to an additional aspect of the invention, a computer program product, is tangibly embodied in an information carrier. The computer program product includes instructions that are operable to cause data processing apparatus to receive a query including an indicator of a use of a frequent travel award and retrieve rules for a frequent travel award redemption program. The frequent travel award redemption program is encoded using predefined data structures based on fare by rule data structures defined by a third party fare by rule provider. The program automatically determines a travel itinerary based on the query and the rules encoded using the predefined data structures.
Implementations can include one or more of the following features. The third party fare by rule provider comprises the Airline Tariff Publishing Company (ATPCO) or SITA. The predefined data structures include a field and value based on an account code matching the indicator in the query. The indicator is a frequent traveler passenger type code identified in the query that maps to a generic frequent traveler passenger type code. The mapping is used when matching Record 8 and Record 2 passenger type code data structures. A Record 8 ATPCO data structure is initially search and the search bypasses published fares. The predefined data structures include a carrier code in a record 8 ATPCO data structure that represents a carrier that owns the frequent travel award redemption program. The predefined data structures comprise an ATPCO Record 8 joint carrier table 997 data structure that can be used to represent carriers providing transportation for the frequent travel award redemption program. Automatically determining uses the carrier code of the carrier in the Record 8 ATPCO data structure, and all partner carriers as potential carriers providing transportation for the frequent travel award redemption program if an ATPCO record 8 joint carrier table 997 data structure is not included in the retrieved rules. The frequent travel award redemption program can include an award credit redemption program, an award credit plus co-pay redemption program, an award credit plus percent off redemption program, an award credit plus dollar off redemption program, or an award credit with companion redemption program.
One or more of the following advantages may be provided by one or more aspects of the invention.
The frequent traveler award redemption process can accommodate Frequent Flyer travel awards via the carrier owning the Frequent Flyer program as well as via partner carriers participating in the program including Straight Mileage Redemption Awards, Mileage plus Co-pay Redemption Awards, Mileage plus percent or dollar off awards, Mileage Purchase Options, Mileage Awards for Frequent Flyer and Companion programs.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Further features, aspects, and advantages of the invention will become apparent from the description, the drawings, and the claims.
Referring to
As described in more detail below, the frequent traveler award redemption process 120 uses the data in the query, along with data corresponding to one or more rules of a carrier's frequent traveler program to determine what travel arrangements are possible. The rules include the requirements and the restrictions of the program, as established by an owning carrier. For example, the rules can include geographic limitations of the program, distance restrictions, other participating carriers, scheduling restrictions, distance restrictions, and the like. The rules also include fare data so that process 120 can read and compare with query data to determine whether there are any matches, as described in more detail below, and determine the awards (also referred to as fares) of those matching travel options. The rules are defined using predefined data structures. The frequent traveler award redemption process 120 can obtain the rules from its storage module 130 and/or from a third party's database stored on a storage module 140, which is in communication with the network 115 through a server 145.
When the frequent traveler award redemption process 120 determines what travel arrangements are possible, the frequent traveler award redemption process 120 sends this information to the client 105 to be displayed to the user in various formats, examples of which are described in more detail below.
For determining possible travel arrangements, server 110 includes a plurality of server processes 150. The plurality of server processes 150 includes a scheduler process 155 and faring processes 160. The scheduler process 155 is any suitable scheduler process that produces/generates, from a travel request, sets of flights that can satisfy the request. The faring process 160 is a process that determines a set of valid fares and links the set of valid fares to the sets of flights to form a pricing solution. The faring process 160 includes the frequent travel award redemption process described above, determines fares for possible travel arrangements in terms of redemption of earned travel award credit (e.g., frequent flyer miles) in exchange for free or reduced cost travel and can also include a convention faring process 162. The plurality of server processes 150 can be configured to produce other travel-related information as a result of a user query. For example, the plurality of server processes 150 can produce routes or airline suggestions, optimal travel times and suggestions for alternative requests.
The travel planning system 100 also includes a plurality of databases 165 and 170, which store industry-standard information pertaining to travel (e.g., airline, bus, railroad, etc.). For example, database 165 can store the Airline Tariff Publishing Company database of published airline fares and their associated rules, routings and other provisions, the so-called ATPCO database. As another example, database 165 can store the SITA AIRFARE (SITA Inc. Geneva Switzerland) database, which also contains fare information. Other databases that represent faring information in data structures can be used. Database 170 can be an inventory of current availability of airline information for a particular carrier and so forth. The databases 165 and 170 can be stored locally and updated periodically by accessing remote resources, such as 140 and 145 that maintain the respective databases.
The client 105 can be a smart client. That is, client 105 can include a client computer system that has a computer memory or storage media 175 that stores a client process 180 and a set of pricing solutions 185. The set of pricing solutions 185 in one embodiment is provided from the server process 150 and comprises a set of fares, typically represented as earned award credit (e.g., frequent flyer miles), that are valid for a journey, and associated information linking the fares to the flight segments of the journey. Although the fares are typically represented as earned award credit, the fares can also include a monetary component (e.g., represented as currency, such as U.S. dollars). As explained in more detail below, the monetary component can be required as a “co-payment” with the award credit, or can be used to purchase a portion of the needed award credit (e.g., money needed to purchase 5,000 miles for a 15,000 mile award redemption).
The set of pricing solutions 185 is obtained from the server 110 in response to a user request sent from the client 105 to the server 110. The server 110 executes the plurality of server processes 150, using the scheduling process 155 and the faring process 160 to produce a set of pricing solutions for a particular journey. Under control of the client process 180, the requesting client 105 can store and/or logically manipulate the set of pricing solutions 185 to extract or display a subset of the set of pricing solutions 185 as a display representation 190 (e.g., a graphical user interface (GUI)) on a client display 195. The server processes 150 are preferably executed on the server computer 110, but can be executed on the client computer 105.
Referring now to
In one implementation, this query 205 is fed to the scheduler process 155 that produces a large number of itineraries, that is, sequences of flight segments between the origin and destination for each slice of a journey. Examples of scheduler systems that may be used include the OAG Flight Desk (Official Airlines Guide, a division of Reed Travel Group) or schedule components of computer reservation systems (CRS's) such as Sabre®, Apollo®, Amadeus® and WorldSpan®. It is preferable in order to obtain the largest number of possible itineraries to use a scheduler with dynamic connection generation. Such a scheduler is described in U.S. patent number, entitled SCHEDULER SYSTEM FOR TRAVEL PLANNING SYSTEM, Ser. No. 09/109,622, filed on Jul. 2, 1998 by Carl G. de Marcken et al., pending and assigned to the assignee of the invention and incorporated herein by reference.
The scheduler process 155 provides the itineraries to one a faring process component 120 or a faring process component 162 of the faring processes 160. To determine which faring process is used, the server processes 150 determines 210 whether there is a frequent award indicator. As described in more detail below, the server processes 150 can use, for example, an account code value to determine whether the query is associated with a frequent award program.
If there is no indication that the query relates to a frequent award program, then server 110 executes 215 a faring process 162 for determination of traditional, monetary-based fares. The faring process 162 provides a set of pricing solutions 220 by finding valid fares corresponding to the itineraries produced by the scheduler process 155. The faring process 215 validates the fares for inclusion in the set of pricing solutions 220. In general overview, the faring process 215 includes three processes 225, 230, and 235. The process 225 searches for published fares. The process 230 searches for discounts. The process 235 searches for further calculations and/or adjustments to fares using rules, such as the fare by rule process using the ATPCO database or SITA AIRFARE (e.g., database 165) described above. Such a faring process 215 is described in more detail in U.S. Pat. No. 6,295,521, entitled TRAVEL PLANNING SYSTEM, Ser. No. 09/109,327, filed on Jul. 2, 1998 by Carl G. de Marcken et al., assigned to the assignee of the invention and incorporated herein by reference. Other examples of faring processes could be used for the fare by rule faring process 162.
However, if there is an indication that the query relates to a frequent award program, then server 110 executes 227 the faring process 160, which includes process 120 for determination of fares based on award credit while bypassing process 225 and 230, and incorporating certain elements of process 235 Fare By Rule. The faring process 160 provides a set of pricing solutions 185 by finding valid fares corresponding to the itineraries produced by the scheduler process 155 using a set of encoded rules, as described in more detail below.
The set of pricing solutions (e.g., 185 or 220) is used by an availability process 240 that interrogates an airline inventory database (e.g., 170), to determine whether there are seats available on particular flights for particular pricing solutions. The availability process 240 uses the airline inventory database as a filter to remove from the set of pricing solutions those pricing solutions for which there are not available seats. The availability process 240 is shown after the faring process (e.g., 160 or 215). However, availability process 240 can be included at nearly any point in the process illustrated in
The client system 105 receives the results from one or more of the server processes 150 (e.g., 155, 160, 215, and/or 240). These results can be used to form the set of pricing solutions 185 and/or pricing solutions based upon availability. The client process 180 executed in the client 105 uses this information or a subset of it to access a booking process 245 to provide booking and a reservation for a user-selected travel option included in the pricing solutions 185. For example, the client system 105 can receive data from process 155 and process 160 and combine them to generate the pricing solution 185, or the client 105 can receive the pricing solution 185 from the faring process 160, or the client 105 can receive the pricing solution 185 after the availability process 240.
The client process 180 (
Referring now to
In one example, the client process 180 receives the flight information from scheduler process 155 and the pricing solution from the faring process 160 or the availability system 240 and enumerates 305 pricing solutions from the directed acyclic graph (DAG) representation 185. The enumerated set (e.g., from process 305) of pricing solutions is rendered or displayed 315 in a graphical user interface 190 on the client monitor 195 (
In response to user input 320, the client 105 can manipulate 310 travel options and can query the local copy of the DAG to produce and display a subset of pricing solutions enumerated from the DAG that satisfy the query 320. An example manipulation process used to control the display and change the travel options displayed will be described below.
In this example, a directed acyclic graph (DAG) is used to represent the compact set of pricing solutions 185′ since, in general, the number of nodes needed to represent a typical pricing solution will be substantially less than the actual number of pricing solutions represented by the DAG. This significantly increases the efficiency of transfer of a set of pricing solutions 185 from one of the server processes 150 to the client process 180. The DAG representation also minimizes the storage requirements for the set of pricing solutions 185. The DAG representation permits the use of powerful search, sorting, and manipulation processes to produce various pricing solutions in an efficient manner. As used herein, a directed acyclic graph (DAG) is a set of nodes connected by directed arcs that have no loops of arcs in the same direction. If a node A is connected to a node B via an arc A-B, then A is called a parent of B, and B is called a child of A. Each node may have zero, one or many parents and zero, one or many children. As used herein, a pricing solution that is represented by a graph will be referred to as a pricing graph. Such a pricing graph is described in more detail in U.S. Pat. No. 6,295,521, entitled TRAVEL PLANNING SYSTEM, Ser. No. 09/109,327, filed on Jul. 2, 1998 by Carl G. de Marcken et al., assigned to the assignee of the invention and incorporated herein by reference. When the pricing solution 185 is generated using faring process 160, the fares represented in the pricing graph includes earned travel credit requirements, as determined as described in more detail below.
The modified ATPCO data structures used in frequent traveler award redemption process 120 include:
As described in connection with
Using this query, frequent traveler award redemption process 120 determines (210) whether there is a frequent award program indicator. For example, using the data in Table 1, frequent traveler award redemption process 120 uses the account code value to determine whether the query is associated with a frequent award program. If the value “FFYAR” does not indicate a frequent award program, the server 110 employs another process to determine fares by rule (e.g., process 215), instead of the frequent travel award redemption process 120. If the value “FFYAR” does indicate a frequent award program, the server 110 employs the faring process 160 to determine the travel options and fares (in terms of earned award credit) available under the program.
Referring to
One example match is shown below in Table 2. The match is to an example rule that can be added to hold coach awards. It should be noted that Table 2 does not include all of the fields in an ATPCO Record 8, but in general only those fields that have been modified to accommodate a frequent traveler redemption award by rule for this example. A more complete ATPCO Record 8 is described later.
With the above information, frequent traveler award redemption process 120 can determine that there is a frequent flyer award redemption that the passenger may qualify for, using a process similar to the ATPCO fare by rule process. In the Record 8 data structure, the CXR code field identifies the carrier to which the record applies. This refers to the carrier filing a particular frequent flyer award redemption program. The carrier code here matches to the sales carrier/address identified in the incoming query example in Table 1 (AS). The prime passenger type code identifies the passenger type, such as FFY, a frequent flyer passenger. Other types might be defined according to different service levels associated with a program, such as those for silver, gold, and platinum type passengers.
The qualifying account code field lists the account to identify that the query is for a frequent travel award redemption. The tariff number field and the rule number field are used to match with Record 2s, as described below. The joint carrier table 997 is used to list carriers that participate in this travel award program. If there is not a joint carrier table for a particular Record 8, the frequent traveler award redemption process 120 can default to the sales carrier AS. The location fields of the geographic scope indicate the geographic boundaries of the frequent travel award program represented by that Record 8. The loc 1 and loc 2 fields represent the geographic scope of the origination location and the destination location. In the case of the example query data in Table 1, the origination airport in the query is PDX, Portland, Oreg. PDX is part of the contiguous 48 states and therefore is a match to zone 001. Similarly, the destination airport in the query is LAS, Las Vegas, Nev., which is also part of the contiguous 48 states and therefore is a match to zone 001.
Continuing with the frequent traveler award redemption process 120, the frequent traveler award redemption process 120 retrieves (435) matches, e.g., the Record 8s, and determines (435) the special requirements for the associated carriers in the matched Record 8s. To determine if the passenger is eligible (e.g., matches the special requirements), the frequent traveler award redemption process 120 uses the appropriate tariff/carrier/rule information (also referred to as TRF/CXR/RUL) indicated in the Record 8 above, in the tariff number field, the CXR code field, and the rule number field, respectively. Frequent traveler award redemption process 120 compares the tariff/carrier/rule information to ATPCO CATEGORY 25, Record 2s to determine (440) whether there are any matches. If there are no matches, the frequent traveler award redemption process 120 notifies (430) the client 105 that no itineraries matching the query data exist. If there are one or more matches, the frequent traveler award redemption process 120 retrieves (445) the matches.
One example match of a Category 25, Record 2 is shown below in Table 3. It should be noted that Table 3 does not include all of the fields in an ATPCO Category 25, Record 2, but in general only those fields that have been modified to accommodate a frequent traveler redemption award by rule for this example. A more complete ATPCO Category 25, Record 2 is described later.
In Table 3, the rule tariff field, the carrier code field, and the rule number field are the matching values to the tariff number field, the carrier code field, and the rule number field in the Record 8. The sequence number determines the order in which matching the Record 2 is attempted. The loc 1 type and loc 2 type indicate the type of geographic specification (e.g., area, zone, country, state, or city). In Table 3, the location types are zones. The loc 1 geo spec field and the loc 2 geo spec field indicate the specific geographic limitations. In Table 3, the query data falls within the geographic limitation of zone 1, the 48 contiguous states. The JT CXR table 997 points to the table that includes a listing of all of the partner carriers. The effective date lists the first date on which the Record 2 is effective. The discontinue date lists the last date on which the Record 2 is effective. The relational indicator field indicates the relationship between multiple Record 3 tables. If only one Record 3 table exists, the Relational Indicator is “THEN.” However, often there will be separate Record 3 tables, each pertaining to a particular award code. In such cases, the additional Record 3 tables will be strung together with an “OR” Relational Indicator. On occasion, an award covered in a particular Record 3 Table is conditional upon criteria in another category. The Record 3 for the other category is preceded by a Relational Indicator of “IF”. Often such strings of Record 3 tables end with an “ELSE” Relational Indicator signifying the end of the string and containing conditions for all other matching data.
The cat no field indicates the category number of the data structure, in this case category 25.
The Record 3 table no field identifies any Record 3 tables that match (455) the detail requirements for a particular carrier for a particular frequent travel award program within the Record 2 sequence. Table 4 provides an example Record 3 table. Table 4 does not include all of the fields in an ATPCO Category 25, Record 3, but in general only those fields that have been modified to accommodate a frequent traveler redemption award by rule for this example. A more complete ATPCO Category 25, Record 3 is described later.
In Table 4, the table no field identifies the table number of the Record 3 table and is a matching value to Record 3 table no field in the Category 25, Record 2 data structure (e.g., Table 3). The passenger type field identifies the passenger type code for which this Record 3 table is applicable. The passenger type FFY matches the passenger type in the submitted query (e.g., Table 1). The number of flight segments field indicates the maximum number of flight segments per fare component that can be used for the resulting award data. In the Table 4 example, the value is 99, basically representing that there is no real limit on the number of flight segments (e.g., no typical itinerary includes over 99 segments). The fare calculation formula indicator indicates the calculation method for determining the award redemption. For example, a value of “S” can be used to indicate that the reward is specified using the amount of the reward credit needed for a particular itinerary. A value of “A” can be used to indicate that an award redemption formula is used to calculate a discount off of a published fare upon redemption of a specified amount of award credit. For example, 1000 miles might allow a $100 discount off of a published fare.
The specified fare field indicates the award credit that is redeemed for the particular itinerary. The currency field indicates the type of award credit to which the fare field refers to. The decimal field indicates a placement of a decimal in the number in the fare field. In the Table 4 example, the fare value is 20,000, the fare currency 1 is miles (MLG, or other value to be determined) and the decimal location at the zero place in the fare, indicating that no decimal is needed. Using these three values in combination indicates that the fare for this particular award redemption is 20,000 miles. In other examples, a second combination of the three fields is used to indicate needed co-payments for the award redemption. The prime RBD field indicates the reservation booking designator (RBD) for the award.
The frequent traveler award redemption process 120 determines (455) whether there are any other additional constraints, such as blackout periods. If there are no additional constraints, the frequent traveler award redemption process 120 generates (465) matching itineraries and transmits the matching itineraries to the client 105. If there are additional constraints, the frequent traveler award redemption process 120 retrieves (470) the additional constraints. The frequent traveler award redemption process 120 determines (475) whether there are any matches by, for example comparing table values to query data as described above. In addition to the award redemption produced in Category 25, in order to provide for any additional constraints, other categories of modified ATPCO data structures can hold the remaining award conditions. For instance, Category 11—blackouts can hold blackout dates applicable to value awards. Category 5 and 12 (advance reservations and ticketing & surcharges) can provide advance reservation requirements and fees associated with reservations made in less than the allotted time frame.
Table 5 illustrates a general cross reference of frequent flyer award redemption data attributes and where they can be placed in modified ATPCO fare by rule data structures.
If there are no additional constraints, or if there are constraints and the frequent traveler award redemption process 120 determines (475) that there are matches with the additional constraints, the frequent traveler award redemption process 120 generates (465) matching itineraries (for which earned travel credit, and co-pay if applicable, can be redeemed) and transmits the matching itineraries to the client 105.
Referring to
The calendar view in the first region 505 displays a calendar that includes, for example, two months 530 and 535. Days in the calendar include indicators 525 indicating that one or more award redemptions are possible for those days, meaning, for example, that the date of a flight holding a particular award inventory from or to a departure or arrival location falls on that day. The indicator 525 that is displayed can vary. For example, in screenshot 500, the calendar days display the lowest cost (e.g., 25 K, representing a cost of 25,000 miles) for an award redemption possible on that day. Other information can be represented to the user by displaying additional or alternative text, varying the color of the background of that day or of the indicator 525. Other information can also include, for example, a co-payment value, an airline name, a class of seat, a number of stops, capacity controls, and the like. Capacity control information indicates whether the airline has capacity restrictions for the use of the award redemption, such as limited inventory on certain flights, restriction dates, and the like. For example, a red background for a particular day can be used to indicate that capacity-controlled flights are possible for award redemption for that day, along with a blue indicator 525, used to indicate that only one-stop flights are possible for award redemption for that day. As can be seen by the first region 505, the calendar view advantageously enables a user to view in a single display all of the dates award redemption is possible so the user can conveniently find out more details about awards according to dates in which the user has interest. The calendar view also allows the user to view in a single display those dates on which travel has a higher cost (e.g., April 15-18). More detailed description about the use of a calendar view for travel itineraries can be found in U.S. patent application Ser. No. 10/272,521 filed Oct. 16, 2002 entitled “Flexible-Date Travel Queries” by Rodney Daughtrey, et al., assigned to the assignee of the invention, and the contents of which are hereby incorporated by reference.
The indicator 525 can also serve as a hyperlink or control to change the displays in regions 510 and 515. In screenshot 500, indicator 525 serves as a control to change the display of the content in the second region 510 and the third region 515. When a user selects the indicator 525 (e.g., moves a cursor over the indicator 525 and pushes a mouse button), the regions 510 and 515 display the one or more award redemptions (and/or summaries thereof) possible for that particular day (i.e., April 10). This is one way in which the regions 505, 510, and 515 are associated with each other, and through that association, an action in one region can cause changes in one or more of the other regions. After the user selects indicator 525, the user can search through the possible award redemptions using the tabular view in region 510 or a list view in region 515.
The tabular view in region 510 includes a matrix 540 that summarizes one or more award redemptions. As described above, in screenshot 500, the matrix summarizes the possible award redemptions for April 10. The matrix 540 includes three rows and four columns, for a total of twelve cells. Each cell has an indicator that indicates a summary based on one or more criteria. The cells in the first row and the first column indicate each criterion for summarizing the possible awards. The second, third, and fourth columns indicate summaries based on coach class awards, business class awards, and first class awards, respectively. The second and third rows indicate summaries based on number of stops. Cells that intersect two criteria summarize the awards that meet both criteria. For example, cell 545 summarizes awards that meet both first class and one-stop criteria. Cell 550 summarizes all of the awards in matrix 540.
Although the matrix 540 in the second region 510 summarizes the departures for one day, the matrix 540 can summarize the award redemptions for a larger set of award redemptions. For example, the matrix 540 can summarize all awards in the calendar view. Displaying a summary of all of the awards can be a default when the matrix 540 is first displayed. More detailed description about the use of a tabular view for travel itineraries can be found in U.S. patent application Ser. No. 09/431,679, filed on Nov. 1, 1999, assigned to the assignee of the invention and the contents of which are hereby incorporated by reference.
The indicators on each of the cells in matrix 540 can also serve as hyperlinks or controls to change the display in region 515. In screenshot 500, for example, cell 550 includes the indicator “Options for 25,000 miles.” If a user selects this indicator, the list region 515 changes to display all of the awards summarized by matrix 540. This can be a default when the list in region 515 is first displayed. Cell 545 includes the indicator “From 50 K”. If a user selects this indicator, the list region 515 changes to display all of the awards summarized by cell 545, which are one-stop, first class awards. When a user selects this indicator, only row 7 of the list in region 515 is displayed. Similarly, if the user selects the indicator “Business class” in matrix 540, then only the awards, which are business class, are displayed, namely rows 4-6 of the list in region 515.
The list in region 515 displays the details of the individual awards possible. The content displayed in the list can be selected, for example, by a default value and/or by using the calendar view of region 505 or the tabular view of region 510. The user an also manipulate the list view by using hyperlinks or controls directly in the list in region 515. For example, the list can be sorted by any of the headings in the first row of the list. The list in screenshot 500 is sorted by cost. If the user selects the indicator 555, labeled “Flight times”, the list is re-sorted by the flight times. The “Details” indicator 560 enables the user to view more details about the corresponding award.
Referring to
Commonly considered undesirable characteristics of a travel option or set of travel options, such as long-duration layovers, short-duration layovers which increase your risk of missing the connecting flight, overnight flights, non-refundability of tickets, ticket change fees, terminal changes at connection points, and unknown seat availability are rendered in red text in an attempt to indicate a sense of warning or alarm. Other messages that are considered instructive are rendered in other, more calming colors (for example, green) text in an attempt to draw the reader's eye and to impart a helping, assistive tone to the text. Moreover, the color and amount of the text on the screen is an indicator of the general desirability of the travel option; that indication is gained quickly with just a visual scan of the text as a whole.
The examples described above employ ATPCO data structures used in different ways and/or modified ATPCO fields and values. The frequent traveler award redemption process 120 can of course be implemented using non-ATPCO rules rendered into non-ATPCO data structures, i.e., data structures that do not follow or that are not compliant with the ATPCO data structures. These non-ATPCO data structures can be user-defined data structures, examples of which are provided below, and other third-party fare rule information, such as the SITA AIRFARE database, modified in analogous ways to the ATPCO modifications described herein. Use of non-ATPCO data structures allows the addition of other features that are not found in nor can be incorporated in the modified ATPCO data structures. Such non-ATPCO data structures can also allow the elimination of fields in the ATPCO structure that are not needed to determine a frequent traveler award redemption.
Examples of non-ATPCO data structures as discussed below include RFD Fare And Rule Browser by ITASoftware, Inc. This product provides customers with view access to all public fares and rules in a database maintained by e.g., ITA, as well as to the customer's own private fares and rules. These fares and rules are received primarily from ATPCO and therefore follow the ATPCO standard structure of fields and values in an XML compatible format. However, over and above ATPCO data, the RFD Fare And Rule Browser includes additional elements and attributes as extensions to ATPCO fares and rules. Moreover, remote users can have update capabilities of these RFD templates, so that in addition to being able to view existing data on screens containing the values already coded, both new data can be added to skeletal templates and existing data can be revised on the templates holding the values that have already been coded.
The following description describes the use of both modified ATPCO data structures and non-ATPCO data structures in more detail.
Referring to
If there are no record 8 matches (730), process 700 notifies (735) the client 105 that there are no frequent flyer award redemption programs that match the data in the query. If there are matches (730), then to determine if the passenger is eligible, the process 700 proceeds to the Category 25 for the tariff/rule/carrier(s) cross-referenced in the Record 8. Within the fare by rule Category 25, process 700 starts (740) the attempt to match a Record 2 sequence (740). Within the matching Record 2 sequence (740) the search for Category 25 Record 3's (745) that match to the query data takes place. If there are Record 3 tables that match and pass (750), the process 700 can produce validated fares (750) (represented as award credit), based on the matches. Following this, supporting provisions coded in the other ATP categories in the fare by rule are validated 760 (and in a few cases, where an award is based on a percent discount of a published fare, the supporting provisions are contained in a published base fare). As described in more detail below, the fare process for frequent award credit travel redemption follows the same processing as ATPCO fare by rule data structures with certain exceptions that are noted herein. Ultimately, availability is checked (e.g., process 240) against the frequent flyer booking code requirements (e.g., the reservation booking designator “RBD” data) to confirm the inventory set aside for such award(s) is available for booking.
In the sections that follow, more detailed information regarding the processing of the aforementioned Record 8 and the Category 25 Records 2 and 3 is provided.
Table 6 illustrates an example Record 8, and indicates which fields need not be used for the frequent flyer award redemption fare by rule application. In addition, unique frequent flyer values/conventions are noted. Differences between the ATPCO Record 8 and the non-ATPCO data structures are also noted.
Since there are no published fare records associated with the frequent flyer award redemption fare by rule application, there are no Record 1s to use for initial processing. So the first step in processing for these rules can begin with the ATPCO Record 8 instead. For carriers filing via ATPCO, Record 8s referencing ATPCO tariffs can be input and transmitted in ATPCO subscriptions. Otherwise, if non-ATPCO tariffs are preferred, data can be input into unique, data structures and transmitted directly to the administrator of the other system. When an itinerary/query is submitted and identified as a frequent flyer award redemption request, the frequent traveler award redemption process 120 retrieves all Record 8s and matches as many as possible based on the match fields.
In an ATP compliant example, the following private carrier fare by rule tariffs illustrated in Table 7 can be used to house frequent flyer award redemption FBRs. In a non-ATPCO system, one frequent flyer award redemption FBR tariff encompassing all geographies may be adequate.
Referring back to Table 6, one basic match to Record 8 can be by frequent flyer passenger type code(s) (PTCs) account code, market and dates. Once a Record 8 is matched for a given passenger type, account code, and fare component, the tariff/carrier/rule information in that Record 8 is used to find the applicable Category 25 for that same tariff/carrier/rule, as coded in the Record 8.
Record 8s vary by tariff, carrier and rule number. More than one Record 8 may be found that relates to the applicable market and frequent flyer passenger. When multiple Record 8s exist for a given carrier and passenger type, the relationship between each record is “OR”. The system (e.g., frequent traveler award redemption process 120) retrieves all matching Record 8s that pertain to frequent flyer award redemptions that may apply to the frequent flyer identified in the query. This process is unlike Record 2 processing, which allows one match, but is consistent with normal Fare By Rule processing logic.
When a positive match to Record 8 is made, the system continues on to the Category 25 Record 2s for that tariff/carrier/rule. Following is a more detailed description of the Record 8 fields charted in Table 6, with descriptions of how specific fields would be used for frequent flyer award redemption FBRs.
The “CATEGORY 35 INDICATOR” is an optional field and can be used to indicate the presence of a Category 35 (Negotiated Fares Restrictions) within the fare by rule being generated. If not used, this field can remain blank in ATP compliant versions, and does not have to be included at all in a non-ATPCO version.
The “CARRIER” field is matched to the sales carrier shown in the query as operating the frequent flyer program being used for the redemption award being produced. When searching for redemption awards for a given city pair, frequent traveler award redemption process 120 can check the Record 8 for both the owning carrier specified here as well as the partner carriers listed in the accompanying joint carrier (“Partner Carrier”) table. This is a departure from current ATP processing, which would only interrogate the accompanying Joint Carrier Table 997 when a Carrier Code of YY, *M, or *J is coded for IATA, bilateral and domestic joint fares, respectively. Nevertheless, ATPCO cross-edits do not disallow this, so for both the ATP compliant version and the non-ATPCO version, the owning carrier would be identified in the CARRIER field, while all partners, including the owning “sales” carrier, in the award redemption program could be housed in the adjoining table. If there is no Partner Carrier Table, then it will be assumed that the Record 8 applies to the sales/owning carrier as well as partner carriers in the program. Actual partner participation will be coded in Category 4, Flight Restrictions. The initial determination of partner carriers will be accomplished by either an internal table, or by a listing of partners built into the query.
Each Record 8 contains a primary passenger type (PTC) identifying the frequent flyer passenger type code. Currently, ATP has designated “FFY for FREQUENT FLYER” passengers. There is also an “FFP—FREQUENT FLYER PREFERRED PTC”. New PTCs may be produced and used either in addition to or in lieu of the existing frequent flyer PTCs. For example, in the case of AA's AAdvantage program, PTCs can be assigned for AAdvantage Executive Platinum members, AAdvantage Platinum members, and AAdvantage Gold members. Similarly, in the CO OnePass Reward program, a different PTC can be provided for their Platinum members (among others), since there are sometimes awards or special provisions applicable to their Platinum members that do not apply to other OnePass members. AS has MVP qualification levels, that may require separate PTCs. HP has Elite memberships and other carriers have similar structures.
The Frequent Flyer PTC in the Record 8 will be validated against the PTC identified in the incoming query. Normal PTC mapping hierarchy does not apply. However, mapping specific frequent flyer PTCs (such as Platinum members) to general frequent flyer PTCs (such as the standard FFY) can be used when comparing the PTC in the query against the PTC in the Record 8. When comparing the PTC in the Record 8 against the PTC in the Category 25, an exact match is required. No mapping takes place. Within Category 1—Eligibility, exact matches are required against the PTC in the query.
The Passenger Status fields define the status and any geographic restrictions for the passenger specified in PTC bytes 10-12. These fields can include, for example, the fields of application (APPL), passenger status (PSGR), and geographic specification (Type, Loc). The field of application (APPL) defines the positive or negative application of the passenger status data and/or geographic specification fields. When the application field=Blank, the status fields have positive application. When the application field=value N (negative), the passenger status and geographic specification have a negative application.
For frequent flyer award redemptions, the nationality and residency values are used infrequently to indicate geographic restrictions for the frequent flyer PTC. The value in the passenger status field (PSGR) specifies whether the PTC must be a citizen or resident of the location specified here. The ID, AGE, and PASSENGER OCCURRENCE (PSGR OCC) fields define further requirements for a passenger. In a typical reward redemption, however, it is not anticipated that there would be any need for these fields.
In addition to identifying the passenger type as a Frequent Flyer, the query is also identified as an award redemption request. To that end, unique account codes can be established to distinguish one carrier's award redemptions from other frequent flyer programs. Such account code in the query would match the value in the account code field in the Record 8. The account codes can also trigger the award redemption path and bypass the search for published fares.
Table 8 includes an example of hypothetical frequent flyer award redemption programs. A frequent flyer PTC requesting an award redemption can be identified in the query along with an account code. The award redemption and account code are matched to the applicable Record 8 PTC and account code, which in turn will point to the tariff and rule having the award redemption data, as illustrated in Table 8.
Referring back to Table 6, the optional QUALIFYING TICKET DESIGNATOR field requires a matching ticket designator in the query. As it is optional, a frequent flyer award redemption program does not have to use this field. Even if the field is used, this Record 8 ticket designator is not used for final ticketing of the award. That information is obtained from Category 25 Record 3.
The tariff and rule number fields referenced in a Record 8 are used to link the Record 8 to the fare by rule and the Record 2s that they hold.
The ATPCO data structure includes a joint carrier table 997 in the Record 8. This table 997 is currently geared towards identifying participants in YY, multi-lateral or domestic joint fare by rules. However, for the frequent flyer award redemptions, this table 997 can be used for listing the partner airlines participating in the owning carrier's award redemption program. Multiple entries can be made in the table, and depending on how the entries are arranged, the carriers listed can be applied on either an AND or OR basis.
Table 9 illustrates an example table 997.
Note 1:
This table may have multiple sets containing Carrier Code 1, 2, and 3 within the same table number. In this example, the relationship between Carrier Codes #1, #2, #3 is “AND”. The relationship between this set and additional Carrier Code 1, 2, and 3 sets is “OR”
Note 2:
ATPCO edits require at least 2 carriers per set. Therefore, even if an award were to apply via only one partner, the set would be coded with that carrier's code and a “$”, indicating that travel is via that partner and any others coded in Category 4, Flight Applications. Other arrangements that eliminate the need for at least 2 partners is possible.
In addition to the joint carrier table, either a separate non-ATPCO table will be produced to maintain a list of all carriers participating in each carrier's frequent flyer award redemption program, or the query itself can house all partners by default. This separate table (or list of partners incorporated into the query) provides additional flexibility for coding the joint carrier table and/or Category 4—Flight Restrictions. For example, there are awards that are redeemable on all partners, so instead of having to list all of them, and similar to the example in Table 9 above, the “$” can be used to indicate “any partner carrier” (including the owning carrier).
Referring back to Table 6, the DIRECTIONAL INDICATOR field is a match field and further defines the direction of the fare being produced. In an ATPCO compliant data structure, the only permitted values for coding are ‘F’, ‘T’, and Blank. The ‘F’ indicates that the award ticket being produced is valid only from the locale coded in the geo scope loc 1 field of the Record 8 (e.g., Table 6) and ‘T’ indicates that the award ticket being produced is valid only to the locale coded in the geo scope loc 1. Blank indicates “between/and”, signifying that the award redemption may be produced in either direction.
The GLOBAL INDICATOR field is a match field to the route of travel on the incoming query. For example, if the query is NYC-HNL-SYD, indicating a desired flight itinerary across the pacific from New York to Sydney, and the Record 8 has an AT (transatlantic) value in the global indicator field, this desired itinerary would “no-match”. Only standard IATA global indicators are valid in this field.
The geography coded in the fields that follow the “GEO SCOPE” heading define the boundaries to match the city pairs in the query (itinerary) being submitted for a frequent flyer award redemption. The GEO SCOPE fields contain three locations, loc 1, loc 2, and loc 3. Loc 1 and loc 2 can be defined using existing geographic values, or using user produced zone tables (e.g., table 978). The location fields define the end points/fare break points that encompass the market identified in the frequent flyer award redemption query in order for there to be a match.
During processing of a frequent traveler award redemption, an attempt is made to match the first city of the query/itinerary to the value in the loc 1 field of the Record 8. If the city is encompassed by loc 1 or by the locales coded in the loc 1 user defined Table 978, the other end point in the award redemption query is checked against loc 2 (or loc 2 user defined table 978) of Record 8. If one or both of the locations in the query does not match and the direction is blank, then the cities or tables are “flipped” and the process is attempted again. Tables 10 and 11 illustrate an example where a Record 8 geographic scope is defined using user produced zone tables. Table 10 shows how loc 1 and loc 2 fields are defined for a particular Record 8 using user produced zone tables. Table 11 defines the two user produced zone tables for this example.
To provide an illustrative example, a frequent flyer award redemption query is submitted for a departure from Dallas/Fort Worth (DFW) and an arrival at Honolulu (HNL). The DFW departure location is compared with the loc 1 definition, which is defined by table 123. DFW is not encompassed by any of the states/provinces listed in Table 123. The cities or table are flipped, but DFW does not match to the other table (table 456) either. So this Record 8 is a “no-match”. It is clear from the tables that the geographic scope of this award redemption is applicable for travel between the west coast (California, Washington, Oregon, and British Columbia) and Hawaii.
Referring back to Table 6, in addition to the end points covered in loc 1 and loc 2 fields either as values or in user produced zone tables, a third locale field (LOC 3) is provided to denote that all travel within the fare component is wholly within the location specified. So, for example, if a reward redemption is requested for locations within the U.S., the Record 8 can further restrict travel by coding US again in LOC 3. This can ensure that, even if there is no routing validation taking place, or no global direction limits when validating Category 25, the loc 3 field can limit award productions by only matching itineraries where all points specified in the query are in the US as well.
The PASSENGER TRAVEL ORIGIN field is a journey-based geography field used in conjunction with fares that require passengers originate their journey somewhere else, such as in “Visit USA” type fares. This field does not need to be used in a frequent flyer award redemption program. The BATCH, MCN, and EFFECTIVE DATE fields are used for database maintenance. The NUMBER OF SEGMENTS field is provided to list additional secondary discounted passengers such as companions.
The SECONDARY PASSENGER TYPE CODE field can be used for frequent flyer awards involving companion travel. The companion PTC can be identified in this field and then, within the matching FBR, additional details and calculation information can be coded in one of the discount categories, for example, Category 22—other discounts. The query can include both the primary frequent flyer PTC as well as the secondary PTC. In such a case, both values in the query need to match both PTCs in the Record 8 for a match to the Record 8.
As described above, Table 978 (referred to as user produced zone tables and user defined zone tables) was produced to enable the input and processing of multiple geographic types and locales that can be used in lieu of more limited values being specified in the geo spec loc fields. The user defined zone table is well suited for frequent flyer awards based on regions since these regions can be coded in this table.
At the Record 8 level, for the frequent flyer award redemption FBRs, Table 978 can be used as an initial filter so that the query/itinerary will only match to Record 8s pointing to awards offered within the desired region. Again in Category 25 Record 2, when different markets or regions have different provisions within the same governing tariff/carrier/rule, the user defined zone table can be used to differentiate provisions for different regions/sub-regions within the FBR.
As with other geographic location validation, the market identified in the frequent flyer award redemption query is matched against (or is determined to be encompassed by) the locales in the tables. Table 12 shows the fields held in table 978.
The user defined zone tables equate to the region codes that carriers use to define the areas covered by different awards. Multiple positive applications within the table 978 share an ‘OR’ relationship. Multiple negative applications within the 978 Table share an ‘AND’ relationship. Table 978 enables the user to include or exclude geographic points anywhere within the table. In the ATPCO compliant example, the table allows up to 220 entries. Non-ATPCO data structures can be further expanded, if required.
Tables 13 and 14 provide another example of geographic scope encoded using table 978. Using a ATPCO compliant data structure, Table 13 shows FBR Tariff FBRINPV (864), which governs private fares produced between US/CA-Area 1/2/3. Table 14 shows FBRA1P (894), which governs private fares within Area 1 (except US/CA). When producing award redemptions within these areas, any smaller geography encompassed by these areas can be input in the Record 8 to limit award redemptions to such area. Or if all markets within these areas are eligible for award redemptions, then the Record 8 user defined zone tables reflects the entire area encompassed by the tariff.
But, smaller or larger geographic areas may be necessary when coding for specific awards. In the case of individual carrier award redemptions, carriers may be producing award redemptions for all markets served by such carriers and their partners, so in many cases all private carrier FBR tariffs will be invoked. And at the Record 8 level, the geographic scope tables can therefore reflect the entire geographic area encompassed by the tariffs.
However, specific award redemptions (award codes) may apply to a different geography. So within the actual award redemption rule, the CATEGORY 25 Record 2 sequences can have user produced zone tables to limit production of a particular award redemption to such limited geography.
As another illustrative example, if a frequent flyer award redemption query is submitted for travel between DFW and Caracas (CCS), the frequent traveler award redemption process 120 searches the Record 8s for a FBR tariff that encompasses this geography. If ATP tariffs are used, there will be a match to TARIFF FBRINPV (864), shown in Table 13 since DFW is in “N:US” (the U.S.) and CCS is in “A:1” (Area 1).
There may also be Record 8s for this tariff housing different frequent flyer award redemption rules. For illustration, in this example the query matches a Record 8 for this geography that points to an AA rule that governs, among others, their P35V award redemption (the AAdvantage Coach Class PlanAAhead Award availability between North America and either Central America, Colombia, Ecuador, Peru, or Venezuela, for 35,000 miles during peak travel times). Table 15 illustrates the AA Region Codes A and B that apply to P35V award redemptions.
In Table 15, Region 14=North America, and Region 15=Central America, Colombia, Ecuador, Peru or Venezuela. So within the CATEGORY 25 Record 2 for this fare by rule, the user defined zone tables can be used to limit the production of P35V award redemptions to just the regions identified above. Table 16 provides an example table 978 that defines the geographic scope for the P35V award redemptions.
It is worth noting that since the P35V award redemptions include travel between Mexico and Central America/Colombia/Ecuador/Peru/Venezuela, in the ATP compliant data structures, another rule has to be set up in FBRA1PV (894) tariff to cover those markets. However, within non-ATPCO data structures, frequent flyer award redemption tariffs can be produced to encompass different or larger geographies, or could even encompass all geographies. In such cases, one award does not have to be duplicated in more than one tariff.
When matching the DFW-CCS example itinerary/query above to the user produced zone tables in the Category 25 Record 2, the following processing can be applicable. The frequent traveler award redemption process 120 compares the first city of the fare component to be validated (DFW) to the GEO SPEC field in the table 978. The frequent traveler award redemption process 120 processes data in the 978 table in a hierarchy. For example, negative limitations are processed before positive limitations, and with these subdivisions, specific to general. If the first location has a negative application in the loc 1 field, then frequent traveler award redemption process 120 exits from the 978 table. But if the first city is not in the table at all, the frequent traveler award redemption process 120 flips the city pair identified in the query, and tries to validate the second city (CCS) against the locales in the loc 1 user defined zone table. If the second location is not matched in the loc 1 table, then frequent traveler award redemption process 120 reads on to the next Category 25 Record 2.
If the first city in the query matches against a positive application in the loc 1 table, that 978 table is applicable for that location in the query. Thus, the frequent traveler award redemption process 120 goes on to validate the second city in the query against the loc 2 table. If the second city is not matched (positively) in the loc 2 table, then the frequent traveler award redemption process 120 flips the cities and tries to validate the second location in loc 1 and the first city in loc 2. If locations are not matched (positively), then the frequent traveler award redemption process 120 reads on to the next Category 25 Record 2.
In the ATPCO compliant data structures, at least one positively validated entry (Byte 8=Blank) in table 978 is generally needed to constitute an applicable table. The presence of a negative application in table 978 does not imply any other positive application. All positive applications are stated explicitly in the table 978. However, the non-ATPCO data structures can have negative entries without positive entries, allowing for more flexible and simplified coding.
There may be many sequences of category control records (Record 2s) for any given frequent flyer award redemption FBR tariff/carrier/rule/category 25. These records identify which itineraries further qualify for the award redemptions that will be produced in the attached Category 25 Record 3 tables. These tables are linked via a string of data table numbers that serve as a pointer to the actual Record 3s which physically house the frequent flyer award redemption production fields and accompanying provisions.
Once a frequent flyer award redemption itinerary/query has matched to a Record 8, that Record 8 tariff/carrier/rule number will point to the Category 25 tariff/carrier/rule. Then the redemption itinerary/query matches to the proper Record 2 sequence within Category 25. If a match is made within Category 25, then additional matching takes place within the string of Record 3 tables. If the query matches and passes all levels of Category 25, the system then goes on and attempts to match and pass the remaining categories in the same manner. For Record 2s matching, the itinerary/query is compared against the appropriate Record 2 match fields. These fields can include tariff/carrier/rule number, locations, fare application indicator, joint “partner” carrier table, and effective and discontinue dates.
When the Record 2 sequence has been matched, the rest of the Record 2 sequence, including the string of data tables is evaluated to determine the appropriate action to take in producing the award redemption. If a match is made to a Record 2 sequence, processing generally would not continue to read higher number sequences.
Process 120, in determining the frequent flyer award redemption FBRs, follows normal ATPCO/Industry Record 2 processing guidelines, but, as with other FBRs, there are certain exceptions. One exception to the guidelines is that the Record 8 is used to match to the Record 2 instead of a fare record or Record 1 fare class. Another exception involves unique FBR stringing rules. When a matching Category 25 Record 3 table is tagged NO DISCOUNT (i.e., the NO DISC field is coded with an “X”) then processing stops, even when multiple OR tables exist in the set. For the frequent flyer award redemption FBRs, this “No Discount” field takes on the meaning “NO AWARD REDEMPTIONS”. For FBR Category 25 Record 3 stringing, if a Record 3 is matched within a string, the system still reads through the other Record 3 tables as well, including OR tables, unless the No Discount tag is set. This applies to IF THEN sets as well, except that an “IF THEN” match does not read on to an ELSE table. Otherwise, even if an award redemption results, the system will continue to read on within the string for any additional awards that may apply, thus allowing multiple awards to be returned. For any FBR Category 25, stringing together tables with AND Relational Indicators is not allowed.
Another exception is that the FBR Record 2 for Category 25 does not contain the following fields: fare Class, OW/RT, routing, footnote, general rule and alt general rule (There are no footnotes or general rules for Category 25). Another exception is that the Record 2 for Category 25 includes User Defined Zone Tables in addition to the LOC 1 & 2 fields.
Table 17 illustrates the fields and values of Category 25 Record 2.
Category 25 helps produce and support the frequent flyer award redemptions. The award redemptions can be handled similarly to other SPECIFIED FBRs. However, one difference is that instead of expressing a specified amount, the cost in mileage is coded instead. The Category 25 Record 3 data for frequent flyer award redemptions assists in performing the following functions: matching information to the query/itinerary data, calculating the cost in mileage, producing the award, and providing resulting award information.
As described above, the ATPCO FBR tariffs represent large groupings of geographic data, but do not always correspond to the groupings of award redemption data. This could result in having to code such award data in more than one ATP tariff. An alternate non-ATPCO data structure solution can designate one frequent flyer award redemption tariff that encompasses all geographies or designate different tariffs that correspond to different frequent traveler award regions. This is a departure from normal ATPCO tariff assignments, and can include the production of unique global code(s) for such tariff(s).
In review, in addition to the Category 25 Record 3, the following records and tables also support frequent flyer award redemption FBRs: Record 8—Fare by Rule, Table 997—Joint (“Partner”) Carrier Table, Table 978-User Produced Zones, Record 2—Fare by Rule Category 25, and, on occasion, Base Fare Table 989. As described in connection with
Within the Record 3 tables, there are more fields that need to be matched before an award redemption can be produced. One field applicable to frequent flyer award redemption FBRs is the PTC field. Other matching fields such as passenger status and override dates may also be used. Once the match to such fields is complete, the award redemption is produced according to the specified mileage information and resulting award information. In addition, the fare by rule can have further restrictions coded in the other categories as well. To validate other rule categories within the fare by rule, the resulting award information within Category 25 Record 3 is obtained and used to match to Record 2's for other fare by rule categories.
Table 18 illustrates an example of the Category 25 Record 3 fields, and indicates which fields are used for the frequent flyer award redemption fare by rule application. In addition, unique frequent flyer values/conventions are noted. Differences between the ATPCO Record 3 and the non-ATPCO data structures are also noted.
Prior to processing Category 25 Record 3 tables, a Record 2 for Category 25 is matched in order to determine the correct Record 3 provisions for the fare/award. After a match is made to Record 2, processing attempts to match Category 25 Record 3 table(s) housed in the matching Record 2, based on the Record 3 match fields. The following are Record 3 match fields that can be used for frequent flyer award redemptions: passenger type code (PTC), passenger status information, travel wholly within, number of flight segments, mileage of the fare component, fare type (match/action field), and override date table no. 994. If processing cannot match all of the match fields, then the system will “no match” the Record 3 and continue processing to the next Record 3 table.
Once a match is made, the data can be processed as follows:
After Category 25 is processed, rule conditions are validated. Matching fare by rule category data, for any category, is based on the data in the Category 25 resulting fare fields. For specified FBRs, rule validation applies the fare by rule fare rule and general rule category data. Rules for calculated FBRs are taken from either the base fare, the FBR categories, or in some cases both are applied depending on the way the category override tags are set.
The reservation booking designator (RBD) data is validated. For specified fare by rules, RBD data can be found in the resulting fare fields (prime RBD and table 999 booking code exceptions). It is not anticipated that RBD Record 6 Chart 1 would need to be interrogated, however, based on customer preference/configuration, this processing logic could be added. Also, again based on customer preference/configuration, Mixed Class of Service table will be used as long as at least one of the carrier's flights has been validated by the Prime or Table 999 exceptions. Record 6, Chart 2 will not be interrogated. Note that the Prime refers only to the carrier owning the award program. The partners' RBDs will be coded in Table 999. Unresolved partner flight segments will not validate against the prime.
Category 10 data is validated next to determine if there are permissible award combinations.
If processing passes validation of all of the above criteria, then the resulting fare/award passes. Processing continues to another Category 25 Record 3 table. If processing does not pass validation of all of the above criteria, the resulting fare fails and processing continues to attempt to pass another possible resulting fare (for calculated discounts off of multiple base fares), and/or moves on to another Category 25 Record 3 table.
There are also exceptions to the fare by rule processing of strings of Record 3 tables. One exception is that Record 3 for Category 25 is used as a main category and not as an IF condition. Another exception is that edits prevent AND tables for Category 25. Another exception is that when processing matches, a Record 3 with the no discount (byte 51) field having value X, indicates that a fare by rule cannot be produced according to the table. Processing will not continue to another Record 3. Another exception is that when processing matches a Record 3, processing produces the award according to the table, and processing continues to another table (including OR tables) attempting to match and produce another fare (unless byte 51 is value X). Another exception is that after processing matches the IF THEN set, whether pass of fail, processing continues to another set in the string, attempting to match and produce another fare (unless byte 51 is value X). General rules are not permitted for Category 25. However, general rules can be referenced in any Category in the fare by rule other than Category 25.
Referring to the fields in the example in Table 18, for frequent flyer award redemptions, the passenger type code (PTC) identifies the frequent flyer passenger eligible for the award being produced. Data in this PTC field matches to the primary PTC in Record 8. The normal PTC mapping hierarchy does not apply but there will be mapping of specific frequent flyer PTCs requested in the query to general frequent flyer PTCs coded. Furthermore, specific Frequent Flyer PTCs are allowed under general Frequent Flyer PTCs in the Record 8, and will match to the specific Frequent Flyer PTC referenced in the query. If the PTC in Category 25 matches/maps to the primary PTC in Record 8, processing produces the fare according to the data in the Category 25 table (provided a match is also made to all other Category 25 match fields). The passenger status fields define the status and any geographic restrictions for the passenger specified in the PTC field. These fields include the application field (APPLICATION), the passenger status field (STATUS), and the geographic specification fields (TYPE, LOC). These fields are described above in connection with the Record 8 example of Table 6, where they also reside.
When data is present in travel wholly within fields (TRAVEL WHOLLY WITHIN-TYPE, TRAVEL WHOLLY WITHIN-LOC) all points of travel on the fare component must be within the specified location. This geographic data may be expressed as an area, zone, nation, or state. The passenger travel origin fields refer to origin of journey and do not have to be used for frequent flyer award redemptions. The number of flight segments field identifies the maximum number of flight segments (coupons) per pricing unit that can be used for the resulting fare/award data.
The override date table identifies a table containing dates on which travel, ticketing, and/or reservations are valid for the data in this category. When present, the table further defines the specific date range within effective/discontinue dates of the Record 2. When validating travel override dates in table 994, validation is against the departure date of the first flight of the fare component being validated.
Once processing matches all match fields in the Record 3, processing interrogates the data in the no discount field. This field is used to specify that the FBR does not apply for the matched passenger itinerary. If processing matches the table and the no discount field is value Blank, then the fare/award is produced according to the remainder of the Category 25 data. Processing also continues to other Record 3 tables in the string. As described above, if processing matches the table and byte 51 is value X, then no discount/award is permitted. Processing does not continue to another Record 3 table in the string. If processing “no matches” the table, processing continues to another table (regardless of the value in the no discount field).
Once a match is made to the Record 3, processing produces the fare based on the fare calculation fields. The fare calculation fields can include mileage fields (MINIMUM MILEAGE, MAXIMUM MILEAGE), a fare calculation indicator field (FARE CALCULATION FORMULA INDICATOR), a percent field (PERCENT) and fare 1/fare 2 fields (SPECIFIED FARE NO. 1/2, CURRENCY 1/2, DECIMAL).
The minimum/maximum mileage fields specify the minimum/maximum mileage permitted for the fare component/award being produced in order to match the table. Validation of the mileage data is against the mileage of the fare/award being produced. Processing identifies the origin and destination of the fare component being produced and determines the mileage between these points. Mileage is calculated as the TPM for the origin and destination of the fare component ignoring any/all interchange and intermediate travel points. If no TPM exists for the origin and destination of the fare component, then great circle mileage would be calculated for all intermediate ticketed points. These mileage fields may have a value 00000 through 99999, signifying a specified number of miles. Tables 19 and 20 illustrate an example.
The data in Table 19 indicates that if the itinerary is for a frequent flyer and the one-way mileage of the award being produced is less than or equal to 1200 miles, then 10,000 earned miles will be charged. While, Table 20 indicates that if the mileage is greater than or equal to 1201 miles and less than or equal to 99999 miles, then the award costs 15,000 miles.
The fare calculation indicator field indicates the fare calculation formula to be used in the production of the fare by rule. A value of “C” is used to calculate fares off of a base fare, but typically is not used for award redemptions. Instead, “A” can be used for award redemptions that provide discounts off of published fares upon payment of a specified number of miles (i.e. the fare will be calculated by applying data in the PERCENT field against base fare information in table 989). In this scenario, the resulting amount of the calculated fare is in addition to the specified amount of required mileage. This is a unique convention established for frequent flyer award redemptions.
The most common value for award redemptions will be Value “S”—Specified. In such cases, the cost in mileage is coded in Fare 1, and if there is a co-payment, Fare 2 can be coded. This convention is also unique to frequent flyer award redemption FBRs. The resulting fare OW/RT field can specify whether the award redemption is an OW (one way) or a RT (round trip) award.
The percent field may be used for frequent flyer award redemptions that require mileage to obtain a percent discount off of a base fare.
For Frequent Flyer Award Redemption FBRs, the fare 1/fare 2 fields are used to express the earned mileage required to obtain the award, and additional co-pay amounts, when applicable. Each fare field specifies a fare amount, currency, and decimal place(s) in the amount. The fare 1 fields can be used for earned mileage, and the fare 2 fields can be used for co-payments. As such, the relationship between the fields is “And”. This convention is also unique to frequent flyer award redemption FBRs. Table 21 illustrates of an encoded award that requires both the redemption of miles and a co-payment.
Referring to
If the value does indicate that the fare is specified (e.g., the value is “S”), the process 800 reads the specified Fare no. 1 field (e.g., bytes 67-70 (packed) or bytes 78-86 (unpacked) for an ATPCO data structure) and the Currency 1 field (e.g., bytes 71-73 (packed) or bytes 87-89 (unpacked) for an ATPCO data structure).
Using the values shown in Table 21, the value of the specified fare 1 field is 20000 and the value of the currency field is MLG, to represent that the earned credit fare is in terms of earned mileage. In some examples, process 800 also reads the decimal field (e.g., byte 74 (packed) or byte 90 (unpacked) for an ATPCO data structure) for Fare 1, which typically would be zero unless the earned travel credit was not represented in whole integer units, and apply the value by placing the decimal point where indicated in the specified Fare 1. By combing the fields that process 800 read (820), process 800 determines (825) that the fare, in earned travel credit, is 20,000 miles.
Process 800 reads the specified Fare no. 2 field (e.g., bytes 75-78 (packed) or bytes 91-99 (unpacked) for an ATPCO data structure) to determine if the field has a non-null or non-zero value. If the value is null or zero, then there is no co-payment necessary and process 800 can report the fare in terms of the earned travel credit (e.g., 20,000 miles). If the value is non-null or non-zero, then process 800 determines the co-payment. In addition to the specified fare no. 2 field, process 800 reads (840) the currency 2 field (e.g., bytes 79-81 (packed) or bytes 100-102 (unpacked) for an ATPCO data structure) and the decimal field (e.g., byte 82 (packed) or byte 103 (unpacked) for an ATPCO data structure) for fare 2.
Using the values shown in Table 21, the value of the specified fare 2 field is 15000 and the value of the currency field is USD, to represent that the fare co-payment is in terms of US dollars. The value of the decimal field is 2, representing the placement of the decimal point two places from the end of the specified fare number. By combing the fields that process 800 read (840), process 800 determines (845) that the co-payment, in US dollars, is $150.00.
To determine (850) the total fare, process 800 treats the determined earned travel credit fare (825) and the determined co-payment (845) as an “AND” relationship. This is different from the standard ATPCO processing, which uses the specified fares in a different way, and treats them as an “OR” relationship. Using the values shown in Table 21, process 800 determines (850) that the total fare is 20,000 miles and a co-payment of $150.00 US dollars.
As described in Table 18, in a non-ATPCO data structure, some of the filler bytes can be changed into fields that define purchase options for travel award credit, should a user not have enough earned travel award credit for a particular travel option. These fields can include permitted deficit/minimum balance fields, a number of miles field, a purchase rate field, a currency field, and a decimal field. The permitted deficit match field indicates up to what percentage difference between the number of miles required for the mileage award and the number of miles available can be purchased, while the minimum balance field indicates the minimum number of earned miles required to purchase additional miles. Although miles are used here for illustration, other earned travel award credit units (e.g., nights spent, number of trips, etc.) are equally applicable to other frequent award programs involving redemption rules to produce an allowable itinerary, such as hotel and rental car reservations.
For example, the percentage can express the number of miles earned applied against the number of miles required to purchase an award. The number of miles action field provides the “per miles” portion of the formula (e.g., the rate) for paying the mileage deficit to make up for a shortfall in the number of miles earned applied against the number of miles required to purchase an award. The value of this field can be 00001-99999. The purchase rate action field provides an amount representing the rate per number of miles shown above. For example, the purchase rate can be “0.15 USD” per mile, or “20.00 USD per block of 100 miles.” The currency field indicates the currency code of the above amount. The decimal field indicates the decimal placement.
Referring to
Referring to
For an illustrative example, the value for the number of miles field can be 100, the value for the purchase rate field can be 2000, the value for the currency field can be, e.g., United States Dollars (USD) or other suitable currency, and the value for the decimal field can be 2. By combining these values, process 900 determines that the rate is 20.00 US dollars for each 100 miles. Process 900 can report (930) this rate to the user, along with the maximum percentage of miles that can be purchased. The maximum amount is determined using the value in the permitted deficit field. For example, if the value is 05, then process 900 reports to the user that 5% of the travel award credit can be purchased for the rate identified (e.g., $20.00 US per 100 miles).
Process 900 can also optionally determine (935) the maximum amount of purchasable travel award credit for a particular travel option and present it in terms of travel award credit. For example, if an award redemption for a particular travel option is 20,000 miles, process 900 can also provide to the fare (i.e., 20,000 miles) with an option that up to 1000 of those miles can be purchased (e.g., using the 05 value of permitted deficit) for the rate identified (e.g., $20.00 US per 100 miles).
Another way to present this to the user is to list all of the possible purchase options (e.g., determined by the value in the number of miles field) as separate travel options. For example, using the 20,000 miles fare and the $20.00 US per 100 miles rate, in addition to a travel option showing a fare of 20,000 miles, there would be 10 additional travel options with the same itinerary, but different mileage requirements and co-payments. For example, there would be one travel option with a fare of 19,000 miles and a $200.00 US co-payment, another travel option (e.g., same itinerary) with a fare of 19,100 miles and a $180.00 US co-payment, another travel option with a fare of 19,200 miles and a $160.00 US co-payment, and so on. If process 900 knows the actual deficit (e.g., the number of earned travel credit awarded to the particular user is included in the query or obtained from another accessible database on the network (e.g., 140)), then process 900 can limit the travel options to those that correspond to the actual deficit.
Table 18 also includes a grouping of fare comparison fields. These fields identify a fare range or a specific fare that should be retrieved to be used for comparison to the resulting fare. The FARE RANGE 2-MAX FARE can be used to cap percent discounts at a designated amount. For instance, when an award includes a percent discount of a published fare (i.e. the base fare) the maximum amount of the discount can be capped as indicated in this field.
Table 18 also includes a grouping of fields labeled as resulting fare information. Since the fare by rule has no associated fare record or Record 1, the resulting fare information fields exist in the Record 3 for Category 25 in order to build a fare/award and hold the information that would normally be held in the fare and/or Record 1. The resulting fare fields can include the following: a OW/RT field, a global field, a routing tariff field, a routing number field, a fare class field, a fare type field, a season type field, a day category field, a display category field, a pricing category field, a prime RBD field, a RBD Table 999 field, a ticketing code field, a ticketing code modifier field, a ticket designator field, and a ticket designator modifier tag field.
Processing uses data in the resulting fare fields for matching and validating fare by rule Record 2s and Record 3s for other categories coded in the FBR. When the fare calculation indicator field has a value S (Specified Fare), edits require that the following resulting fare fields be coded: OW/RT, routing number, fare class code, fare type, display category, pricing category, and prime RBD.
The OW/RT field specifies whether the resulting fare is a one way or round trip fare. There are three values that can be encoded into this field. A value of 1 indicates the reward is applicable to a one-way fare that may be doubled (Tag 1). A value of 2 indicates the reward is applicable to a round trip fare (Tag 2). A value of 3 indicates the reward is applicable to a one-way fare that may not be doubled (Tag 3).
The GLOBAL INDICATOR field specifies the global indicator of the resulting fare. Processing validates the specified global indicator against the route of travel in order to pass the fare/award being produced. Only IATA global indicators are valid. A global indicator may be present with or without data in the routing tariff and/or routing number fields.
The routing tariff field specifies the ATPCO routing tariff of the routing number for the resulting fare. The routing tariff may be a fare by rule routing tariff or a published fare routing tariff. Edits require data in routing tariff when routing number is a value between 00001-09999 (specified routing number). Currently, when the routing number field has a value of 00000 (apply MPM), a value of 77777 (any routing or MPM), a value of 88888 (any routing), or a value of 99999 (no application), ATPCO edits require that routing tariff be value 000 (no application). In the non-ATPCO data structures, values 77777 and 88888 can be associated with a routing tariff number in this field.
The routing number field specifies the routing number for the resulting fare. Processing validates the specified routing tariff and number in order to pass the fare by rule producion. Edits require data in routing number when the fare calculation indicator field has a value S (specified). For frequent flyer award redemption FBRs, a different value (e.g., 900 and/or 910) is included to indicate that no routing validation is required.
As described above, particular values of the routing number field can have a certain significance. The value range of 00001-09999 indicates a specified routing. Specified routings refer to the routings of the carrier owning the program. A value of 00000 indicates that the maximum permitted mileage (MPM) published by IATA applies for the routing validation of the resulting fare. A value of 77777 indicates that the resulting fare may pass routing validation based on any routing in the market for the participating carrier or based on the MPM for the market. A value of 88888 indicates that the resulting fare may pass routing validation based on any routing in the market for the Category 25 Record 2 carrier. When multiple partners participate in an award (“interline awards”) via Routing 77777 or 88888, the system will validate the routings for each carrier applicable on the portion of travel being flown by that carrier. A value of 99999 indicates that the routing number of the base fare applies to the resulting fare. Since there will be no base fare comparisons for specified frequent flyer award redemption FBRs, either this value of 99999, or another value (e.g., routing 900 and 910) can be established to indicate that no routing validation takes place.
For frequent flyer award redemption FBRs, the FARE CLASS field specifies the award code of the award redemption being produced. The award code in this field is also used later to match/validate Record 2s and Record 3s for the other categories in the FBR and other processing of the fare produced from the fare by rule, such as RBD validation.
The FARE TYPE, SEASON, DAY OF WEEK fields specify the fare type code, season code, and day of week code for the resulting fare. Data in these fields is used to match/validate fare by rule Record 2s and 3s and for all future processing of the fare produced from the fare by rule process. Edits require data in the fare type field when the fare calculation indicator field has a value S (specified). In addition, fare type also identifies a cabin class. When a query requests awards in a particular cabin, it is validated against this field, however, if unique Fare Type codes are not assigned to awards in different cabins, then a Booking Code hierarchy that is broken down by cabin can be produced. The DISPLAY CATEGORY field specifies the display category type for the resulting fare. Data in this field is used for future processing of the fare produced from the fare by rule process. Edits require data in the display category field when fare calculation indicator field has a value S (specified). Frequent flyer award redemptions can also include unique values of a display category code.
The PRICING CATEGORY field specifies the pricing category (e.g., normal/special) for the resulting fare. ATPCO edits require data in the pricing category field when fare calculation indicator field has a value S (specified). This field can be option for frequent flyer award redemptions, and therefore, does not have to be included in the non-ATPCO data structures.
The PRIME RBD and RBD TABLE 999 fields specify the prime RBD(s) and/or RBD table 999 booking code exception data for the resulting fare/award. Data in these fields is used for RBD validation of the resulting fare/award. In addition to RBD validation, a mixed class of service table may be used to validate flight segments that remain unqualified after RBD validation.
The value in the TICKETING CODE field replaces or alters the fare class code/award on the ticket. When a ticketing code is entered with a hyphen preceding it, the information is appended to the end of the resulting fare class code/award. The ticketing code modifier field indicates the type of rule information that should be appended to the resulting fare class code/award on the ticket.
The value in the TICKET DESIGNATOR field is appended to the end of the resulting fare class code/award using the convention of ‘/’ followed by the ticket designator information. The ticket designator modifier (TDM) field is used to indicate that additional information should be appended to ticket designator.
Table 18 also includes a grouping of fields labeled as CATEGORY OVERRIDE tags. These fields indicate whether the rules of the base fare or the new fare being produced apply. Typically, for specified FBRs, including the frequent flyer award redemptions, the category override tags will be blank. For calculated frequent flyer award redemptions (e.g., mileage plus a percent discount), these fields can be used in the same manner as other calculated FBRs.
The following two examples provide further illustration of how process 120 can be used.
Table 22 illustrates an example query. There may be several Records 8s that match to the query. One such match is shown below in Table 23. The match is to an example rule that can be added to hold, for example, AAdvantage “oneworld” awards only. The “oneworld” awards are valid on American Airlines, Aer Lingus, British Airways, Cathay Pacific Airways, Finnair, Iberia, LanChile and Qantas Airways.
The number of miles redeemed varies depending on the distance and class of service traveled. Oneworld award codes contain an “OW” for oneworld, the number of miles needed to claim the award (in thousands; for example ‘30’ for 30,000 miles and a letter code for the cabin class, e.g. OW30Y.
With the above information, it can be determined that there is a frequent flyer award redemption fare by rule that the passenger may qualify for given the query received. To further determine if the passenger is eligible, processing proceeds to the TRF/CXR/RUL indicated in the Record 8 above, and first searches for matching CATEGORY 25 Record 2s. Table 24 illustrates an example matching CATEGORY 25 Record 2.
Within the Record 2 sequence, the following Table 25 illustrates an example Record 3 that is a “match”. With at least one match, the award redemption can be produced.
In addition to the award redemption is produced in Category 25, other categories hold the rest of the award conditions. For instance, Category 8—stopovers, can be coded with “unlimited” in accordance with this “oneworld” award, and validated accordingly.
Table 26 illustrates another example query. There may be several Records 8s that match to the query. One such match is shown below in Table 27. The match is to an example rule that can be added to hold coach awards only.
With the above information, it can be determined that there is a Frequent Flyer award redemption Fare By Rule that the passenger may qualify for. To further determine if the passenger is eligible, processing proceeds to the TRF/CXR/RUL indicated in the Record 8 illustrated in Table 26, and first searches for matching CATEGORY 25 Record 2s. Table 28 illustrates an example matching CATEGORY 25 Record 2.
Within the Record 2 sequence, the following Table 29 illustrates an example Record 3 that is a “match.” For instance, the PTC matches, and the PHX-BWI flight segment(s) fall within the required mileage range and maximum number of flight segments. With at least one match, the award redemption can be produced.
In addition to the award redemption is produced in Category 25, other categories can hold the rest of the award conditions. For instance, Category 11—blackouts, can hold blackout dates applicable to value awards.
The above-described techniques can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The implementation can be as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
Methods can be performed and apparatus can be implemented by one or more programmable processors executing a computer program to perform functions of the techniques described above by operating on input data and generating output. Methods can also be performed by, and apparatus can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). Modules can refer to portions of the computer program and/or the processor/special purpose logic circuitry that implements that functionality.
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.
To provide for interaction with a user, the above described techniques can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer (e.g., interact with a user interface element). Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
The above described techniques can be implemented in a distributed computing system that includes a back-end component, e.g., as a data server, and/or a middleware component, e.g., an application server, and/or a front-end component, e.g., a client computer having a graphical user interface and/or a Web browser through which a user can interact with an example implementation, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet, and include both wired and wireless networks.
The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. Although a single client and a single server are shown in one example, the server can service multiple clients. Also, the processes described herein can be distributed over multiple servers.
The techniques above have been described using examples of particular embodiments. Other embodiments are within the scope of the following claims. The alternative examples are for illustration only and not to limit the alternatives in any way. The steps of the techniques described above can be performed in a different order and still achieve desirable results. The techniques described above can be applied to other frequent award programs involving redemption rules to produce an allowable itinerary, such as hotel and rental car reservations.
