AU2013203407A1 - Method and system for air far verification and auditing - Google Patents

Abstract

Abstract A method and system for air fare verification and auditing for a travel itinerary during a ticketing transaction. A request is received from a customer to verify the air fare for the travel itinerary. The fare verification process 5 determines if the air fare for the travel itinerary is in a fares database. A plurality of rules and restrictions that are applicable to the air fare are validated. The process determines if the air fare passes each of the plurality of rules and restrictions and verifies the air fare if all rules and restrictions are satisfied. A verification response can be provided to the customer for the air 10 fare verification request during the ticketing transaction. An audit report can also be provided via a web reporting tool in near real time. Ticket Agent Computer Reservation 25 System Fare Verification 30 System Web 40 Report Customer 45 Audit Department

Description

Regulation 3.2 AUSTRALIA PATENTS ACT, 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT ORIGINAL Name of Applicant: WORLDSPAN, L.P. Actual Inventors: THURLOW, Stephen H; PAVELKA, Brian A; CALLAWAY, Suzanne R Address for service in Australia: AJ PARK, Level 11, 60 Marcus Clarke Street, Canberra ACT 2601, Australia Invention Title: Method And System For Air Fare Verification And Auditing The following statement is a full description of this invention, including the best method of performing it known to us. 1 METHOD AND SYSTEM FOR AIR FARE VERIFICATION AND AUDITING Back-round of the Invention 5 The present invention relates generally to verification of prices for travel itineraries and, more particularly, to an automated process for considering and applying variances in the numerous factors that affect ticket pricing and ticket reissues. Every year airlines lose millions of dollars in revenue within their own 10 operations by issuing incorrectly priced tickets in which the price has been manipulated or manually entered by airline employees. The result is an under collection of the appropriate fare. In many companies, the focus of incorrectly priced tickets is on those tickets issued by travel agents. It may be difficult to gain support within a company that millions of dollars are also lost each year 15 due to under collection of fares by internal airline employees. It is common that departments responsible for agency distribution may concentrate on eliminating and/or reducing incorrectly priced agency issued tickets. Departments responsible for revenue accounting, fraud, and yield management may take an additional approach and confirm that internal 20 revenue leakage is and has been a big issue for some time. A concentrated effort must take place within each company to acknowledge and take ownership of the internal problem. There are various examples of the manner in which internal airline 25 employees are able to price a ticket resulting in the under collection of the appropriate fare. These examples include the following: (1) booking in one class and pricing the ticket in another; (2) manually pricing a ticket with the incorrect currency amount; and (3) applying corporate discounts incorrectly (non-corporate travel, family members). It is very easy for airline employees to issue waivers/favors without the airline ever actually seeing the cumulative total for the week, month, or quarter. It is also common that airline companies do not have the staff to proactively monitor for fraudulent activities and a majority of the fraud that is identified is done so by chance. 5 Although tools are available in the airline business to automatically price travel itineraries and apply that price to a ticket, many tickets continue to have different prices or reissue amounts attached to them for various reasons. These variances cause airlines to lose huge amounts of revenue due to fraud, human errors, and business decisions that do not take into account 10 the cumulative revenue loss for waiving fare rules. To understand the significance of airline ticket under-pricing and consequent revenue loss, a simple example illustrates the point. For an airline carrier that issues 200,000 tickets weekly, of which 40,000 are priced by an airline ticket agent, an error rate of 10% in the fare price, representing 15 4000 tickets, is a conservative estimate. At an average ticket price of $500, the average under-pricing per ticket is $50 (10% of the ticket price). The loss over the course of a year is $10.4 million. Being able to recoup 50% of the lost revenue would generate an additional $5.2 million per year for the airline. It is an object of preferred embodiments of the present invention to address 20 some of the aforementioned disadvantages. An additional and/or alternative object is to at least provide the public with a useful choice. Summary of the Invention This specification describes a system and method for determining if a 25 correct price or reissue amount has been selected for a travel itinerary. The process provides the customer with verification that a correct price or reissue amount was used on the ticket, and if the price used was not the correct price, then the price or reissue amount that should have been used.

The fare verification process provides a way to audit manual tickets by validating if the price used on the ticket was correct. The fare verification tool can be used to detect errors and stop an incorrect transaction from taking place. It can be used to monitor business to generate reports, and it can be 5 used to validate new pricing or reissue systems. In one aspect of the invention, a computer program product is provided for air fare verification and auditing for a travel itinerary associated with a ticketing transaction when executed on a computer processor. The computer program product comprises a non-transitory computer readable 10 medium having computer readable code embedded therein, the computer readable medium comprising program instructions that receive a request via a communications network to verify that the air fare for the travel itinerary has been priced correctly; program instructions that determine if the air fare for the travel itinerary is in a fares database; program instructions that validate a 15 plurality of rules and restrictions applicable to the air fare; program instructions that determine if the air fare passes each of the plurality of rules and restrictions and verify the air fare has been priced correctly if each of the plurality of rules and restrictions is satisfied; program instructions that provide a verification response for the air fare verification request via the 20 communications network, wherein the verification response provides an electronic notification to a recipient of any pricing error made during the ticketing transaction; and program instructions that automatically provide an audit report following completion of the ticketing transaction via the communications network, the audit report including an indication of any 25 pricing error. The term 'comprising' as used in this specification and claims means 'consisting at least in part of'. When interpreting statements in this 4 specification and claims which include the term 'comprising', other features besides the features prefaced by this term in each statement can also be present. Related terms such as 'comprise' and 'comprised' are to be interpreted in similar manner. 5 Preferably the computer program product further comprises program instructions that save and report a failure reason for each rule and restriction that is not satisfied by the air fare, if the air fare did not pass all rules and restrictions applicable to the air fare. Preferably the computer program product further comprises program 10 instructions that determine a best fare among a plurality of eligible fares, if the air fare did not pass all rules and restrictions applicable to the air fare. Preferably the computer program product further comprises program instructions that remove a ticket designator associated with the air fare and apply a pricing adjustment associated with the ticket designator if the air fare 15 passes each of the plurality of rules and restrictions. Preferably the computer program product further comprises program instructions that remove a fare modifier associated with the air fare and apply a pricing adjustment associated with the fare modifier if the air fare passes each of the plurality of rules and restrictions. 20 Preferably the computer program product further comprises program instructions that interrupt the ticketing transaction if the air fare did not pass all rules and restrictions applicable to the air fare. Preferably the computer program product further comprises program instructions that search a published fares database. 25 Preferably the computer program product further comprises program instructions that search a special fares database. r% Preferably the computer program product further comprises program instructions that determine a plurality of rules and restrictions that are applicable to the special fares. Preferably the computer program product further comprises program 5 instructions that determine if the received request is for a reissue ticket verification. Preferably the computer program product further comprises program instructions that locate a plurality of eligible fares for the reissue ticket request in the fares database; and program instructions that select a best 10 reissue amount from the plurality of eligible fares for the reissue ticket request. Brief Description of the Drawings These and other advantages and aspects of the present invention will become apparent and more readily appreciated from the following detailed 15 description of the invention taken in conjunction with the accompanying drawings, as follows. Fig. 1 illustrates processing logic for the fare verification process in accordance with an exemplary embodiment of the invention. Fig. 2 illustrates processing logic for the "keep the fare" process in 20 accordance with an exemplary embodiment of the invention. Fig. 3 illustrates processing logic for the "find best fare" process in accordance with an exemplary embodiment of the invention. Fig. 4 illustrates the processing logic for the "reissue fare" process in an exemplary embodiment of the invention. 25 Fig. 5 illustrates the processing logic for the "find the best reissue amount" process in an exemplary embodiment of the invention.

Fig. 6 illustrates the network architecture for the airline fare verification system an exemplary embodiment. Fig. 7A illustrates a typical passenger name record (PNR) for an automatically priced fare using an airline reservation system. 5 Fig. 7B illustrates a passenger name record that has been adjusted manually by the ticket agent to price in a different class of service than the class booked in the PNR. Fig. 7C illustrates a response that can be transmitted to the ticket agent as a result of the audit by the fare verification system to advise the 10 agent that fare validation has failed. Fig. 8 illustrates an exemplary aggregate report providing the total count of under priced tickets and the corresponding value of the under priced tickets. Fig. 9 illustrates an exemplary location report providing the total count 15 of under priced tickets and the corresponding value of the under priced tickets by location. Fig. 10 illustrates an exemplary specific location report providing each failed ticketing transaction for a specific location. Detailed Description of the Invention 20 The following description of the invention is provided as an enabling teaching of the invention and its best, currently known embodiment. Those skilled in the relevant art will recognize that many changes can be made to the embodiments described, while still obtaining the beneficial results of the present invention. It will also be apparent that some of the desired benefits 25 of the present invention can be obtained by selecting some of the features of the present invention without utilizing other features. Accordingly, those who work in the art will recognize that many modifications and adaptations to the 7 present invention are possible and may even be desirable in certain circumstances, and are a part of the present invention. Thus, the following description is provided as illustrative of the principles of the present invention and not in limitation thereof, since the scope of the present invention is 5 defined by the claims. The fare verification process is activated when a request is made to verify a travel ticket's price. Determining the price or reissue amount for a travel ticket is a complex process that uses many types of rules and restrictions some of which are included in Table 1. 10 TABLE 1 RULES RESTRICTIONS Eligibility Effective and Discontinue Date Time of Day Routing Day of Week Booking Class Season Flight Advance Purchase Purchase Within Minimum Stay Maximum Stay Stopover Transfer Combinability Blackout Surcharge RULES RESTRICTIONS Accompanied Travel Travel Date Sales Location and Security Fare Construction Discount Reissue Refund The fare verification process is driven by a request from a customer who wishes to have a verification of a travel itinerary. Additionally, it can be used to verify that a ticket that has been reissued has the correct reissue 5 price. The request can come in a variety of forms and can be sent by different media. For example, the request could be an Extensible Markup Language (XML) or EDIFACT message from the customer including the fare basis code(s) and ticket designator. EDIFACT is an acronym for "Electronic Data Interchange For Administration, Commerce, and Transport." EDIFACT is 10 an international standard for electronic data interchange that is still in widespread use in certain industries such as air travel and tourism because of the substantial investment in legacy software systems that leverage the EDIFACT standard. Generally, the request will include the travel itinerary which has the airline carrier, the flight number, the date and time of both 15 departure and arrival, the departure and arrival locations, and the class of service requested (the class of service is a method that airlines use to control the inventory of seats on an airplane). Travel itineraries may have multiple segments of travel with this information. Additionally, the request will contain 0 information about the passenger (e.g., adult, child, government worker, etc,), fares charged, taxes charged, possibly surcharges charged, as well as other types of charges related to the fare construction rules that are applied. Finally, the request will include information about how the itinerary was 5 priced, using fare basis codes, amounts and where fares were grouped together as a fare break. The first action of the fare verification process is to attempt to keep the original fare. The original fare may not be the lowest fare available. Sometimes a higher fare can be of benefit when upgrading to a different part 10 of the airplane cabin. Another reason to purchase a higher fare might be to avoid change fees at a later point in the trip. However, a reason for a higher fare may be due to the original fare not meeting the price rules and restrictions for that fare. Thus, the fares that were originally used to price the itinerary need to be verified to determine if they are acceptable. 15 The next step in keeping the original fare is to locate the fare basis code located in a fares database that was used in pricing the original fare. A fare basis code is a unique alphanumeric code assigned to a fare when the airline files a fare. Frequently, a fare basis code may have a ticket designator or fare modifier attached to the end of it. These fare basis code attachments 20 may signify a type of discount applied, or indicate a special program that might apply to this particular fare. These ticket designators or fare modifiers need to be removed so that the base fare basis code can be located in the fares database. These ticket modifiers or designators will be saved for possible later use. 25 If the base fare basis code can be located in the fares database, then the rules and restrictions process will begin. A fare basis code database will point to the rules and restrictions that apply to the particular fare. A complex 10 process of determining if the rules apply to the particular fare then begins. This process examines all of the components of the travel itinerary to verify that the rules are met. If any of the rules are not met, the type of rule that failed is noted and the process continues until all of the rules and restrictions 5 have been verified. If the rules and restrictions are verified as accurate, then the ticket designator or fare modifier may be used to match with a correct discount that may be applied, or a correct program that can be used for the fare. Finally, if all rules and restrictions were verified and applied without error, taxes are examined to determine if they have been collected correctly. 10 If all rules and restrictions were verified as accurate and taxes were collected correctly, the keep the fare process is done. An XML or EDIFACT message could then be returned to the customer advising that the fare verification passed (i.e., the original itinerary/ticket request is matched successfully). If the keep the fare process failed, then the reasons for failure are saved and 15 the second fare verification action is taken. Table 3 below provides a list of failure codes. If the base fare basis code cannot be located in the fares database, then it may be possible that the base fare is a special fare, such as a Category 25 fare. Category 25 fares may be based off a published fare, but the fare 20 amount may be discounted. If a Category 25 fare is not based off of a published fare, it may be a unique private fare. These special fares may use some of the published fares rules and restrictions or they may have their own unique rules and restrictions, or they may be a combination of base fare rules and unique Category 25 rules. At this point in the processing, it needs to be 25 determined which rules will be used in the keep the fare process. A complex process will begin of determining if the rules apply to that fare. This process will look at all of the components of the travel itinerary to verify that the rules 11 are met. If any of the rules are not met, the type of rule is noted and the process continues until all of the rules and restrictions have been verified. Finally, if all rules and restrictions were verified and applied without error, taxes are examined to determine if they have been collected correctly. If all 5 are verified as accurate the keep the fare process is done. If the keep the fare process failed, then the reasons for failure are saved and the second fare verification action is taken. The second action taken by fare verification process, if the fare could not be kept, is to look for the best possible alternative. This process will 10 consider the class of service that the itinerary used for each segment of travel, and classes above that class of service. This process is not limited to the fare that was originally used, but all eligible fares. These fares must pass all of the fare's rules and restrictions. If the rules and restrictions are verified as accurate, then the ticket designator or fare modifier may be used to match 15 with a correct discount that may be applied or a correct program that can be used for the fare. Finally, if all rules and restrictions were verified and applied without error, taxes are examined to determine if they have been collected correctly. If all are verified as accurate the best possible alternative fare process is done. The data generated by this second action will be saved and 20 reported via a web reporting tool. In an exemplary embodiment, during the preceding process, if the initial fare verification results in a failure, an XML or EDIFACT message can be returned to the customer advising the customer that the fare verification failed. This enables the customer to interrupt the ticket process. The 25 customer can then send another XML or EDIFACT message including override data. The fare verification process would then price the ticket using the current fares with equal or higher classes of service to determine the correct 1) itinerary/ticket amount. If the customer chooses to ignore the transaction, to use an auto-priced fare, or to recalculate a new price, the transaction will not appear in the web reports, but will pass through the audit process as a new transaction. 5 At the end of the fare verification process, it is determined whether or not the original fare could be kept. If it could not be kept, there will be reasons for the rules and regulations failure. Also, there will be a best possible fare that should have been used. All this information can be retained for reports and/or returned to the requestor. Ultimately, the verification 10 process will report back to the requestor about the verified itinerary. There are multiple ways for this report to be handled. In an exemplary embodiment, when the travel itinerary passes the audit (i.e., correct fares were used), verification that the fare audit passed is sent back to the requestor. The transaction is also counted in a cumulative daily total that can 15 be reported to the customer. When the fare used was not correct, then the rules violated will be reported and the best possible fare also will be reported. This reporting process can be used to stop or pause tickets from being issued with the wrong price. The reports can be used to identify fraud or mistakes that are occurring on tickets being issued. Many uses can be found for these 20 reports. Example reports are discussed further below. Exemplary processing logic for the fare verification process, corresponding to the preceding description, is illustrated in the flowcharts of Figs. 1 - 3. Although the steps of the process are described in a particular order herein, the steps can be performed in a different order, or without 25 performing all of the steps depicted. The processing begins in logic block 100 when a customer requests the verification of a travel itinerary for a passenger. The customer requesting the fare verification can typically be a ticket agent of the airline. Generally, the ticket agent will be an employee of the airline working at an airport ticket counter or a separately located airline ticket facility. In decision block 104, a determination is made as to whether or not the customer request is for a reissue ticket verification. If it is, the 5 reissue verification process illustrated in Fig. 4 is performed as indicated in logic block 108. Otherwise, processing continues in logic block 112. The test for reissue ticket fare verification in decision block 104 is an optional feature of the invention. The next step in the processing logic illustrated in Fig. 1 is removing 10 the ticket designator or fare modifier for the travel itinerary if either exists. The ticket designator/fare modifier needs to be removed in order to locate the base fare basis code in the fares database. The ticket designators/fare modifiers are saved for later use. The "keep the fare" process is then performed as indicated in logic block 116, and as illustrated in Fig. 2, 15 discussed below. Decision block 120 is a test for whether or not the fare could be kept. If the fare could be kept, a reporting process is initiated as indicated in logic block 132. For a positive outcome (i.e., fare verified as correct), the reporting process could be to simply track the number of fare verification requests and the number of positive outcomes for subsequent aggregate 20 reporting to the customer. If the fare could not be kept in decision block 120, information is gathered as to why the fare could not be kept as indicated in logic block 124. Processing then transfers to the "find the best fare" process illustrated in Fig. 3, discussed below. The reporting process is initiated in logic block 132 and can include sending a report back to the airline ticket 25 agent at the point of sale to interrupt the transaction to correct the fare for the travel itinerary. 1A Fig. 2 illustrates the processing logic for the "keep the fare" process in an exemplary embodiment initiated from logic block 116 in Fig. 1. Logic block 200 indicates the step of locating the fare for the travel itinerary in the fare database. Decision block 204 determines whether or not the fare is in the 5 fare database. If the fare for the travel itinerary is not in the fares database, the fare is located in a private special fares database as indicated in logic block 208. Category 25 fares, discussed previously, represent one such special fare having unique rules that could be used in this step. The applicable private rules and restrictions are then determined as indicated in 10 logic block 212. From either decision block 204 (fare in database) or logic block 212 (private rules and restrictions), the next step is to validate the rules and restrictions as indicated in logic block 216. Exemplary rules and restrictions are provided in Table 1 above. In decision block 220, a test is made to determine if a ticket designator 15 was used. If a ticket designator was used, it is applied to the travel rules as indicated in logic block 224. If it is determined that a ticket designator was not used in decision block 220, or if a ticket designator was applied in logic block 224, processing continues to decision block 228 for determination of whether or not the fare passed the set of rules and restrictions for the 20 particular fare. If the fare did not pass any of the rules and restrictions, the failure reason is saved, and the processing continues to validate the remaining rules and restrictions, as indicated in logic block 232. Exemplary failure codes are provided in Table 3 below. From logic block 232, processing transfers to Fig. 3 to find the best fares, as indicated in logic block 236. 25 In decision block 228, if the fare passed all rules and restrictions, the fare modifier previously saved is applied to the fare, as indicated in logic block 240. Taxes and other charges are then applied, as indicated in logic block 1i 244. The result is reported to the customer as indicated in logic block 248. In most instances, the result of the successful fare verification process will be accumulated for subsequent reporting, rather than transmitted to the point of ticket transaction. 5 In an exemplary embodiment, Fig. 3 illustrates the processing logic for the "find the best fare" process initiated from logic block 128 in Fig. 1 (logic block 236 in Fig. 2). Logic block 300 indicates the step of locating eligible fares for the travel itinerary in the fare database. As indicated in logic block 304, the rules and restrictions for the eligible fares are validated. In decision 10 block 308, a determination is made as to whether or not a ticket designator was used. If a ticket designator was used, it is applied to the rules as indicated in logic block 312. If a ticket designator was not used in decision block 308, or if the ticket designator was applied to the rules in logic block 312, the process then applies the fare modifier as indicated in logic block 316. 15 The best fare is selected from the eligible fares as indicated in logic block 320. Taxes and other charges are then applied as indicated in logic block 324. The best fare is then reported to the ticket agent as indicated in logic block 328 to complete the transaction. A process for validating reissued tickets is also available for 20 verification. Frequently, a traveler needs to modify his ticket after it has been issued. The calculations to reissue are often complex and difficult to verify. The reissue ticket verification process will take similar information as required for a regular ticket plus information about the old and new ticket. The travel itinerary for both the original ticket and the new (reissue) 25 ticket includes the airline carrier, the flight number, date and time of both departure and arrival, the departure and arrival locations, and the class of service requested (the class of service is a method that airlines use to control 14 the inventory of seats on an airplane). Travel itineraries may have multiple segments of travel with this information. Additionally, the request will contain information about the passenger (examples might be adult, child, government worker, etc.), fares charged, taxes charged, possibly surcharges charged, as 5 well as other types of charges related to the fare construction rules applied. Finally, the request will include information about how the itinerary was reissued using fare basis codes, amounts and where fares were grouped together as a fare break. The reissue ticket will attempt to keep the reissued fare. If the 10 reissued fare violates rules, then the rule violations will be reported. Reissue rules are the same as a regular ticket pricing, however there are additional rules related to how a ticket can be reissued and some of the refunding rules associated with reissues. When a ticket has been incorrectly reissued, a correct reissue amount will be calculated and reported. Reporting processes 15 can be used in many different ways. Similar to regular pricing a reissue that is taking place can be stopped until the correct reissue amount is charged, or a reason for the incorrect amount is given. As in regular price verification, reporting can be done outside of the flow of the transaction and may be used to identify fraud or mistakes that are being made. 20 Fig. 4 illustrates the processing logic for the "reissue fare" process in an exemplary embodiment initiated from logic block 108 in Fig. 1. Logic block 400 indicates the step of locating the original fare and reissue fare for the travel itinerary in the fares database. Decision block 404 determines whether or not the original fare and reissue fare are in the fares database. If the 25 original fare and reissue fare for the travel itinerary are not in the fare database, the original and reissue fare are located in a private special fares database as indicated in logic block 408. Category 25 fares, discussed 17 previously, represent one such special fare having unique rules that could be used in this step. The applicable private rules and restrictions are then determined as indicated in logic block 412. From either decision block 404 (fares in database) or logic block 412 (private rules and restrictions), the next 5 step is to validate the rules and restrictions for the reissue fare process as indicated in logic block 416. In decision block 420, a test is made to determine if a ticket designator was used. If a ticket designator was used, it is applied to the reissue fare rules as indicated in logic block 424. If it is determined that a ticket 10 designator was not used in decision block 420, or if a ticket designator was applied in logic block 424, processing continues to decision block 428 for determination of whether or not the reissue fare passed the set of rules and restrictions for the particular fare. If the reissue fare did not pass any of the rules and restrictions, the failure reason is saved, and the processing 15 continues to validate the remaining rules and restrictions for the reissue fare, as indicated in logic block 432. Exemplary failure codes are provided in Table 3 below. From logic block 432, the process transfers to Fig. 5, as indicated in logic block 436, to find the best reissue amount. In decision block 428, if the reissue fare passed all rules and 20 restrictions, a fare modifier can be applied to the fare, as indicated in logic block 440. Taxes and other charges are then applied, as indicated in logic block 444. The result is reported to the customer as indicated in logic block 448. In an exemplary embodiment, each successful reissue fare verification transaction will be counted for subsequent reporting, rather than transmitted 25 to the point of ticket transaction. Each fare verification transaction that fails (i.e., an error is detected) can be reported in real time to the customer via a web reporting tool. 12~ Fig. 5 illustrates the processing logic for the "find the best reissue amount" process in an exemplary embodiment initiated from logic block 436 in Fig. 4. Logic block 500 indicates the step of locating eligible fares for ticket reissues in the fare database. As indicated in logic block 504, the rules and 5 restrictions for the eligible reissue fares are validated. In decision block 508, a determination is made as to whether or not a ticket designator was used. If a ticket designator was used, it is applied to the reissue rules as indicated in logic block 512. If a ticket designator was not used in decision block 508, or if the ticket designator was applied to the reissue rules in logic block 512, the 10 process then applies the fare modifier as indicated in logic block 516. The best reissue amount is selected from the eligible reissue fares as indicated in logic block 520. Taxes and other charges are then applied as indicated in logic block 524. The best reissue amount is then reported to the ticket agent as indicated in logic block 528 to complete the ticket reissue transaction. 15 An exemplary embodiment of the network architecture for the air fare verification system is illustrated in Fig. 6. A ticket agent 10 communicates over a high speed communication link 15 with a computer reservation system (CRS) 20 for specific flight information to create a travel itinerary, and receives the requested information which is then relayed to the passenger in 20 order to book a particular flight or flights with a particular class of service. The ticket agent 10 can book the flight and class of service if seats in the class are available. Although only a single ticket agent is shown in Fig. 6, there are no limitations on the number of ticket agents, the physical locations of the ticket agents, or the type of ticket agents (airline ticket agent, travel agency 25 ticket agent, supervisor, manager, etc.). Likewise, the computer reservation system 20 can represent a plurality of separate computer reservation systems 10 provided by airlines or global distribution system providers, such as Worldspan and Galileo. A typical passenger name record (PNR) for an automatically priced fare that would show on the ticket agent's computer screen is depicted in Fig. 7A. 5 The annotations indicate that the PNR is booked in coach (Y) class of service and automatically priced by the computer reservation system at $1,528. The computer reservation system 20 can communicate over a high speed communication link 25 with fare verification system 30 in response to a request from the ticket agent 10. The fare verification system 30 provides a 10 response to the ticket agent 10 via high speed communication links 16, 26. The fare verification system provides audit reports over a wideband communication network (e.g., the Internet) 40 to a customer audit department 50 via communication links 35, 45. Fig. 7B illustrates the ticket agent 10 overriding the valid automatically priced fare of Fig. 7A by manually 15 adjusting the fare price using a Q class of service, for which the fare is $478. The fare verification system 30, in response to a fare verification request, could return a message such as that depicted in Fig. 7C indicating that the fare failed verification. In an alternative embodiment, the network system illustrated in Fig. 6 20 does not include a separate communication link 16 for providing a fare verification response to the ticket agent 10. In this alternate embodiment, the customer 50 requests an audit report for a ticket transaction initiated by the ticket agent 10. The request can be sent over communication link 46. An audit report can also be sent automatically from the verification system 30 to 25 the customer 50 for every ticketing transaction initiated by ticket agent 10. The verification system 30 verifies the airline fare for the transaction, but does not send a response back to the ticket agent 10 to interrupt the transaction. )n Instead an audit report is transmitted from the verification system to the customer 50 via the wideband network 40 and communication link 45 immediately following completion of the ticketing transaction. This alternative embodiment is appropriate for situations in which the customer wants to 5 monitor ticket agent performance for educational or training purposes, but does not want to interrupt the ticketing process. Web reporting allows the transactions identified in the audit process to be available online for review within minutes. Each responsible area within the customer's company can then follow-up on the tickets in question and 10 determine why each ticket was under/over-priced (e.g., training, mistake, fraud, etc.). Documentation and reports can be used to reduce/stop errors, remove employees from positions in which they have the ability to commit fraud, and reduce the number of fare waivers/favors. The task of stopping revenue leakage on internally issued tickets is not easy. The fare verification 15 process allows companies to audit, follow-up and/or stop the transaction, but it also takes a firm commitment from all areas within the company to successfully begin to eliminate this type of revenue loss. There can be multiple levels of reporting. For example, a first level of reporting can include all transactions that failed the audit. A second level of 20 reporting can include all transactions that failed the audit and were overridden subsequently by the customer. Several reports can be made available to the customer including aggregate reports, location reports, and specific location reports. An aggregate report is designed for senior management to review 25 revenue dilution/leakage by location type. Examples of location types include all reservations, all airport ticket offices and all city ticket offices. Fig. 8 illustrates an exemplary aggregate report. The location report is designed for 21 the next level of management to review revenue dilution/leakage one level down from the aggregate report. This report enables the user to review dilution/revenue leakage by each city and location type. Fig. 9 illustrates an exemplary location report. The aggregate and location reports would be 5 displayed typically in the default airline currency (e.g., USD, EUR). The specific location report is designed for the supervisor/station manager to review/follow-up with the agent who issued the ticket in question. Each transaction appearing on the specific location report is accompanied by the specific details required to review the transaction with the agent (e.g., 10 Record Locator, Ticket Number, Agent ID, Waiver Code, Amount, Failure Code, etc.). The specific location report could be displayed typically in the default airline currency and/or the local currency. The specific location report would be available to view one city and one location at a time. In addition, the specific location report could have a web filter to allow further 15 customization of the display presented to the customer. Fig. 10 illustrates an exemplary specific location report. Table 2 identifies standard data for the specific location report. TABLE 2 20 Carrier Code Country City Type of Location (e.g., RES, ATO, CTO) 25 Record Locator Ticket Number Agent ID Discrepancy Type: U = Under priced itinerary, 30 0 = Overpriced itinerary, P = Fare Calculation/Parser error, E = Fare Basis Code Error -unable to match FBC in message to FBC in Ticket Pricing System Currency 35 Discrepancy Amount (Amount PNR Is Under/Over Priced) Total Fare For Transaction (Total Old Fare) 9)91 Total Fare Determined By Fare Verification System (Total New Fare) Fail Code (see list of fail codes in next section) Fare Basis Ticket Designator Waiver Code 5 Passenger Name Override Indicator Local / Ticketing Date and Time Zulu Time For Ticketing 10 Exemplary failure type codes that can be used in the specific location report are shown in Table 3. TABLE 3 FAILURE CODE EXPLANATION 1 Fare Basis Code Not Found 2 Invalid Fare Amount 3 Invalid Booking Code 4 Routing 5 Invalid Fare For PTC 6 Taxes/Fees 7 Invalid OA Booking Code 10 Sales Restriction 11 Travel Date 12 Advance Purchase 13 Minimum Stay 14 Stopover 15 Day/Time 16 Transfers 17 Maximum Stay 18 Blackout 19 Seasonality 20 Purchase Within 21 Flight Application 22 Combinability 15 The specific location report can be customized by the customer by addition of extra fields for each transaction. For example, a field could be used for follow-up with the agent issuing a transaction to explain the corrective action that was taken. The data provided on all reports is available within minutes via the web reporting tool. This enables the customer to discuss a transaction in question with the ticket agent in near real time. 5 Embodiments of the invention described herein provide unique benefits to the customer. These benefits include, but are not limited to, the capabilities (1) to audit the price of the travel itinerary during the ticketing transaction rather than after the transaction has taken place; (2) to alert the agent making the ticket transaction in real-time that the fare being collected 10 is not correct before any revenue is lost; and (3) to provide near real-time reports (i.e., in time proximity to completion of the ticketing transaction) via a web reporting tool for all ticket transactions sent through the verification system that are ticketed for the wrong amount. Without the fare verification system described herein, customers can conduct audits only after ticketing 15 transactions are completed. The customer has no ability to regain the lost revenue. Using embodiments described herein to verify ticketing transactions enables the customer to eliminate or greatly reduce revenue leakage since a real-time response is displayed to the customer in order to correct the price prior to completing the transaction. 20 The system and methods of the present invention have been described as computer-implemented processes. It is important to note, however, that those skilled in the art will appreciate that the mechanisms of the present invention are capable of being distributed as a program product in a variety of forms, and that the present invention applies regardless of the particular type 25 of physical signal bearing media utilized to carry out the distribution. Examples of signal bearing media include, without limitation, recordable-type media such as diskettes or CD ROMs.

The corresponding structures, materials, acts, and equivalents of all means plus function elements in any claims below are intended to include any structure, material, or acts for performing the function in combination with other claim elements as specifically claimed. Those skilled in the art will 5 appreciate that many modifications to the exemplary embodiments are possible without departing from the scope of the present invention. In addition, it is possible to use some of the features of the present invention without the corresponding use of the other features. Accordingly, the foregoing description of the exemplary embodiments is provided for the 10 purpose of illustrating the principles of the present invention, and not in limitation thereof, since the scope of the present invention is defined solely by the appended claims.

Claims (12)

1. A computer program product for air fare verification and auditing for a travel itinerary associated with a ticketing transaction when executed on a computer processor, comprising a non-transitory computer 5 readable medium having computer readable code embedded therein, the computer readable medium comprising: program instructions that receive a request via a communications network to verify that the air fare for the travel itinerary has been priced correctly; 10 program instructions that determine if the air fare for the travel itinerary is in a fares database; program instructions that validate a plurality of rules and restrictions applicable to the air fare; program instructions that determine if the air fare passes each 15 of the plurality of rules and restrictions and verify the air fare has been priced correctly if each of the plurality of rules and restrictions is satisfied; program instructions that provide a verification response for the air fare verification request via the communications 20 network, wherein the verification response provides an electronic notification to a recipient of any pricing error made during the ticketing transaction; and program instructions that automatically provide an audit report following completion of the ticketing transaction via the 25 communications network, the audit report including an indication of any pricing error.

2. The computer program product for air fare verification and auditing of claim 1 further comprising program instructions that save and report a failure reason for each rule and restriction that is not satisfied by the air fare, if the air fare did not pass all rules and restrictions applicable 5 to the air fare.

3. The computer program product for air fare verification and auditing of claim 1 further comprising program instructions that determine a best fare among a plurality of eligible fares, if the air fare did not pass all 10 rules and restrictions applicable to the air fare.

4. The computer program product for air fare verification and auditing of claim 1 further comprising program instructions that remove a ticket designator associated with the air fare and apply a pricing adjustment 15 associated with the ticket designator if the air fare passes each of the plurality of rules and restrictions.

5. The computer program product for air fare verification and auditing of claim 1 further comprising program instructions that remove a fare 20 modifier associated with the air fare and apply a pricing adjustment associated with the fare modifier if the air fare passes each of the plurality of rules and restrictions.

6. The computer program product for air fare verification and auditing of 25 claim 1 further comprising program instructions that interrupt the ticketing transaction if the air fare did not pass all rules and restrictions applicable to the air fare.

7. The computer program product for air fare verification and auditing of claim 1 further comprising program instructions that search a published fares database. 5

8. The computer program product for air fare verification and auditing of claim 1 further comprising program instructions that search a special fares database.

9. The computer program product for air fare verification and auditing of 10 claim 8 further comprising program instructions that determine a plurality of rules and restrictions that are applicable to the special fares.

10. The computer program product for air fare verification and auditing of 15 claim 1 further comprising program instructions that determine if the received request is for a reissue ticket verification.

11. The computer program product for air fare verification and auditing of claim 10 further comprising: 20 program instructions that locate a plurality of eligible fares for the reissue ticket request in the fares database; and program instructions that select a best reissue amount from the plurality of eligible fares for the reissue ticket request. 25

12. A computer program product for air fare verification and auditing for a travel itinerary associated with a ticketing transaction when executed ')0 on a computer processor, substantially as herein described with reference to the accompanying drawings.