KR20150118895A - Electronic miscellaneous document handling in response to voluntary modifications of ancillary services - Google Patents

Abstract

The present invention relates to methods, systems, and computer program products for handling electronic miscellaneous documents in response to voluntary modifications of services. A request, which includes first data for a passenger name record, is received for the airline reservation change. Second data for a first electronic miscellaneous document, which is linked to the first data for the passenger name record, is also received. A determination is made as to whether the first electronic miscellaneous document can be exchanged by applying at least one exchange eligibility rule to the first and second data. If the first electronic miscellaneous document can be exchanged, a fare for a service associated with the first electronic miscellaneous document is obtained from a pricing engine associated with the first electronic miscellaneous document. In response to receiving the fare for the service, the passenger name record is updated with a second electronic miscellaneous document including the fare for the service.

Description

TECHNICAL FIELD [0001] The present invention relates to an electronic payment certificate (EMD) handling method and system corresponding to a voluntary correction of an incidental service,

The present invention relates generally to computer and computer software, and more particularly to a method, system, and computer program product for handling the exchange of an electronic miscellaneous document (EMD) in response to a voluntary modification of a service.

An electronic payment certificate (EMD) is issued for a travel-related service that includes an airline's individual services. Generally, two distinct types of electronic payment can be issued. Standalone electronic payment certificates (EMD-S) are not issued with standard flight tickets. The standalone electronic payment card may be issued for a non-air bag service, such as a car voucher or lounge access, but is not associated with a flight coupon. An associated electronic payment certificate (EMD-A) may be issued for an oversubsidized baggage, sports equipment, premium seats, or supplementary services such as meals or drinks. The associated electronic payment card is directly associated with the flight coupon for the flight segment.

The customer may choose to change one or more of the initially-planned subscription services associated with the electronic payment or exchange flight tickets. Voluntary changes initiated by these customers involve modifications to the original electronic payment card issued to the customer. The issuing travel agent of the original electronic payment can handle the voluntary change and provide the customer with a new document validating the modification of the electronic payment. Travel agents can manually update electronic payments through a series of long, complicated and error-prone actions that require a wealth of service pricing knowledge combined with knowledge of the exchange use cases. Service prices, balances, taxes, and many other parameters can be affected by voluntary change requests and must be redetermined according to the requested change. A new price record can be generated that includes a reference to the original document and information about each new service.

Re-pricing of electronic payments is relatively complicated compared to re-pricing flight tickets. Among other reasons, the price of the new electronic payment, among other parameters, is the price of the service at the exchange time, the price of the electronic payment to be exchanged, and the price of the new flight ticket, if any, It depends on the price. Thus, it is possible to perform eligibility checks, determination of new prices, deduction of remaining amounts in electronic payments to be exchanged, generation of price records with appropriate original document references, and management of arbitrary penalties and residual values Represents some time-consuming and error-prone steps taken by travel agents.

What is needed is an improved method, system, and computer program product for handling the exchange of electronic payments in response to a voluntary modification of the service.

Embodiments of the present invention generally include methods, systems, and computer program products for responding to changes in airline reservations. A request containing the first data for a passenger name record is received for a change in airline reservation. Second data for the first electronic payment certificate linked to the first data for the passenger name record is also received. Whether or not the first electronic payment certificate can be exchanged by applying at least one exchange eligibility rule to the first data for the passenger name record and the second data for the first electronic payment certificate Is determined. If the first electronic payment certificate can be exchanged, a service charge associated with the first electronic payment certificate is obtained from a pricing engine associated with the first electronic payment certificate. In response to receiving the service charge, the passenger name record is updated with a second electronic payment certificate containing the service charge.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments of the present invention and, together with the general description of the invention given above and the detailed description of the embodiments given below, It plays a role.
1 is a schematic diagram of an exemplary operating environment including a plurality of computer systems;
Figure 2 is a schematic diagram of the exemplary computer system of Figure 1;
3 is a block diagram of an exemplary service changer system in accordance with one embodiment of the present invention.
Figures 4A and 4B are flow diagrams of a process performed in an input analyzer component in accordance with an embodiment of the present invention.
5 is a sequence diagram according to an embodiment of the present invention.
6 is a diagram showing data provided by various components and a database to determine a new price record;
Figure 7 shows a passenger name record after rebooking a voluntary change and after re-booking a voluntary change.
Figures 8A and 8B illustrate electronic payments after re-booking spontaneous changes and before re-booking spontaneous changes associated with the passenger name record of Figure 7;

Embodiments of the present invention provide a service change system, method and system for automatically handling an update of an electronic payment in response to a voluntary change initiated by a passenger for a flight ticket associated with an incidental service and / Computer program product. The service change system performs complex transactions by collecting data from a variety of different sources, adapting the collected data to a single record, collecting and processing one or more changes of the electronic payment to multiple passengers simultaneously into a single question . The service change system provides a flexible layout in the user graphical user interface that identifies the services affected by this change and makes the associated documents exchangeable. The travel agent can only partially select (or not at all) the services, electronic payments and passengers for which each exchange applies. By automatically analyzing associations between all elements in the context, information that is not explicitly entered by a travel agent can be deduced automatically. The service modification system may be operated on various price engines by providing an interface that adapts the question to the specificities of each individual price engine.

1, the operating environment 10 includes one or more global distribution systems (GDS) 12, one or more client devices 14, one or more travel agent systems 16 that constitute an indirect selling system, One or more airline systems 18, a service change system 20, and one or more price engines 22 that constitute a carrier system. The GDS 12, the client device 14, the travel agent system 16, the airline system 18, the service change system 20 and the price engine 22 may be connected to the network 24. The network 24 may include one or more private networks and / or public networks (e.g., the Internet) that enable the exchange of data.

Each GDS 12 provides communication between the airline system 18 and the travel agent system 16 and searches through the GDS 12 for travel products available to a travel agent, a validating carrier, or other indirect merchant May be configured to book reservations to one or more airline systems (18). To this end, each GDS 12 may maintain a communication link to each airline system 18 via the communications network 24. [ These communication links enable the GDS 12 to obtain the travel product schedule and availability data from the airline system 18. Whereby each travel agent system 16 can book flights, trains, hotels, rental cars or other travel products from multiple service providers over a single connection to the GDS 12.

In response to the trip product being bookmarked, the GDS 12 may receive and store information about the travel product in a passenger name record (PNR). This PNR may be generated, at least in part, by the airline system 18, and may include one or more reservation records comprised of the interval and traveler data associated with the one or more bookkeeping reservations. The PNR interval may be active, for example, (e.g., for a service provided by a corresponding service provider), (for example, for a service reserved by another system or provided by a third party) It can be identified as passive, past, flown, information, open or canceled (e.g., for purchased services with an open date). The PNR may be stored in a database accessible to the GDS 12, the airline system 18, the travel agent system 16, and the service change system 20. The PNR may be identified by a record locator that is unique to each PNR and may include intervals that define a travel itinerary for a particular trip, service, passenger, or group of passengers. The itinerary may include services in a number of airlines (e.g., flights, buses, or trains), hotel reservations, rental car reservations, or any other travel-related services.

Each airline system 18 may include a computer reservation system (CRS) and / or a billing system for each service provider. The CRS allows each GDS 12 and / or each travel agent system 16 to book a ticket service, such as a flight, train service, hotel room or rental car, and associated service associated with the ticketed service. Each airline owns or operates an airport ticket office (ATO) and a city ticket office (CTO) and may sell tickets for themselves and / or other airlines. Price engine 22 may be hosted in airline system 18 or GDS 12, but each is associated with a particular airline. Each airline system 18 may include a reservation system that allows the airline ticketing office, GDS 12, and / or travel agent system 16 to locate, book, and pay for airline tickets.

Each travel agent system 16 may include a server application, such as a web server, which provides a web site accessible by the public. This website can be configured to provide access to travel plan features such as the ability to search for travel products that match the travel request. To this end, each travel agent system 16 may be configured so that the traveler can access data in one or more databases hosted by the GDS 12, the travel agent system 16, and / or the airline system 18.

Each client device 14 may be any suitable computing system configured to communicate over the network 24. [ Each client device 14 may be a desktop, laptop or tablet computer, a smart phone, a personal digital assistant (PDA), or any other removable or stationary device that allows a traveler to search and book travel services via the network 24. [ Computing device. For example, each client device 14 may include a client application, such as a web browser, that communicates with a server application hosted by one travel agent system 16, such as a web-server. The server application may communicate with the GDS 12, the travel agent system 16 and / or the airline system 18 and obtain data relating to travel services available to the traveler to book the travel service and to enable the electronic document to be issued.

The GDS 12 may access one or more document databases and store and retrieve data associated with electronic tickets or other electronic documents associated with the purchased service. For example, the service modification system 20, which may be hosted by the GDS 12 or the airline system 18, may be configured to handle the exchange of electronic payment certificates (EMD) in response to a voluntary passenger modification of the reservation have. The service change system 20 is provided by an airline IT solution provider who can provide the network infrastructure for the operating environment 10 and that can provide hardware and software components for online transactions involving ticket sales and incidental services . All or a portion of the service modification system 20 may be integrated into one or more other systems, such as one GDS 12. [

Each EMD may include one or more electronic coupons, at least stored in a document database accessible to the service modification system 20, wherein each coupon corresponds to a service provided by the EMD. In response to one or more electronic coupons being used, exchanged, or refunded, the document database may be updated to reflect a change in the status of the electronic document.

2 provides a block diagram illustrating components of one or more servers of a computer system that may include a service modification system 20 in accordance with one embodiment of the present invention. The service change system 20 is a system that is created and triggered by a direct or indirect channel, i.e., via a client device 14 or from a cryptic terminal or a GUI terminal It can receive and process voluntary change requests that are generated and triggered through the airline website.

The service modification system 20 includes at least one processor 122 that includes at least one hardware-based microprocessor and a memory 124 that is coupled to the at least one processor 122. The memory 124 may include random access memory (RAM) including the main storage medium of the service change system 20 and any supplemental level of memory, e.g., cache memory, non-volatile memory, or backup memory For example, a programmable or flash memory), a read-only memory, or the like. Further, the memory 124 may include any cache memory located physically somewhere in the service change system 20, e.g., a microprocessor, and any storage capacity used as virtual memory, for example, Stored in a mass storage device or stored in another computer connected to the service modification system 20. [

The service modification system 20 may include a user interface 126 including one or more user input / output devices, e.g., a keyboard, pointing device, display, printer, and the like. The data may be transferred to other computers or terminals (e.g., GDS 12, client device 14, travel agent system 16, airline system 18) via network interface 128 connected to communication network 24. [ And the price engine 22). The service change system 20 may also communicate with one or more mass storage devices, which may be, for example, an internal hard disk storage device, an external hard disk storage device, an external database, a storage area network device,

The service change system 20 generally operates under the control of the operating system 130 and relies on or depends upon various computer software applications, components, programs, objects, modules, engines, data structures, In particular, these components include an input analysis component 202, a data management component 204, a multi-pricing engine manager component 206, and a pricing engine connector component 210 and may include instructions that may be present and / or stored in the memory 124. [

The service change system 20 may include, for example, one or more databases, including a price engine configuration database 208 and a pricing record configuration database 212. Each database 208, 212 may include data and support data to store and organize data. In particular, each database 208, 212 may be arranged in any database organization and / or structure, including but not limited to relational databases, hierarchical databases, network databases, and / or combinations thereof. A database management system in the form of a computer software application executed as an instruction in the processing unit of the service modification system 20 may be used to access information or data stored in the records of the databases 208 and 212 in response to a database query.

Furthermore, various applications, components, programs, objects, modules, engines, and the like, may also be executed on one or more processors in another computer connected to the service change system 20 via the communications network 24, Lt; RTI ID = 0.0 > and / or < / RTI > in a distributed or client-server computing environment where the processing required to implement the functionality can be assigned to multiple computers over the network. For example, some of the functions described herein as being included in the service change system 20 and / or components of the service change system 20 may be implemented in one or more servers. In accordance with an embodiment of the present invention, a component, module, application, and / or engine may be executed on one or more servers of the service change system 20 and the processor 122 of the service change system 20 Thereby enabling the operation according to the embodiment to be performed.

Figure 3 shows a block diagram of one embodiment of a service change system 20. The service modification system 20 may be configured to perform an operation of handling a voluntary service change in response to the traveler or passenger making a decision to request a change in his or her initial reservation. A voluntary change request is generated and triggered by a direct or indirect channel, that is, generated and triggered through an airline website or GUI / cryptic terminal, shown collectively as the client terminal 280. The service modification system 20 includes an electronic ticket stored in the process accompanying document, for example, an electronic ticket stored in the ticket database 220, an EMD stored in the EMD database 230, and a generic document stored in the document database 240. [ And various databases that store information about PNR type reservations stored in the PNR database 250 or other types of records stored in the generic record database 260. [ The database 220, 230, 240, 250, 260 may be similar in organization and structure to the price record configuration database 212 and the price engine configuration database 208. The databases 220, 230, 240, 250, 260 may be hosted in one or more of the GDS 12 and / or the airline system 18.

Each EMD stored in the EMD database 230 is an electronic document that can be issued in response to a traveler purchasing an incidental service. The EMD may be consulted to determine whether the traveler is eligible to receive the incidental service. Exemplary services to which an EMD may be issued include an allowance to carry additional luggage, a special zone (e.g., a business lounge), a meal or beverage during a travel segment (e.g., a flight) Or to select a particular seat (e.g., a seat with a window seat, a passage side seat, a seat with a special leg room, etc.), a transportation service between the airport and the hotel, Including the eligibility to receive

Each PNR stored in the PNR database 250 may include traveler data providing the traveler's reservation details, other data related to the traveler's trip, and data supporting airline personnel to treat the passenger. In general, certain data found in PNRs may include traveler's name, passenger type code, data identifying one or more booked travel segments, traveler contact information, when and where the ticket was issued, and the ticketing office or employee who made or updated the reservation . ≪ / RTI > When an EMD is issued for an adjunct service, the PNR may be updated with data associating the PNR with the EMD. Whereby the travel service provider can associate an interval within the PNR with the EMD for the corresponding supplementary service purchased by the traveler.

The service modification system 20 is further connected to various pricing engines 214, 216, 218 configured to provide rules and billing information associated with the fees in a format suitable for processing by a computer. The price engine 214, 216, 218 may be based on an airline tariff publishing company (ATPCO) or other heterogeneous external airline pricing system. The content and mode of operation of the service change system 20 are further described with reference to Figs.

The service modification system 20 includes an input analysis component 202 configured to verify the validity of a voluntary change request. The input analysis component 202 is configured to receive a voluntary change request from one client terminal 280. [ The request to be processed may require the execution of one or more exchanges, each exchange being made from one or more EMDs for one or more services for a given passenger.

The service information to be included in the exchange may be either explicitly selected by the employee / passenger in the request, or automatically identified from the change request situation by a process executed by the input analysis component 202. Based on the passenger name record, the input analysis component 202 retrieves one or more original EMDs associated with the passenger airline reservation from the EMD database 230, and the spontaneous change request exchanges one or more original EMDs To determine if it is eligible, or alternatively, to reject the request. The input analysis component 202 is also configured to issue a notification to the client terminal to originate a request to notify the verification or rejection of the voluntary change request.

After the validity check process 300 described below with respect to FIGS. 4A and 4B, the voluntary change request is further processed by the data management component 204. FIG. In general, the data management component 204 includes a new price record linked to the new EMD that is linked to the passenger name record and includes all updates and prices for all changes, and the associated pricing elements (E.g., issuance, endorsement, etc.) of the user. In addition to the price records that make up the basis of the reissued EMD, in accordance with the re-price output, the data management component 204 determines the residual value of a particular amount that is not used for the exchange but which can be returned back to the passenger, Lt; RTI ID = 0.0 > a < / RTI >

The data management component 204 is further connected to a pricing record configuration database 212. The price record configuration database 212 stores price record configurations of various airlines.

The data management component 204 is further connected to a multi-price engine manager component 206 that is operable to receive PNR data (e.g., PNR data) that selects the correct price engine 214, 216, 218 corresponding to the EMD to handle And airline rule information. The multi-price engine manager component 206 is coupled to a price engine configuration database 208, which stores parameters that allow for airline configuration rules, elements, and price selection. For example, an airline may be configured to always determine a price for its service through an ATPCO submission, whereas another airline may want its dedicated system to be the only one that performs a price determination for that service . The airline may also have its policy to determine the price for the service through ATPCO, except for upgrades, for example, which are priced on a mile-by-mile basis through its own system.

The multi-price engine manager component 206 is further coupled to the price engine connector component 210 to interface with the price engine 214, 216, 218. The price engine connector component 210 is capable of being formatted with each airline configuration rule and sends a re-price question to the price engine 214, 216, 218 and receives a response with the calculated price from the queried price engine . The pricing engine connector component 210 also collects the data obtained from each pricing engine 214, 216, 218 and configures it as a common model and provides it back to the data management component for finalizing the exchange process.

4A and 4B illustrate process flows performed in an input analysis component 202 in accordance with an embodiment of the present invention. A voluntary change request is received by the service change system 20 at block 302. All data required for the exchange process, including the service and passenger information affected by the voluntary change, is collected. As described above, the input analysis component 202 performs the validation of the requested exchange. If the change request does not define all the elements involved in the exchange, the process automatically retrieves the missing information (via blocks 308, 316, 320, and 328 of the process flow).

After receiving the voluntary change request, the service modification system 20 determines whether all the passengers whose exchange is to be performed by the appropriate passenger selection from the staff at block 304 have been identified in the request. If the passenger selection is explicitly mentioned (yes branch), the validity of the passenger selection is checked in block 306. For example, if a passenger is present in a situation and the request is generally coherent with the situation (for example, the request is referred to as "pax infant 1 & "Exists but is for an adult), the check fails. If the passenger selection is not valid, the service modification system 20 rejects the transaction (block 340). Otherwise, control is transferred to the block 310 by the service changing system 20.

If no passenger selection is mentioned in the request (no branch at block 304), all passengers who are subject to the current change situation are automatically retrieved by the service change system 20 at block 308. [ After the blocks 304, 306, 308 belonging to identifying the passenger, the validity of the change request is checked by the service change system 20 at the service level by controlling several eligibility criteria.

At block 310, the service change system 20 checks to determine whether a new service is mentioned in this request. If a new service is mentioned, that is, if the service is present in the context, or if the service is associated with the selected passenger, the validity of the service selection in the request is checked by the service change system 20 (block 312). If the service selection is not valid, the service change system 20 rejects the transaction (block 340). Otherwise, the service change system 20 passes control to block 314.

At block 314, the eligibility of the selected service for the spontaneous change is checked. If the service is not valid, the transaction is rejected (block 340). Otherwise, the service change system 20 passes control to block 318. [ Eligibility may be limited through several rules that determine the services that can be targeted by the exchange and those that can not be targeted by the exchange. For example, all sub-services that can not be priced can be excluded from the exchange. Other eligibility rules may be based on the date of the attachment service, for example, a date-based service may be excluded from the exchange.

If the subscription service is not explicitly selected in this request at block 310, the service in the PNR is filtered using the predefined eligibility criteria to discard the non-eligible service from the exchange process (block 316). Control is transferred by the service change system 20 to the block 318 shown in FIG. 4B.

At block 318, it is determined by the service switching system 20 whether the EMD (s) are explicitly limited to this request. If the EMD (s) are explicitly qualified in this request, the service modification system 20 checks the validity of the EMD selection in the request (block 322). For example, the service changing system 20 checks whether this selection has been performed by referring to the PNR. If the selection is present and corresponds to an EMD, or if the selection is an EMD number, the service modification system 20 checks if this selection is present in the EMD database 230. If the EMD selection is not valid, the transaction is rejected (block 340). Otherwise, the service change system 20 passes control to block 324. [ At block 324, the service change system 20 performs a test to check whether the request provides a mapping between the document and the service. For example, the mapping in this request may include two separate lists with one list having EMDS and the other list having services, or a list such as "EMD1-SRV1-2, EMD2-SRV3-4" , And an association list between the EMD and the service.

If the EMD (s) are not explicitly defined or referenced in this request at block 318, all EMDs involved in the current change situation are automatically identified by the service change system 20, Lt; RTI ID = 0.0 > 20 < / RTI > The service change system 20 passes control to block 324. [

At block 324, if the service change system 20 does not find a mapping document in this request, the service change system 20 passes control to block 326. [ Otherwise, control passes to block 325. [ At block 325, the service change system 20 performs a test to determine the validity of this mapping. If the mapping is not valid in this mapping document, the transaction is rejected (block 340). For example, multiple services may be requested to be included in the same exchange, but if these services do not have the same RFIC code, they are not in the same price record, so the mapping is considered invalid. If the mapping is valid in the mapping document, the service modification system 20 transfers control to block 330. [

If no mapping document is provided in the incoming request received at block 326, the service modification system 20 will determine its own mapping between the EMD and the service based primarily on its association with the passenger. The service change system 20 performs a test to determine whether a single mapping document can be selected in the current change situation. If a single mapping document can not be selected, the service modification system 20 transfers control to block 338 to determine whether the mapping operation can be determined at a later stage of the exchange process. This may be the case, for example, where it is not possible to infer all exchanges from the PNR and to provide a feature that the price engine calculates a mapping based on an amount balance. If the mapping can not be deferred, the transaction is rejected (block 340); Otherwise, the service change system 20 passes control to block 330. [

If the test results in block 326 provide a single mapping document, the service change system 20 automatically determines the mapping document to be applied to the exchange request (block 328). At block 330, the service change system 20 automatically retrieves the EMD to be selected for the voluntary change request from the EMD database 230.

At block 332, the service modification system 20 performs a test to check the eligibility of each EMD retrieved at block 330 based on a predefined eligibility rule. For example, an EMD that already has a coupon for an exchanged or reissued status is not eligible for a current request for a voluntary exchange. In the unqualified EMD, the transaction is denied (block 340); Otherwise, in an eligible EMD, the service change system 20 passes control to block 334. [ At block 334, the service modification system 20 prepares the updated PNR for each passenger. For example, if a previous price record exists in an existing PNR for a re-bocked service, they are deleted. After the updated PNR is prepared for each passenger, the exchange process continues at block 336. [

Referring to FIG. 5, a sequence diagram illustrating an input message and an output message exchanged between components according to an exemplary embodiment of the present invention is shown. This sequence diagram shows the interaction between objects in a sequence in which the interaction takes place.

In the message 402, a voluntary service change request is received at the input analysis component 202 of the service change system 20. The content of the request is analyzed and the eligibility of the request is checked by the service change system 20 as described with reference to Figure 4a. The input analysis component 202 queries the EMD database 230 with the message 404 to retrieve the EMD corresponding to this request. The data representing the EMD is sent back to the input analysis component 202 as a message 406. Upon receiving the EMD data, the input analysis component 202 completes the entire request checking process and prepares the PNR following this process as described in FIG. 4B.

The input analysis component 202 provides the PNR data to the data management component 204 of the service change system 20 as a message 408. The data management component 204 performs the task of collecting all the data that performs the EMD exchange by operating the next sub-process as a whole. The data management component 204 retrieves the configuration of the price record from the price record configuration database 212 to the message 409. The data management component 204 sends a request to the multi-price engine manager component 206 to retrieve the re-pricing information in the message 410. The multi-price engine manager component 206 retrieves the price engine selection rules from the price engine configuration database 208 in message 411 to identify the price engines 214, 216, and 218 to query for exchange. The multi-price engine manager component 206 is designed to handle a number of existing situations in re-pricing services according to the aviation industry, since not all airlines provide prices for air and incident services in the same manner. While some airlines use ATPCO submissions, other airlines store their price rules locally on their own servers and provide an interface for GDS (12) to access price rules.

The price engine selection rules and PNR data are transmitted from the multi-price engine manager component 206 to the price engine connector component 210 of the service change system 20 in a message 412. The pricing engine connector component 210 performs formatting the re-pricing query in the format required by each pricing engine interface. The price engine connector component 210 sends a re-price question to at least one of the price engines 214, 216, 218 identified for re-pricing as a message 414, And receives the calculated charge.

The computed charge is passed to the data management component 204 as a message 418, 420, which performs the task of aggregating all the data. After receiving the calculated charge, the data management component 204 of the service modification system 20 receives the data used to populate a new price record in which the reissued EMD is generated. The data management component 204 updates the PNR that contains the pricing record and all associated pricing elements used in the issuing process (original issuance, authorization, etc.). In addition to the price record that forms the basis of the reissue EMD, a residual value record may be generated by the data management component 204 in accordance with the re-price output. The result may be a residual value EMD that is not used for the exchange but includes the amount that can be returned to the passenger in accordance with the airline rules and practices. The PNR database 250 is updated with the new price record in message 422 and the acknowledgment is returned in message 424 as a data management component 204 update. The updated PNR is sent from the data management component 204 to the input analysis component 426, which forwards the spontaneous change processing result to the client terminal 280 in a message 428.

6 illustrates aggregating all of the data provided to the data management component 204 by various components and databases to form a new price record 500. [

Referring to FIG. 7, there is shown an exemplary PNR with a PNR 600 existing before re-booking accompanied by a spontaneous change and a PNR 601 present after re-booking. 8A and 8B, there is shown an exemplary EMD 608b before the change request processing associated with the spontaneous change re-booking of FIG. 7 and a new exemplary EMD 618b after the change request processing of FIG. 7, respectively.

Prior to a voluntary change request resulting in re-booking, the field or portion of the PNR 600 will go from Paris to New York on October 12 (2.AF 12OCT CDG JFK) and return on November 12 (3.AF 12NOV JFK (1. testee 602) booked on the flight section 604 on a flight (CDG) flight. The subsidiary service 606 is requested for additional luggage during the entire itinerary under a particular service request (4.SSR ABAG / S2 and 5.SSR ABAG / S3). The document 608 generated for the testee's bookkeeping is an e-ticket 608a (7.ETKT 057-2337324592 / S2-3) for flight and an EMD 608b (EMD 057-822073577 / E4- 5).

In an illustrative scenario, Mr. Test decides to extend his stay in New York for a day. As a result, Test will contact the airline travel agency to re - book on a different flight on the new return date of November 13th. Services associated with Old and Old flights are removed from Test's reservations and new additional services 616 (5 ') on new dates (3'. AF 13 NOV JFK CDG) and baggage associated with this new flight. SSR ABAG / S3). Other documents will still remain valid, but this only applies to part of the itinerary that has not been re-booked. The employee must replace the old document with a new one. The e-ticket is exchanged, and the EMD exchange is performed further.

From the client terminal 280 (e.g., a cryptic terminal) to initiate the performance of the EMD exchange, the employee displays the PNR of the customer that has been rebuilt to a new itinerary. The employee sends an EMD exchange request using, for example, the Cryptic command 'FXQ / EMD' type, but the parameters are not explicitly selected. The current PNR situation (passenger, flight section, services and documentation included in the reservation) is considered in the request. As already explained, the input analysis component 202 processes the situation to identify the next exchange element. One element is the Passenger Test (1st Test), a passenger on the PNR only. The other element is a special service request (4.SSR ABAG / S2, 5'.SSR ABAG / S3) for ancillary services. There is a third service 600 (6.SSR DOCS) in the PNR, but this service is set to be unquotable and considered non-eligible to exchange. The other element is EMD. Only one EMD (EMD 057-8225073577) is referenced in PNR for Passenger 1.

It is necessary to identify the data contained in EMD 608b (message 404 in Figure 5). The EMD database 230 is queried to retrieve the entire EMD document so that its content can be analyzed to determine its eligibility condition. The coupon status is confirmed. In the example of Figure 8A, the EMD includes two coupons 702a, 702b with an "open" status, which means that the EMD document is eligible for exchange.

Configuration information for the considered service, i.e., additional baggage 'ABAG', is retrieved from the price record configuration database 212, which stores the price record configurations of the various airlines. This configuration information may include a reason for a release code (RFIC) description 703 that defines the service group to which the EMD belongs. This configuration information may further include an EMD type 704, an indicator 705 consumed for issuing, and an indicator that can not be interchangeable with the airline. In FIG. 8A, in the example of EMD exchange of test seeds, the configuration information includes information such as baggage (BAGGAGE) as an RFIC description 703, "A" as an EMD type 704 (ie, associated with flights) 705), and FALSE as a non-transferable indicator between the airlines.

As described above, at this point in the exchange process, it is necessary to acquire all the fees and amounts to fill the new price record. The multi-prime engine management component 206 accesses the pricing engine configuration database 208 to check the pricing engine that performs re-pricing in the current situation. In this example, in the considered airline and service, the selected price engine may be a price engine based on the ATPCO submission.

The price engine selection and current transaction data are transmitted to the price engine connector component 210, which is a component of the service modification system 20 having parameters corresponding to each particular interface of each price engine. In an exemplary embodiment, the price engine connector component 210 populates the re-pricing request with the necessary data according to the ATPCO pricing engine requirement, sends the request to the correct pricing engine and receives the result of the operation.

If the result from the price engine is received by the price engine connector, the result is adapted to the format independently of the price engine that provided the result. As a result, the data received from the various price engines is treated uniformly by the price engine connector component 210 in the same manner. The price data received from the price engine includes the flag requested for publication, the international indicator, the fee holder, the non-refundable indicator, the non-exchangeable indicator, the base rate 706, the exchange value 707 and the total rate 708 . In the example of the testee's EMD exchange, the flag required for publication is TRUE, the international indicator is "I" (for international flights), the fee holder is Air France (AF) The indicator is FALSE and the non-exchangeable indicator is FALSE, the base rate 706 is 132.00 EUR, the exchange value 707 is 132.00 EUR and the total rate 708 is 20.00 EUR (Which is the difference between the new price and the EMD amount).

The new price record is further populated with data computed by the data management module. For example, the issuance indicator 711, the original issuance data 710, the FCPI (Fare Calculation Pricing Indicator) and the FCRI (Fare Calculation Reporting Indicator) flag (not shown) are calculated by the data management module. The original issue data 710 includes the EMD exchanged and the reference and exchange date for the coupon, and the IATA number of the office. In the example of the testee's EMD exchange, the issuance indicator 711 is "R" for reissue and the calculation is automatic since the fare calculation price indicator (FCPI) and the fare calculation report indicator (FCRI) Are all set to " 0 "

The exchange is completed by updating this situation with all of the processed data and information. Most of the data may be a field or part of a new price record used to generate a new EMD at issue time. Portions of the data may be stored in different elements of the PNR, but the link may still be maintained in the main pricing record, such as the original issuance or approval. All of these elements are generated for the PNR and are available for publication to prepare a new document.

A response is returned to the employee indicating that the transaction was successful. Thereafter, the employee can check the output of the transaction with all the calculated amounts, and if any, additional collection or penalty fees. Issuance of a new EMD may be obtained without performing any other manual operation.

FIG. 8B shows a new exemplary EMD 618b issued in the example of an EMD exchange of a testee in which all modification and re-pricing information has been updated. The re-pricing information includes a base rate 706, an exchange value 707, a total charge 708, a fee calculation 709, and a link to the original issue data 710. The new e-Ticket 618a for the flight (7.ETKT 057-2337324592 / S2-3) is also documented in the PNR 601 and for EMD 608b (EMD 057-822073577 / E4-5) ). It is also clear that the flight section 614 is updated in the PNR 601 as a result of the re-ticketing.

In response to the change request, the service modification system 20 can simultaneously exchange multiple EMDs for each passenger and multiple passengers. The service change system 20 can be accessed through a flexible graphical user interface that provides employees with clear and efficient entries that specify multiple exchange combinations that can be processed at one time, saving time. The service change system 20 can provide an integrated solution that can provide a clear visibility to employees and customers of the services being exchanged by properly updating the transaction status, including all necessary checks of amounts and data.

In general, a routine executed to implement an embodiment of the present invention, whether implemented as part of an operating system or a particular application, component, program, object, module or command sequence, or even a subset thereof, Quot; computer program code "or simply" program code ". The program code typically includes one or more instructions resident in various memory and storage devices in a computer, and the instructions, when read and executed by one or more processors in the computer, cause the computer to perform various aspects of the invention To perform the steps necessary to implement the step or element to be implemented. Moreover, while the present invention has been described in the context of fully functional computer and computer systems, those of ordinary skill in the art will recognize that many embodiments of the present invention may be distributed in various types of program products, It will be appreciated that the invention is equally applicable regardless of the particular type of computer readable medium used to carry out the invention.

Program codes embodied in any of the applications / modules described herein may be distributed individually or collectively to a number of different types of program products. In particular, the program code may be distributed using a computer-readable medium and a communication medium, which may include a computer-readable storage medium. A computer-readable storage medium that is essentially non-volatile includes volatile and non-volatile, implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data, and Removable and non-removable type media. The computer readable storage medium may be any of a variety of storage devices including but not limited to RAM, ROM, erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory or other solid state memory technology, CD-ROM), or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage media or other magnetic storage devices, or any other medium that can be read by a computer and used to store the desired information can do. The communication medium may embody computer readable instructions, data structures, or other program modules. By way of example, and not limitation, communication media may include wired media, e.g., wired networks or direct-wired connections, and wireless media such as acoustic, RF, infrared and other wireless media. Any combination of the above may also be included within the scope of computer readable media.

Computer program instructions that may be stored on a computer-readable medium, such as a computer, a processor, or other type of programmable data processing apparatus or other device capable of functioning in a particular manner may be stored on a computer readable medium, Or < / RTI > instructions that implement the function / action specified in the blocks.

The computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a computer to execute a sequence of operations that may be performed on the computer, other processing apparatus, or other device, A computer-implemented process that provides one or more processes that implement the functions / operations specified in the blocks or blocks.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention to these embodiments at all. As used herein, the singular terms "work" and "above " are intended to include the plural forms unless the context clearly dictates otherwise. As used herein, the term "comprising" and / or "having" means that there is a stated feature, integer, step, operation, element and / , Steps, operations, elements, components, and / or groups are not intended to be < / RTI > Further, when the terms "comprising", "having", "having", "having", "consisting", or variations thereof are used in either the detailed description or the claims, It is to be understood that the same is intended in a broad sense.

While the present invention has been illustrated and described in considerable detail, it is not intended that the applicant intend to limit or limit the appended claims to such detail. Additional advantages and modifications will readily occur to those of ordinary skill in the art. Thus, in a broader aspect, the invention is not limited to the specific details, representative apparatus and method, and illustrative examples shown or described. Accordingly, these details may be deviated from the details of the inventor's general inventive concept without departing from the spirit and scope thereof.

Claims (19)

CLAIMS What is claimed is:
Wherein the request includes first data for a passenger name record, the method comprising: receiving a request for a change in airline reservation in a computer system;
Receiving, in the computer system, second data for a first electronic payment certificate linked to first data for a passenger name record;
The computer system determines whether the first electronic payment certificate can be exchanged by applying at least one exchange qualification rule to the first data for the passenger name record and the second data for the first electronic payment certificate step;
Obtaining a service charge associated with the first electronic payment certificate from a price engine associated with the first electronic payment certificate if the first electronic payment certificate can be exchanged; And
And in response to receiving the service charge, updating the passenger name record with the second electronic payment including the service charge. 2. The method of claim 1, wherein receiving the second data for the first electronic payment certificate linked to the first data for the passenger name record comprises:
And retrieving second data for a first electronic payment certificate from the airline database. 2. The method of claim 1, wherein the request includes a third electronic payment certificate and the first electronic payment certificate can be exchanged if the first and third electronic payment certificates are handled by the same validating carrier ≪ / RTI > 2. The method of claim 1, wherein the first electronic payment certificate can be exchanged if the request does not include a third electronic payment certificate and the request does not include an indication of flight disruption. The method of claim 1, wherein if the request does not include a third electronic payment, the request includes an indication of flight interruption and the first electronic payment includes an independent destination, Or the number of the coupon for the service is different from the number of the new service in the request, the change in the airport in the request, the change in the operating airline in the request, or the reference to the flight section is in the request The first electronic payment certificate can be exchanged. 2. The method of claim 1, further comprising updating the passenger name record with a link to a second electronic payment. 7. The method of claim 6 further comprising: collecting an element in the first data of the passenger name record, an element in the second data of the first electronic payment, a charge received from the price engine, and third data calculated by automatic processing Whereby a price record for a second electronic payment certificate is formed. 2. The method of claim 1, wherein the service is automatically identified from the context of the request if the service is not mentioned in the request. 2. The method of claim 1, wherein the first electronic payment certificate is automatically identified from the status of the request if the first electronic payment certificate is not mentioned in the request. A system for responding to changes in airline reservations,
At least one processor; And
A memory coupled to the at least one processor, the memory including instructions that when executed by the at least one processor cause the system to:
The request comprising first data for a passenger name record, the request comprising: receiving a request for a change in airline reservation;
Receiving second data for a first electronic payment certificate linked to first data for a passenger name record;
Determining whether the first electronic payment certificate can be exchanged by applying at least one exchange qualification rule to the first data for the passenger name record and the second data for the first electronic payment certificate;
Obtaining a service charge associated with the first electronic payment certificate from a price engine associated with the first electronic payment certificate if the first electronic payment certificate can be exchanged; And
In response to receiving the service charge, to perform an operation of updating the passenger name record with the second electronic payment including the service charge. 11. The computer readable medium of claim 10, wherein the program code configured to cause the at least one processor to receive second data for a first electronic payment certificate,
And program code configured to cause the at least one processor to retrieve second data for a first electronic payment certificate from an airline database upon execution. 11. The computer readable medium of claim 10, wherein the program code further causes the at least one processor to, when executed by the at least one processor, cause the at least one processor to, if the request includes a third electronic payment, And to exchange the first electronic payment certificate when handled by the airline. 11. The computer-readable medium of claim 10, wherein the program code further comprises instructions that, when executed by the at least one processor, cause the at least one processor to: if the request does not include a third electronic payment and if the request does not include an indication And to exchange the first electronic payment certificate. 11. The computer-readable medium of claim 10, wherein the program code causes at least one processor, when executed by the at least one processor,
If the request does not include a third electronic payment and the request includes an instruction to stop the flight and the first electronic payment includes an independent destination or includes a change of the ticketing airline in the request, If the number of the coupon is different from the number of the new service in the request, if the request includes a change of the airport, if the request includes a change of the operating airline, or if the reference of the flight section is the same as in the request, Wherein the system is configured to exchange information. 12. The computer readable medium of claim 10, wherein the program code configured to cause the at least one processor to update the passenger name record with a second electronic payment certificate,
And program code configured to cause the at least one processor to update the passenger name record with a link to a second electronic payment certificate upon execution. 16. The computer-readable medium of claim 15, wherein the program code further causes the at least one processor to cause the at least one processor to, when executed by the at least one processor, And to form a price record for the second electronic payment certificate by collecting the fee received from the price engine and the third data calculated by the automatic processing. 11. The system of claim 10, wherein the program code is configured to cause at least one processor, when executed by the at least one processor, to automatically identify a service from a status of a request if the service is not mentioned in the request. . 11. The computer program product of claim 10, wherein the program code, when executed by the at least one processor, causes the at least one processor to automatically generate a first electronic payment certificate from the status of the request if the first electronic payment certificate is not mentioned in the request And to identify the system. As a computer program product,
Non-transient computer readable storage medium; And
And program code stored on a computer readable storage medium, wherein the program code, upon execution, causes the at least one processor to:
The request comprising first data for a passenger name record, the request comprising: receiving a request for a change in airline reservation;
Receiving second data for a first electronic payment certificate linked to first data for a passenger name record;
Determining whether the first electronic payment certificate can be exchanged by applying at least one exchange qualification rule to the first data for the passenger name record and the second data for the first electronic payment certificate;
Obtaining a service charge associated with the first electronic payment certificate from a price engine associated with the first electronic payment certificate if the first electronic payment certificate can be exchanged; And
In response to receiving the service charge, to perform an operation of updating the passenger name record with the second electronic payment including the service charge.

Images