Abstract:
Systems for managing pricing proposals and associated options in the travel industry with respect to the provision of travel services or products. The system is capable of communicating with a booking engine and a global distribution system (GDS), and is operable by a reservation agent. An itinerary pricing User Interface determines an itinerary for one or more predetermined passenger, segment, and option combinations, sends one or more informative pricing requests to the GDS, and receives as a result of the requests one or more pricing proposals for each predetermined passenger, segment and option combination from the GDS. A pricing summary module and User Interface stores each pricing proposal, such that the one or more pricing proposals are available for subsequent use. The pricing summary User Interface provides an intuitive representation of the one or more pricing proposals in order to compare the pricing proposals.

Description:
PRIORITY CLAIM 
       [0001]    This application claims the benefit of European Patent Application No. 11306492, filed Nov. 15, 2011; the disclosure of which is incorporated herein by reference in its entirety. 
       FIELD OF THE INVENTION 
       [0002]    The present invention relates to a method and system for generating and using a price summary, particularly in respect to the travel industry. 
       BACKGROUND OF THE INVENTION 
       [0003]    All the major ecommerce portals provide pricing applications that allow a user to add selections to a virtual shopping cart. The total price is then calculated for the products in the shopping cart. The prices of the objects contained in the shopping cart are fixed and as such the price of the shopping cart content is simply calculated as the sum of the prices of the objects in the shopping cart. A pricing strategy (for example the fact that two objects were added to the cart at the same moment) has no bearing on the computation of the total price of the cart content. 
         [0004]    Pricing applications for air itineraries allow an end-user to price air segments that have been added to a Passenger Name Record (PNR). The reservation agent decides how to group the passengers and segments when performing a pricing operation. The price for a PNR is determined through several pricing commands and the agent can add pricing options to each command. Existing pricing applications for air itineraries are based on a fully manual and iterative procedure and do not provide automation or convenient comparison capabilities. 
         [0005]    Due to the complexity of pricing airline fares, air itinerary pricing is a process which differs from the shopping cart pricing process described above. 
         [0006]    The final price of an air itinerary in a PNR (i.e. the final price that the customer will pay when the tickets are issued) may depend on how the segments and passengers are grouped during the pricing process, as well as on the pricing options used. Each group of segments that has been priced together will correspond to a ticket when the ticket or tickets are eventually issued. For example, a two segment itinerary, such as a round trip, can be priced and ticketed using one of at least two pricing strategies. 
         [0007]    In a first strategy, the outbound and inbound legs may be priced together and the total price is equal to PR 1 . When the ticket is issued, it is a single ticket covering the whole itinerary. In a second strategy the outbound leg is priced and is equal to PR 2 . The inbound is priced and is equal to PR 3 . When the ticket is issued two separate tickets are provided. In general, the total price for two separate legs and a round trip are not the same. 
         [0008]    As a result, a pricing method and system aimed at finding the lowest price for a given air itinerary cannot be as simple as that required for ecommerce. The pricing process cannot be reduced to a process of adding items to a shopping cart and calculating a total price as the sum of the prices of the objects in the cart. 
         [0009]    The current methodology for pricing air itineraries is also not user friendly or intuitive due to the need to compare different pricing proposals and different pricing strategies for a given itinerary. 
         [0010]    Typically, a reservation agent using such an application will perform several different pricing commands. The commands will change the manner in which the agent groups segments, passengers, passenger grouping and pricing options. For each different pricing command the agent will note down the abovementioned options and the results on a piece of paper; and compare them and perform sum operations manually; in order to be able to find the best pricing proposal. It is necessary to note down this information in case the customer decides to proceed to the issuance of a ticket corresponding to the pricing proposal. If this is the case, at present, the agent will have to repeat the set of commands (including the segments and passenger grouping and the pricing options used) in a “confirmed” mode in order to create a pricing record and issue the ticket. 
         [0011]    In the travel domain travel agents often receive enquiries from users for a price or proposal for a travel service or product. In response to the request the travel agent conducts a search to find appropriate results as described above. These results are communicated to the user often by telephone and, as previously mentioned, a note of the results is kept by the agent in case the user subsequently wishes the product or service identified by the travel agent to be issued. The manner in which the travel agent keeps a note of the results can vary from person to person. It is often merely a handwritten note kept in a notebook or a Post-it™ stuck to the computer. It is subsequently difficult, if a user wishes to purchase a particular product or service, to identify the exact result that was earlier identified by the travel agent. In addition, the agent will need to re-play all the pricing commands in order to confirm the pricing proposal that was previously identified and create the pricing record, prior to proceeding to the ticket issuance. 
         [0012]    The present systems are very much hit and miss and the agent is required to keep notes and information and then repeat searches once a customer has decided to purchase a particular ticket. If the request for the purchase of the ticket is taken by a different agent from the one who took the first enquiry, the problem may be compounded still further. The second agent will have no information about the nature of the proposals proposed to the customer and will probably be unable to find precisely the same combination as the previous agent. As a result, the customer may not be able to purchase the proposal they were previously offered. 
         [0013]    The prior art does not address the problems of keeping information available and accessible for future use the proposal as previously created. In addition, the prior art fails to solve many of the other existing problems. 
       OBJECTS OF THE INVENTION 
       [0014]    It is an object of the present invention to overcome at least some of the problems associated with the prior art. 
         [0015]    It is a further object of the present invention to provide a method and system which allows a travel agent to retain information relating to pricing proposals for subsequent use. 
       SUMMARY OF THE INVENTION 
       [0016]    The present invention provides a method, system and computer program as set out in the accompanying claims. 
         [0017]    According to one aspect of the present invention there is provided a system for managing pricing proposals and associated options in the travel industry with respect to the provision of travel services or products, wherein the system is capable of communicating with a booking engine and a global distribution system (GDS), the system being operable by a reservation agent, wherein the system comprises:
       an itinerary pricing User Interface for determining an itinerary for one or more predetermined passenger, segment and option combinations, sending one or more informative pricing requests to a GDS and receiving as a result of the requests one or more fares for each predetermined passenger, segment and option combination from the GDS; and   a pricing summary module and User Interface for storing the one or more fares and build one or more pricing proposals, so that the one or more pricing proposals are available for subsequent use, such as issuing a ticket associated with one or more of the pricing proposals, wherein the pricing summary User Interface provides an intuitive representation of the one or more pricing proposals in order to compare the pricing proposals.       
 
         [0020]    For the avoidance of doubt Informative pricing refers to a preview of price information which relates to a real price. The real price then can be used if a customer subsequently requests issuance of a ticket. 
         [0021]    The term fare as used herein is intended to include a combination of a fare basis and an associated price. The fare basis is a code which is represented by an alphanumeric sequence for identifying a type of fare and the associated price is a numerical value of the cost if a ticket associated with the fare is subsequently issued. 
         [0022]    Optionally, the results of the informative itinerary pricing request and input parameters used to generate the informative itinerary pricing request are stored in the pricing summary module. 
         [0023]    Optionally, the pricing proposal comprises a set of results of informative pricing results, such as a fare and a set of input parameters that were used to generate each informative pricing result. 
         [0024]    Optionally, comparison of the pricing proposals is based on a price criteria or an attribute of the fare composing the pricing proposal. 
         [0025]    Optionally, the pricing summary User Interface can be used to trigger the confirmation of the selected pricing proposal via the pricing confirmation module. 
         [0026]    Optionally, the system further comprises a pricing confirmation module for confirming, on request, via the pricing summary User Interface, one or more pricing proposal and automatically repeating the steps necessary for creating one or more pricing record needed to issue the ticket corresponding to the one or more pricing proposal. 
         [0027]    According to a second aspect of the invention, there is provided a method for managing pricing proposals and associated options in the travel industry with respect to the provision of travel services or products, operating on a system capable of communicating with a booking engine and a global distribution system (GDS), and being operable by a reservation agent, wherein the method comprises:
       determining via an itinerary pricing User Interface an itinerary for one or more predetermined passenger, segment and option combinations from the GDS by sending one or more informative pricing requests to the GDS and receiving as a result of the requests one or more pricing proposals for each predetermined passenger, segment and option combination from the GDS;   storing via a pricing summary module and User Interface the one or more pricing proposals for each predetermined passenger, segment and option combination, such that the one or more pricing proposals are available for subsequent use, such as issuing a ticket associated with one or more of the pricing proposals, wherein the pricing summary User Interface provides an intuitive representation of the one or more pricing proposals in order to compare the pricing proposals.       
 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0030]    Reference will now be made, by way of example, to the accompanying drawings, in which: 
           [0031]      FIG. 1  is a diagram for showing the relationship between the travel agent and GDS, in accordance with an embodiment of the invention; 
           [0032]      FIG. 2  is a sequence diagram of a first part of the process, in accordance with an embodiment of the invention; 
           [0033]      FIG. 3  is a sequence diagram of the second part of the process, in accordance with an embodiment of the invention; and 
           [0034]      FIGS. 4 to 14  are a variety of screenshots demonstrating various stages of the process, in accordance with an embodiment of the invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0035]    The present invention relates to a travel pricing process, for any kind of ticket, product or service priced via an automated pricing system (also referred to as the “system” in the rest of this document). 
         [0036]    The invention enables a professional reservation agent (airline or travel agent) to compute and/or compare, in a user friendly way, different pricing proposals for the same itinerary in order to determine the most convenient and cost-effective option for the customer. In addition, the invention provides an automated mechanism for conserving pricing information relating to different proposals. This automated process enhances agent productivity and reduces the error risk. In addition, it is easier for an agent to identify the priced proposals and be able to confirm these proposals for the customer. This is particularly the case where a second agent conducts the second part of the process, namely confirming a proposal for a customer that has previously been provided by a first agent. 
         [0037]    One of the primary concerns of the present invention is the concept of a pricing summary. In order to more clearly describe the present invention, it is helpful to define certain terms. 
         [0038]    A passenger name record (PNR) contains data relating to a number of passengers (P i , P j  . . . ) and a number of air segments (Sa, Sb, . . . ). The first required definition is the price of an air itinerary for a given PNR. The price of the air itinerary for the PNR record identified above is a possible price of the air tickets issued to all passengers in the PNR, covering. all the air segments (Sa, Sb, . . . ). 
         [0039]    A second definition is the definition of informative pricing command, this is a command that takes as its input a subset of the passengers and the air segments in the abovementioned PNR. Pricing options are then determined and combined to produce a specific output price, which is applicable just for the combination of passengers and air segments in the initial input for informative purposes. 
         [0040]    A third definition is the definition of a pricing proposal. This is the result of one of the possible sets of informative pricing commands that an agent can execute to obtain a price for the air itinerary for the above-mentioned PNR. As will be described below, this can be represented graphically. 
         [0041]    A fourth definition is the pricing summary definition. The pricing summary is essentially a container of a limited number of different pricing proposals. This container helps the reservation agent to compare and contrast different pricing proposals in order to find the most suitable for the air itinerary in a particular PNR. Further details of the pricing summary will be described in greater detail below. 
         [0042]    Referring to the drawings, particularly  FIGS. 4 to 14 , various phases of a pricing scenario are described. The screenshots show the various features of the travel agent tool which forms part of the present invention. The system enables the travel or reservation agent to execute a number of informative pricing commands. Once the agent has received relevant information relating to one or more pricing proposals, which correspond to the results of informative pricing, the pricing proposals are depicted in the three tabs “Pricing  1 ”, “Pricing  2 ”, “Pricing  3 ” in the pricing summary  408  shown in  FIG. 4 . The agent may carry out a number of different informative pricing commands and the information relating to each is stored in the system by means of parameters such as the passenger selection, segment selection, pricing options, etc. 
         [0043]    These parameters are shown on the screenshots along with other parameters that may equally be of value in determining and storing information relating to a pricing command. The screenshots will be described in more detail below. 
         [0044]    For a particular itinerary the agent can build multiple pricing proposals. Each pricing proposal can be built using different sets of options or grouping the legs of a journey in different ways, or using any other appropriate factor. Each pricing proposal may result in a different combination of fares so that the total price of the air itinerary for the PNR may be different from one proposal to another. The two or more pricing proposals can be stored in the pricing summary. When a pricing proposal is stored, the system will store all the information needed to allow the construction of the pricing proposal itself. This information may include passenger selections, segment selections, pricing options, etc. In addition, when the pricing proposals are added to the pricing summary the agent will be able to compare them easily and choose the best proposal to meet the user&#39;s needs. 
         [0045]    Prior to ticket issuance, the agent will need to create persistent data in the system which stores the price associated with the ticket that will ultimately be issued. This data is referred to as a pricing record. 
         [0046]    When the agent wants to proceed to ticket issuance, a pricing proposal is selected for confirmation. All the informative pricing commands and associated input parameters (segment and passenger selection, pricing options, etc) are replayed in a mode that triggers creation of the pricing records that are necessary to issue the ticket. These pricing records will persist within the system. It should be noted that the informative pricing does not create any persistent data. Should there be any errors these will be reported as either a success or failure of a particular transaction. 
         [0047]    As previously indicated, the invention relates to a system and process for an agent to iterate informative pricing commands and store these commands and their results in a convenient manner in order to retrieve the information later.  FIG. 1  shows a simple use case flow diagram to illustrate the basic steps and processes carried out. A travel agent  100  has access to the pricing summary system of the present invention, screenshots of which are shown in  FIGS. 4 to 14 . The pricing summary system includes an informative itinerary pricing module  102  and a pricing summary module  104 . The informative itinerary pricing module is in communication with the global distribution system (GDS) and obtains the informative itinerary pricing results for a number of different pricing commands. The pricing summary module  104  adds fares in a pricing proposal  106 . In addition, fares can be removed from the pricing proposal  108  and the agent is able to compare pricing proposals  110  in a user friendly environment. At the same time, or in a subsequent step, a pricing proposal confirmation  112  may be carried out by the agent. This causes the system to replay all the pricing commands, using the passenger selections, segment selections, pricing options, etc that have been saved when the pricing proposal was generated. Options may include class, extras etc. When a pricing proposal is confirmed, the system will replay the pricing commands no longer in the informative mode, and a persistent pricing record will be created in the system. 
         [0048]    The agent will be able to prepare a plurality of pricing proposals each using different pricing strategies. Different pricing proposals that are associated with different prices for a given PNR may come from a number of different pricing strategies. These strategies include: pricing domestic segments separately from international segments; pricing each airline independently; using specific pricing options, such as Passenger Type Code (PTC) override forcing the fare breakpoint, searching for specific discounts etc; pricing the full itinerary for all passengers; or any other appropriate strategy. An example of a PTC override is using a different PTC than the initial PTC definition for the passenger in the PNR, such as a military adult rather than an adult. 
         [0049]    The different pricing proposals, with all their associated data, are added to the pricing summary  104  to be stored and to be available for analysis, comparisons and confirmation. The pricing summary makes comparison of the different pricing strategies much simpler than previous systems and methods. There is no need for the agent to perform any manual calculations and the quality of the service that the agent can provide the customer is increased, due to the fact that the most suitable price for a particular itinerary can be easily identified. In addition, the price that the agent communicates to the customer will be accurate and easily retrievable at a later date for pricing proposal confirmation, as described above. 
         [0050]    Referring now to  FIG. 2 , the pricing proposal sequence diagram will now be described. This adds further detail to the abovementioned steps and sets out the messages and steps required in the process.  FIG. 3  shows similar messages and steps for the pricing confirmation sequence also described above. 
         [0051]    Referring to  FIG. 2 , a travel agent  200  is in communication with the booking engine  202 . This in turn behaves as middleware between the agent and a global distribution system (GDS)  206 . The booking engine includes an informative pricing module or service  204 , a pricing summary module or service  205 , and a pricing confirmation module or service ( 207 ). The pricing summary module contains one or several pricing proposal modules  206 . The informative pricing service and the pricing confirmation service, which reside in the booking engine, handle the communication between the booking engine and the GDS. A User Interface allows the interaction between the agent and the booking engine by providing a graphical representation of the pricing summary and pricing proposals. The User Interface also provides the controls that allow use of informative pricing services and pricing confirmation services. 
         [0052]    The travel agent determines an itinerary to price at step  208 . The PNR data pertaining to the itinerary that needs to be priced is fetched by the booking engine from the session data at step  210 . The booking engine uses the PNR data to build the price itinerary request that is fed to the informative itinerary pricing service at step  212 . The informative itinerary pricing service formats the informative itinerary pricing request complying with the GDS API at step  214  and sends it to the GDS. The itinerary informative pricing request is sent to the GDS at step  216  and a response is generated at step  218 . The informative itinerary pricing service returns the fares to the booking engine in step  220  where they are stored in step  222 . The return fares are then communicated to the travel agent at step  224 . The travel agent adds the selected fare or fares to the price proposal at step  226 . 
         [0053]    The booking engine fetches the fare data at step  228  and the fares are added to the price proposal in the pricing summary  205  at step  230 . A fare storage representation is carried out at step  232  and a pricing narrowing option is carried out at step  234 . The fares are then stored in pricing proposal module  206  in a step  236 . The pricing proposal module carries out a consistency check step  238 . The pricing proposal module returns an operation status message to the pricing summary module in step  240  and the return pricing summary content is returned to the booking engine at step  242 . The pricing summary content view is updated and presented to the travel agent  200 . 
         [0054]    The query at step  208  is made up of a set of parameters and options. The parameters include the segments that are selected such as Sa, Sb and the parameters include passenger selections, such as P i , P j . 
         [0055]    Additionally, global pricing (Og) options are sent, such as Point Of Sale (POS), Point Of Ticketing (POT), ticketing date, taxes, fees etc. Some options (Os) can be associated to segments, such as fare breakpoints. Further, some options (Op) can be associated with passengers, such as discount passenger, type override and airline discounts etc. As an example, for a PNR composed of three passengers P 1 (ADT), P 2 (ADT), P 3 (CHD) and two segments S 1 , S 2 , an informative itinerary pricing query encompassing all passengers and all segments, could be quoted as follows: 
         [0000]      PricingQuery=[{P1,P2,P3},{S1,S2},Og,Os,Op] 
         [0056]    An informative Itinerary Pricing Reply, such as response  218 , is made up of a list of fares, each of which is applicable for one or several passengers. As an example, a fare that applies to passengers P 1  and P 2  (i.e. P 1  and P 2  are eligible for fare F 1 ) can be quoted as follows: 
         [0000]      F1{P1,P2} 
         [0057]    An informative Itinerary Pricing Reply holding three available fares for ADT passengers and three available fares for CHD passenger could thus be quoted as follows: 
         [0000]      PricingReply=[F1{P1,P2},F2{P1,P2},F3{P1,P2},F4{P3},F5{P3},F6{P3}] 
         [0058]    The invention provides a graphical representation as a result of the steps of storing informative itinerary pricing reply in the pricing proposal(s). The agent selects one or more fares contained in the informative pricing reply and generates one or more pricing proposals. For a given fare the pricing proposal may relate only to a subset of the eligible passengers. 
         [0059]    An important element of the fare storage representation in the pricing proposal is a high degree of coupling between a given fare and the originator pricing options. The fare is always stored in a pricing proposal together with the originator&#39;s pricing options. 
         [0060]    As previously mentioned, only a subset of eligible passengers may be selected while adding a fare to the pricing proposal. Returning to the earlier example, if the pricing reply is: 
         [0000]      PricingReply=[F1{P1,P2}] 
         [0000]    the Agent may want to add the Fare F 1  to the Pricing Proposal just for Passenger P 1  despite the fact that P 1  and P 2  are both eligible. This is an advantage of the present invention, which allows fares to be stored for each passenger in the pricing proposal. In the above example what is actually stored in the Pricing Proposal is: F 1 {P 1 }. On the other hand, if the agent adds the fare to all the eligible passengers, one fare will also be stored in the pricing proposal for each passenger. 
         [0061]    Returning again to the example, if the pricing reply is: 
         [0000]      PricingReply=[F1{P1,P2}], 
         [0000]    and if the Agent wants to add F 1  in the Pricing Proposal for both P 1  and P 2 , what is actually stored in the Pricing Proposal is: 
         [0000]      F1{P1},F1{P2} 
         [0062]    The ability to be able to adapt the pricing proposal as described above makes the pricing proposal management provided by the present invention considerably more flexible than previous systems and methods. The price option narrowing step  234  not only makes use of the fact that each fare applies to the single passenger and that each fare is linked to a specific pricing option, but also takes into account the fact that the informative itinerary pricing query may include passenger associated pricing options. The following informative Itinerary pricing query will now be considered by way of example. 
         [0000]      PricingQuery=[{P1,P2,P3},{S1,S2},Og,Os,O1p1p2,O2p3] 
         [0000]    Where: O 1 p 1 p 2  are the pricing options associated to P 1  and P 2 ; and O 2 p 3  is the pricing option associated to P 3 . 
         [0063]    Assuming the agent wishes to apply a discount to the passengers, for example, the same discount can be requested for both ADT passengers (P 1  and P 2 ) and a different discount requested for the CHD passenger (P 3 ). The corresponding informative itinerary pricing reply would be updated as follows: 
         [0000]      PricingReply=[F1{P1,P2},F2{P1,P2},F3{P1,P2},F4{P3},F5{P3},F6{P3}] 
         [0064]    F 1 , F 2 , and F 3  relate to the fares for the combination of passengers P 1  and P 2 . F 4 , F 5  and F 6  relate to fares for passenger P 3 . If the agent decides to add F 1  for both P 1  and P 2  and F 4  for P 3  in the Pricing Proposal the invention will apply a pricing option narrowing strategy to ensure that, whenever necessary, each fare is stored with its originator options narrowed to its own context. Returning once more to the example, what is actually stored in the Pricing Proposal is: 
         [0000]      F1{P1} linked to [{P1},{S1,S2},Og,Os,O1p1] pricing options 
         [0000]      F1{P2} linked to [{P2},{S1,S2},Og,Os,O1p2] pricing options 
         [0000]      F4{P3} linked to [{P3},{S1,S2},Og,Os,O2p3] pricing options 
         [0065]    It is possible that certain pricing options may be replicated where several fares are returned by the same informative itinerary pricing query. In addition, pricing options are linked to the context of each fare for the passengers involved. The duplication and linkage can produce a memory overhead. The present invention can rectify this by making links for shared instances and using cloning in order to create as few new instances as possible. 
         [0066]    Despite the fact that storage of the present invention has been optimized, a correlation link is maintained to identify fares which come from the same informative itinerary pricing command. This has advantages in both the pricing proposal management and the subsequent pricing proposal confirmation processes. 
         [0067]    The pricing proposal is intended to be confirmed and converted into one or several pricing records at some point in time. The pricing records will be later used to issue ticket documents and the construction and confirmation of one or several pricing proposals is in fact a type of ticket document issuance path. 
         [0068]    Generally, a ticket issuance system will only issue one ticket document for a given passenger and a given segment (or a given set of segments). This rule is taken into account all along the whole document issuance path. As a result, overlapping fares which could ultimately result in overlapping ticket images should be avoided. The present invention avoids overlapping fares and tickets by ensuring that only one fare is added to the pricing proposal for a given combination of passenger and segment (or segments). This feature gives rise to an advantage in the preparation of ticket issuance and avoids inconsistent pricing proposal contents from an early stage. By way of example, if the agent requests an informative itinerary pricing query as follows: 
         [0000]      PricingQuery=[{P1,P2,P3},{S1,S2},Og,Os,Op1p2p3] 
         [0000]    and receives the following reply: 
         [0000]      PricingReply=[F1{P1,P2},F2{P1,P2},F3{P1,P2},F4{P3},F5{P3},F6{P3}] 
         [0000]    then the following listed operations will fail:
 
a) Adding F 1 {P 1 }+F 2 {P 1 } to a pricing proposal at the same time. This would fail because there is an overlap of the fares F 1  and F 2  to be added.
 
b) Adding F 1 {P 1 } and then F 2 {P 1 } to the pricing proposal. This would fail because of the overlap between the fare F 1  already present in the pricing proposal and the fare F 2  to be added.
 
         [0069]    A consistency check may be carried out between the pricing proposal contents and the pricing records if necessary. 
         [0070]    The present invention also provides a mechanism for removing one or more fares from the pricing proposal container or pricing summary. Fares obtained from a single informative itinerary pricing query may need to be grouped together. As a result, removal of those fares must also be grouped together. The correlation link between fares coming from the same informative itinerary pricing query enables a warning to be issued to the agent in such circumstances so that the group is treated as a whole. 
         [0071]    Referring now to  FIG. 3 , the pricing confirmation sequence will now be described. The travel agent  300  is in communication with the booking engine  302 , which behaves as a middleware between the agent and the GDS  307 . The booking engine features an informative pricing module or service (also referred to as a pricing proposal module)  306 , a pricing confirmation module or service  308 , and a pricing summary module or service  304 . The pricing summary module contains one or several pricing proposal modules  306 . 
         [0072]    As previously mentioned, the informative pricing service and the pricing confirmation service, which reside in the booking engine, handle the communication between the booking engine and the GDS. A User Interface allows the interaction between the agent and the booking engine by providing a graphical representation of the pricing summary and pricing proposals. The User Interface also provides the controls that allow use of informative pricing services and pricing confirmation services. 
         [0073]    In a first step  312 , the travel agent identifies in the User Interface the pricing proposal which is to be confirmed. Then the agent requests pricing confirmation of the selected pricing proposal to the pricing summary module in step  314 , via the User Interface. The pricing summary module retrieves the pricing proposal contents from the pricing proposal module  306  in step  316 . The pricing proposal module returns the fare in step  318 . In step  320 , the pricing summary module requests fare confirmation via the pricing confirmation service. The pricing confirmation service groups the fares by compatibility and affinity in step  322 . The number of transactions is optimized in step  324 . The itinerary informative pricing request is sent to the GDS in step  326  and responses generated in step  328 . The pricing confirmation service checks fare validity at step  330 . A confirmation and pricing record creation message and pricing record creation request are sent to the GDS in a step  322  and a confirmation status is returned from the GDS to the pricing confirmation service module at step  334 . The pricing confirmation service builds a status report for each fare at step  336 , which is then communicated in a status report in step  338  to the pricing summary module. The pricing summary module forwards the status report at step  340  to the booking engine, where PNR data synchronization occurs at step  342 . At step  344  either a synchronized PNR view is communicated to the agent  300 , via the User Interface, or in case of error an error message will be presented. 
         [0074]    The pricing proposal confirmation process converts fares contained in pricing proposal into a pricing record. Due to the self-sufficient fare storage representation described above the pricing proposal holds all the necessary data to enable fare confirmation to be carried out. The process of converting pricing proposals to pricing records is transparent and integrated and the steps are not visible to the agent. For certain use cases, additional operations may be required to confirm a fare. In this case, options are presented to the agent for selection and the system continues to operate based on the responses given. 
         [0075]    As previously mentioned the present invention attempts to minimize the number of informative itinerary pricing queries sent at the time of confirmation of the pricing proposal. In order to do this, the system builds as few as possible pricing queries (i.e. optimizing the number of pricing queries needed by combining several pricing queries in one when possible) as is described below, with reference to an example. Assuming the agent has made a first request as follows: 
         [0000]      PricingQuery=[{P1,P2},{S1,S2},Og,Os]       the system may then return the following reply:         
         [0000]      PricingReply=[F1{P1,P2}]       Subsequently, the agent adds the following fare to the pricing proposal:         
         [0000]      F1{P1}+F1{P2}       The agent then requests a further pricing query for an additional passenger as follows:         
         [0000]      PricingQuery=[{P3},{S1,S2},Og,Os]       In this case, the system replies:         
         [0000]      PricingReply=[F′1{P3}]
       The agent can then add the following fare to the pricing proposal:       
 
         [0000]      F′1{P3}
       The resultant contents of the pricing proposal are now as follows:       
 
         [0000]      F1{P1} linked to [{P1},{S1,S2},Og,Os] pricing options 
         [0000]      F1{P2} linked to [{P2},{S1,S2},Og,Os] pricing options 
         [0000]      F′1{P3} linked to [{P3},{S1,S2},Og,Os] pricing options
 
         [0082]    When the pricing proposal is confirmed the system determines that the three fares are compatible in terms of pricing options even though they come from distinct pricing transactions. As a result, only one informative itinerary pricing query will be sent when the pricing proposal confirmation process is carried out. This informative itinerary pricing query is as follows: 
         [0000]      PricingQuery=[{P1,P2,P3},{S1,S2},Og,Os] 
         [0083]    The above scenario can be augmented by the following example. An Agent requests informative pricing S 1 , S 2  for P 1 , P 2 , to be added to the pricing summary. The system will store F 1  Informative Pricing for P 1  ( 51 , S 2 ) and P 2  (S 1 , S 2 ). The agent now requests Informative pricing S 1 , S 2  for P 3 , which is added to pricing summary. The system will store F 1 ′ for P 3  (S 1 ,S 2 ) pricing  3 . At the time the agent performs the confirmations, the system will not redo the three transactions above. The system optimizes the combination of the transactions, if possible assuming combinable pricing elements (Og, Os) and similar selections (i.e. S 1  and S 2 ) are being used. In this case, the system will prepare one pricing transaction rather than three, with the following resulting in [{P 1 , P 2 , P 3 }, {S 1 , S 2 }, Og, Os as above. 
         [0084]    Once the pricing proposal confirmation process has completed, the system will report the status associated with each fare contained in the pricing proposal. If for any reason a fare has failed, an error message will be identified to the agent thereby allowing the agent to effect the necessary corrective action and subsequently confirm the pricing proposal. In this case, the system will only deal with the previously failed fares and ignore the previously successful ones. 
         [0085]      FIGS. 4 to 14  show screenshots of various stages of operation of the system of the present invention, in respect of an illustrative example. 
         [0086]    Referring initially to  FIG. 4 , the screenshot shows a pricing window User Interface  400  into which a travel agent can request informative pricing for a travel itinerary. The pricing window includes pricing options in which fields are identified. The fields include passenger names and passenger types (PTC)  404 , and detailed flight information  406 . The agent can select the different passengers and different sectors for which the system is required to return different proposals in respect of fares. Additionally, the agent can input pricing options, in association with the selected passengers and sectors. Among the possible options the agent can decide to override the passenger PTC, force a fare breakpoint, search for specific discounts etc. Also the agent can, in association with the selected passengers and sectors, request advanced options such as force the application/exemption of some fees, waive some taxes, etc. After selecting passengers and sectors and defining all the pricing options, the agent can request the informative pricing. The screenshot also shows a price summary  408  which can be used to store the results of the informative pricing at the request of the travel agent. 
         [0087]    The results of informative pricing can be stored in the pricing proposals that are shown as “Pricing  1 ”, “Pricing  2 ” and “Pricing  3 ” in price summary  408 . Each time an informative pricing result is stored in a pricing proposal contained in price summary  408 , all the selected passengers and sectors, as well as all the options associated to the informative pricing request are stored. 
         [0088]      FIG. 5  shows a similar screenshot to  FIG. 4 , in which a fare has been returned as shown at  500  as the result of an informative pricing request. The agent can select button  502  to add the fare to pricing proposal “Pricing  1 ” of the price summary. 
         [0089]      FIG. 6  shows how the fares have been introduced into the price summary as shown at  600 . The details from the fare  602  have been transferred into the price summary. This is stored with the associated pricing option so that this fare can be later selected by the agent if purchase of this fare is required. 
         [0090]      FIG. 7  shows the informative pricing for all passengers but just for sectors one and two  700 . This generates a further fare  702  which can be added to pricing  2 ,  704  in the pricing summary  706 . The agent can select the preferred fare  708  to be added to the price summary by the button  710 . 
         [0091]      FIG. 8  shows the selected fare updated in the pricing summary of pricing tag  2 ,  800 .  FIG. 9  shows the screenshot for identifying the informative pricing for all passengers on sectors three only and adding this fare to the pricing summary  2 ,  900 .  FIG. 10  shows the updated pricing summary  1000  including the informative pricing for all passengers and all segments (one, two and three). 
         [0092]      FIG. 11  shows the pricing summary for pricing  1  and pricing  2  tabs, representing two different pricing proposals. These views can be used by the agent to compare the pricing proposal  1  and  2  for all passengers and all segments where the informative pricing has been carried out by means of flights encompassing all sectors for the pricing proposal  1 ; and flights encompassing first and second sectors in one informative pricing and the third sector in the second informative pricing in pricing proposal  2 . 
         [0093]    Based on the overall fare for each pricing proposal the agent selects pricing proposal  2  as shown in  FIG. 12 . Pressing the confirm price button  1200  will automatically replay all the informative pricing requests in a mode that triggers creation of the pricing records. The informative pricing requests include associated input parameters such as segment and passenger selection and pricing options. This is different to the informative pricing which does not create any persistent data. 
         [0094]    The pricing records will persist into the system and are mandatory elements in order to issue tickets. Pricing proposal confirmation may be carried out at the same time as the pricing proposal is generated or escalated at a later time, as the pricing proposal retains the information until deleted. 
         [0095]      FIG. 13  shows a detailed view of the pricing summary window. The pricing summary includes pricing proposal navigation  1300 ; informative pricing for passenger  1 , with the subtotal  1302 ; and informative pricing for passenger  1  and segments two and three which can be potentially deleted  1304 . In addition, the pricing summary includes the pricing confirmation button  1306  as previously described. 
         [0096]      FIG. 14  shows the error message presented to the agent where the agent attempts to add a fare to a pricing summary related to passengers and segments already present in the pricing summary. 
         [0097]    The invention can be extended to any kind of process involving several informative transactions to be computed and assembled into proposals that can be compared among each other before confirmation. The expertise of the agent remains a key value of the process. The system provides the needed automation to avoid mistakes when the agent wants to confirm a proposal. 
         [0098]    A person skilled in the art will understand that some or all of the functional entities as well as the processes themselves may be embodied in software, or one or more software-enabled modules and/or devices, or in any combination thereof. The software may operate on any appropriate computer or other machine. The operation of the invention provides a number of transformations, such as the changes to the summary, as information is added; conversion of data to a ticket, etc. 
         [0099]    In one exemplary implementation, the subject matter described herein can be implemented using a non-transitory computer readable medium having stored thereon a computer program comprising instructions for carrying out any of the methods described herein. For example, any of the modules and engines described herein may be implemented in software embodied in a non-transitory computer readable medium and executed by a processor. Exemplary computer readable media suitable for implementing the subject matter described herein include disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. In addition, a computer readable medium that implements the subject matter described herein may be located on a single device or a computing platform or may be distributed across plural devices or computing platforms. 
         [0100]    This invention has been described with reference to the purchase of tickets in the travel environment. However, it will be appreciated that the invention may apply to other environments. It will be appreciated that this invention may be varied in many different ways and still remain within the intended scope of the invention.