FR3062228A1 - AGREGATIVE DATABASE OF RECORDINGS CONTEXT - Google Patents

Abstract

Systems, methods and computer program products for aggregating data from related database records. A reservation folder database stores a plurality of reservation record records. Each booking record record links reservation records and other data relating to a particular trip or group of trips by storing identifiers that identify the reservation records to be linked. To view or edit a trip, a client application can search the database for a reservation record record that matches the search term. Based on the identifiers in the corresponding booking folder record, the client application can retrieve the related reservation records and aggregate the reservation records into a single view of the booking record for the entire trip. To change the trip itinerary, the client application can add or remove links from the booking folder record or edit the linked reservation records.

Description

Holder (s):

Amadeus S.A.S ..

O Extension request (s):

© Agent (s): SAMSON & PARTNER PATENTANWALTE MBB.

FR 3 062 228 - A1 ® AGGREGATE DATABASE OF CONTEXT RECORDS.

@) Systems, methods, and computer program products for aggregating data from related database records. A reservation file database stores a plurality of reservation file records. Each booking record record links booking records and other data relating to a particular trip or group of trips by storing identifiers that identify the booking records to be linked. To view or modify a trip, a client application can search the database to find a record of a reservation file corresponding to the search term. Based on the identifiers in the corresponding reservation file record, the client application can retrieve the linked reservation records and aggregate the reservation records into a single view of the reservation file for the entire trip. To modify the journey itinerary, the client application can add or remove links from the reservation file record or modify the linked reservation records.

i

AGGREGATIVE RECORDS DATABASE

BACKGROUND In general, the invention relates to computers and computer systems and in particular to systems, methods and computer program products for aggregating data from related database records.

In the information age, data relating to people, transactions or other matters is commonly collected and stored in databases. Much of the data collected in separate databases is often superfluous, or related in some way. For example, a single person or process can generate data, in separate data processing sessions, related to a single task or project, but occurring at different times and / or during processing by different systems. These different data processing sessions can give rise to database records which are similar to a single event or transaction recorded in different databases or in unrelated records inside partitions in a single database. of data.

For example, in the travel industry, travel agents can book travel products for customers with booking systems managed by different travel providers, a single trip can, for example, include reservations for air transportation, hotels, car rentals, and other travel-related products. When a travel product is booked, one or more electronic records that document the booked travel product are typically made in a database on a global distribution system. The database may include a collection of records containing information on travelers and their routes in relation to travel products booked with that particular travel supplier. Each database record can also define a contract between the travel agent and the travel supplier for products reserved by the database record. Booking products with multiple travel providers can result in the generation of unrelated database records that are not linked to each other. When reservations for a particular traveler or route are not linked, it becomes difficult for travel agents to determine the extent of the entire travel itinerary. In addition, it may be difficult for the travel agent to identify each existing contract with a particular passenger.

Travel providers may face a different problem resulting from the generation of multiple unrelated database records. Each database record can define a contract between the travel provider and a particular travel agency. However, a single traveler may have used more than one travel agency to book their trip, resulting in separate database records for products supplied to the same passenger by the same travel provider for a single trip. For example, in the case of air transport, this results in a division of the traveler's itinerary between multiple contracts which may prevent the airline from applying pricing policies for the entire route.

[0006] Thus, improved systems, methods, and computer program products are required to aggregate data from related database records that provide users and systems with a single view of database records.

SUMMARY In one embodiment, a data processing system includes one or more processors and a memory coupled to the processors. The memory stores data including a reservation file database and a program code. When executed by at least one of one or more processors, the program code can cause the system to receive a first request to consult a reservation file. The first request may include a search term and, in response to receipt of the first request, the system may retrieve a reservation record record corresponding to the search term from the reservation record database. The reservation record record can define a first identifier which identifies a first reservation record. The system can use the first identifier of the reservation record record to retrieve the first reservation record and transmit the reservation record to a user system. The reservation file may include a first item of data from the first reservation record.

In another aspect, the program code can cause the system to create the reservation record record in the reservation record database and to associate the reservation record record with a reservation record. Alternatively, once the reservation record has been created, the reservation record record and the reservation record can be dissociated by removing Γ identifier from the reservation record from the reservation record.

In yet another aspect, the reservation record record may further define a second identifier which identifies a second reservation record, and the program code may furthermore cause the system to use the second identifier of the reservation record reservation to retrieve the second reservation record and add a second item of data from the second reservation record to the reservation file, In another aspect, the program code can cause the system to retrieve the reservation file registration from the help of a context coordinator, attach a context header to a query, transmit the query of the context coordinator to the reservation files database, retrieve the reservation file from the reservation files database , store the reservation file in the context header, attach the header be from context to a response, transmit the response from the reservation records database to the context coordinator and detach, using the context coordinator, the context header from the response.

In another aspect, the program code can cause the system to create the reservation file record in the reservation file database by receiving before the first request, a second request which includes the term search and the first identifier. In response to the receipt of the second request, the program code may cause the system to store the search term in a first field of the reservation record record, to store the first identifier in a second field of the reservation record record , generating a file identifier, and storing the file identifier 25 in a third field in the reservation file record. The program code can then cause the system to store the reservation file record in the reservation file database.

In another aspect, the reservation file may be transmitted to the user system via an application programming interface and the data processing system may also comprise a client computer on which a client application is operating. interfacing with the application programming interface and providing a user interface for viewing the reservation file and a server computer running a database management application which manages the file database of reservation.

In another aspect, the reservation record record aggregates a plurality of reservation records without replicating the data found in any of the reservation records.

In another aspect, the program code can, moreover, cause the system, in response to the reception of the second request to update a route, to retrieve the reservation file registration, use the first identifier of the reservation file record to retrieve the first reservation record and update the route by modifying the first reservation record.

In another aspect, the program code can also cause the system, in response to the reception of the second request to update the route, to recover the recording of the reservation file and update a route by storing the second identifier in the booking record, the second identifier which identifies a second booking record defining a travel product which is added to the route. In another embodiment, a method can include the reception, by the data processing system, of the first request to consult the reservation file. The first request may include a search term, and in response to receipt of the first request, the method may retrieve a reservation record record corresponding to the search term in the reservation record database. The reservation record record may define the first identifier that identifies the first reservation record and the method may use the first identifier of the reservation record record to retrieve the first reservation record. The method can also include the transmission of the reservation file to the user system and the reservation file can include a first datum of the first reservation record.

In another aspect, the method can also include the creation of

Γ reservation record registration in the reservation dossier database and associate the reservation dossier registration with the reservation registration. Alternatively, once a reservation file has been created, the method may further include dissociating the reservation file registration from the reservation registration by removing the reservation registration identifier from the reservation file. In another aspect, the reservation record record can also define the second identifier which identifies the second reservation record, and the method can also include the use of the second identifier of the record record. reservation to retrieve the second reservation record and add the second item of data from the second reservation record to the reservation file.

In another aspect, the method can, using the context coordinator, retrieve the reservation file, attach the context header to the query, transmit the query from the context coordinator to the reservation file database, retrieve the reservation file from the reservation file database, save the reservation file in the context header, attach the Context header to the response, transmit the response from the reservation folder database to the context coordinator and detach, using the context coordinator, the context header from the response.

In another aspect, the method can create a reservation file in the reservation file database by receiving, before the first request, the second request which includes the search term and the first identifier. In response to the reception of the second request, the method can store the search term in a first field of the reservation file record, store the first identifier in a second field of reservation file registration, generate an identifier of folder and store the folder identifier in a third field in the booking folder record. The method can then store the reservation record in the reservation record database.

In another aspect, the method can also include the storage of transverse data in a fourth field of the reservation file record.

In another aspect, the reservation file can be transmitted to the user system by the application programming interface, and the data processing system can include the client application which acts as an interface with the the application interface and provides the user interface for displaying the reservation file and the database management application which manages the reservation file database.

In another aspect, the plurality of reservation records can be aggregated by the reservation record record without replicating the data found in any of the reservation records.

In another aspect, the method can also include, in response to the reception of the second request to update the route, the recovery of the reservation file registration, using the first identifier of the 'booking record to retrieve the first booking record, and update the route by modifying the first booking record.

In another aspect, the method can also include, in response to the reception of the second request to update the route, retrieving the reservation file registration, and updating the route by storing the second identifier in the reservation file record, the second identifier which identifies the second reservation record defining the travel product which is added to the itinerary. In another embodiment, a computer program product includes a durable computer-readable storage medium including a program code. The program code can be configured to, when executed by one or more processors, cause one or more processors to receive the first request to consult the reservation file. The first request may include the search term and, in response to the receipt of the first request, the code may cause the processors to retrieve the reservation record record corresponding to the search term from the reservation records database . The reservation record record can define the first identifier that identifies the first reservation record. The code can cause processors to use the first identifier in the reservation record record to retrieve the first reservation record, and transmit the reservation record to a user system.

The reservation file may include the first item of the first reservation record.

The above summary may present a simplified overview of some of the embodiments of the invention in order to provide a basic understanding of certain aspects of the invention discussed herein. The summary does not purport to provide an exhaustive overview of the invention and is not intended to identify any key or critical elements or to limit the scope of the invention. The sole purpose of the summary is to simply present a few concepts in a simplified form as a preamble to the detailed description presented below.

BRIEF DESCRIPTION OF THE DRAWINGS The drawings, which form an integral part of the specifications, illustrate various embodiments of the invention and, with the general description of the invention above and the detailed description of the embodiments given below. -after, serve to explain the embodiments of the invention.

FIG. 1 is a schematic view of an exemplary operating environment including a travel agency system, a global distribution system (GDS) and an aggregated database.

FIG. 2 is a schematic view of an example computer which can be used to provide the FIG operating environment. 1.

FIG. 3 is a schematic view of the FIG GDS. 1 including a service integrator and a slice of the background (Open Back End [OBE]).

FIG. 4 is a schematic view of the GDS of FIG. 3 illustrating a context coordinator application, a file services application, a recording storage application, a recording access application, and the aggregated database hosted in the OBE layer;

FIG. 5 is a sequential diagram illustrating a message flow between the applications and the FIG aggregated database. 4 to create a reservation file record.

FIG. 6 is a sequential diagram illustrating a message flow between the applications and the FIG aggregated database. 4 to retrieve a reservation file registration.

FIG. 7 is a schematic view of a reservation file that can be displayed by the FIG travel agency system. 1 in one embodiment of the invention.

FIG. 8 is a schematic view of a reservation file which can be displayed by the FIG travel agency system. 1 in another embodiment of the invention. FIG. 9 is a schematic view of a reservation file which can be displayed by the FIG travel agency system. 1 in yet another embodiment of the invention.

FIG. 10 is a flow diagram of a process that can be executed by the GDS and / or the FIG travel agency system. 1 to create a reservation file record.

FIG. 11 is a flow diagram of a process that can be executed by the GDS 5 and / or the FIG travel agency system. 1 to add reservations to the reservation file record created in FIG. 10.

DETAILED DESCRIPTION The embodiments of the invention can be implemented by a data processing system which provides processing and database functions allowing 10 and / or facilitating interconnections between one or more supplier systems. travel, travel agency systems, and / or database systems. Database systems may include a new type of database that records and generates records of reservation records. These reservation record records can provide a single active reception center for travel management by the traveler, travel agent, or other system user. The booking file can thus provide users of the data processing system with a single access point which maintains compatibility with existing booking recording standards, to consult and manage all the information of a trip for the traveler.

A booking record can be created at the start of a trip planning session. As travel products are booked for travel, a check-in locator or other check-in identifier can be added to the booking record record for each booking made. The reservation record record may be stored in a centralized database so that external systems can access the reservation record record. In response to a request to view or modify the trip, the booking records database can be queried to access the booking record record corresponding to the trip. The requesting system can then identify each reservation record associated with the reservation file record, and retrieve the identified records from their respective databases. The data provided by the booking file and the 30 booking records can be aggregated into a single booking file which provides a view of the entire journey. The database of reservation files can thus allow the consultation of aggregated itineraries for a particular trip, a group of travelers, or any other person having an interest in the itinerary, thus extending the basic functionality of the database and improving the efficiency of booking processes such as inquiries and responses.

Referring now to FIG. 1, an operating environment 10 according to an embodiment of the invention may include a GDS 12, one or more supplier systems 14a-14m, one or more travel agency systems 16a-16n, one or more reservation databases 18a-18o, and a reservation file database 20. The reservation databases 18a-18o and a reservation file database 20 may be independent databases, or may be stored in an aggregated database 22. In one embodiment of the invention each of the supplier systems 14a-14m can host or be associated with one of the databases 18a-18o or can use a hosted reservation database by another system, such as GDS 12. Each of GDS 12, supplier systems 14a-14m, travel agency systems 16a-16n, databases 18a-18o and the reservation records database on 20 can communicate via a network 24. The network 24 can include one or more private or public networks (eg, Internet) which allow the exchange of data between systems connected to the network 24.

The GDS 12 can be configured to facilitate communication between the supplier systems 14a-14m and the travel agency systems 16a-16n by allowing travel agents, the sending carrier, or other indirect sellers confirm reservations on supplier systems 14a-14m via GDS 12. For this purpose, GDS 12 can maintain links with supplier systems 14a-14m via network 24. These links can, for example, allow GDS 12 to route requests from the supplier system of an issuing carrier or from the travel agency system to the corresponding supplier system of the actual carrier. Provider and travel agency systems can therefore book flights with multiple carriers via a single connection to GDS 12. GDS 12 can be based on a highly available service-oriented architecture that is fully distributed. This fully distributed architecture can separate the functions provided by the GDS 12 into several applications, each application having the responsibility of providing a given set of services.

Each of the supplier systems 14a-14m can include a computer reservation system (CRS) allowing the GDS 12 or the travel agency systems 16a-16n to book and pay for travel products, such as airline tickets, hotel rooms, or vehicle rentals. Each provider system can also interact with other 14a-14m provider systems, directly or through GDS 12, to allow, for example, the originating carrier to sell seats supplied by the actual carrier. The de facto carrier can then invoice the issuing carrier for the products supplied. In certain embodiments of the invention, one or more of the supplier systems 14a-14m may include an electronic ticketing system (ETS) and / or a departure control system (DCS) for a corresponding carrier. 16a-16n travel agency systems can provide travel agents with an interface to access GDS 12 allowing agents to search and book travel products. One or more of the travel agency systems 16a-I6n may also include an application server accessible through a traveler system (not shown) allowing travelers to search and book travel routes without being assisted by a travel agent. This application may include, for example, a travel website accessible via the network 24 using a client application such as a web browser running on the traveller's system.

In response to the reservation of a product by the traveler, the GDS 12 or a corresponding supplier system 14a-14m can store a passenger name record (PNR), or other type of reservation record, in one of the reservation databases 18a18o, in the aggregated database 22 and / or in a logical partition of the aggregated database 22. The PNR can be generated, at least in part, by the corresponding supplier system and can include one or more records which contain the route and the passenger information. Each of the records in the PNR can define one or more reservations made by the traveler. The PNR can also monitor the use of travel products purchased, for example the use or not of a reserved flight. The PNR can be identified by a record locator unique to that PNR within its respective database, and can include records defining an itinerary for a particular trip, service, passenger, or group of passengers .

it An action performed via the GDS 12 or by one of the supplier systems 14a-14m to modify a route (eg, adding a passenger, changing a flight, etc.) may result in a change the content or state of the corresponding PNR. At least some of the elements contained in each PNR, such as remarks or special service requests, may be required to comply with a standard format defined by a standards body, e.g., IATA (Interrnational Air Transport Association). This standardization can ensure data compatibility between different systems operating in the travel industry. However, the need to align PNR elements to industry standards can also limit the characteristics that can be accommodated by PNRs.

The reservation file database 20 can store reservation file records which provide a single database record for aggregating and managing a travel route disseminated between multiple PNRs. Reservation record records can also be configured to store data that is not compatible with existing PNR standards, thereby enabling the deployment of new services. For this purpose, each reservation file record may include one or more elements that store data necessary for different usage scenarios. For example, an item can store the registration locator for each PNR linked to the reservation dossier registration. Although FIG. 1 illustrates a mode of storage in separate databases, according to an embodiment of the invention. reservation records (eg, PNRs) and reservation record records can be organized as separate logical databases within an aggregated database 22. The aggregated database 22 can be hosted by GDS 12 or any other suitable system, or provided as part of a cloud-based service.

The reservation file registration can store contextual data of

PNR, such as the identity of the ticket office that created the PNR or the point of sale for one or more travel products defined in the PNR. The reservation file may also contain data found in one or more of the associated PNRs, such as the name and contact information of one or more stakeholders, e.g. e.g. the traveler, travel agency or agent who booked the trip, the entity that organized or paid for the trip (the employer), or any other entity for which the trip is of interest or an issue. Booking record registration can therefore allow GDS 12, supplier systems 14a-14m and / or travel agency systems 16a-16n to obtain travel details from a single source which combines a plurality of independent PNRs including the itinerary of a trip.

Reservation file registration thus represents a new type of database registration which stores new registration elements without affecting the existing structure of standard PNR elements. The unique structure of reservation record records can allow the reservation record database 20 to accommodate new services without affecting legacy services provided by GDS 12 and / or provider systems 14a-14m. The reservation file database 20 can allow separate processing of PNRs and reservation file records. It may also allow legacy applications and databases incompatible with reservation record records to continue operating using only PNRs while allowing other applications and databases to use the additional features provided by the reservation file database 20. By preserving the standard format of existing reservation systems and database records, the reservation file database 20 can enable the deployment of new features while ensuring that these new ones features will not interfere with the operation of applications from the systems of the supplier, the travel agency and the current GDS.

Referring now to FIG. 2, the GDS 12, the supplier systems 14a14m, the travel agency systems 16a-16n, the reservation databases 18a-18o, the reservation files database 20, the aggregated database 22, and the network 24 of the operating environment 10 can be implemented on one or more computer devices or systems such as the exemplary computer 30. The computer 30 can include a processor 32, a memory 34, a memory device mass 36, an input / output interface (I / O) 38, and a man-machine interface (HMI) 40. The computer 30 can also be operatively coupled to one or more external resources 42 via the network 28 or I / O interface 38. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud network services ), or any other appropriate IT resource that can be used with the computer 30.

The processor 32 may include one or more selected devices: microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, programmable door networks, programmable logic devices, state machines defined , logic circuits, analog circuits, digital circuits or any other device used to manipulate signals (analog or digital) on the basis of operating instructions stored in memory 34. Memory 34 can include a single device or a most memory devices, including, but not limited to, read-only memory (ROM), random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM) , dynamic random access memory (DRAM), flash memory, cache memory or any other device capable of storing cker information. The mass memory storage device 36 may include data storage devices such as a hard disk, an optical disk, a magnetic tape drive, a volatile or non-volatile solid state circuit or any other capable device. to store data.

The processor 32 can operate under the control of an operating system 44 which resides in memory 34. The operating system 44 can manage computer resources so that the computer program code, integrated under the form of one or more software applications such as the application 46 which resides in the memory 34, can receive the instructions executed by the processor 32. The processor 32 can also execute the application 46 directly, and in this case the system 44 can be omitted. The software application (s) may include a case of operation comprising a server which can accept requests from client applications and provide them with responses. One or more data structures 48 can also reside in memory 34 and can be used by processor 32, operating system 44 or application 46 to store or manipulate data.

The I / O interface 38 can provide a machine interface which couples the processor 32 functionally with other devices and systems, such as the network 24 or the external resource 42. The application server 46 can thus collaborate with the network 28 or with the external resource 42 by communicating via the I / O interface 38 to provide the various elements, functions, applications, processes, modules making up the embodiments of the invention. The application 46 may also include a coded program which is executed by one or more external resources 42, or may otherwise be based on the functions or signals provided by other system or network components external to the computer 30. Indeed , in view of the almost infinite configurations of possible computer hardware and software, those skilled in the art will understand that the embodiments of the invention may include applications located outside of computer 30, distributed to multiple computers or to other external resources 42 or provided by IT resources (hardware and software) which are provided by a service such as a cloud computing service, via the network 24.

The HMI 40 can be operatively coupled to the processor 32 of the computer 30 10 to allow a user to interact directly with the computer 30. The HMI 40 can include a video or alphanumeric display, a touch screen , a loudspeaker and any other visual and audio indicator capable of communicating data to the user. The HMI 40 can also include input devices and controls such as an alphanumeric keyboard, pointing device, keyboards, push buttons, control buttons, microphones, etc., capable of accepting commands or user input and pass it to processor 32.

A database 50 can reside on the mass memory device 36 and can be used to collect and organize the data used by the various systems and modules described herein. The database 50 can include data and accommodate the associated data structures that store and organize the data. In particular, the database 50 can be fitted with any database organization or structure, in particular, but not limited to, a relational database, a hierarchical type database, a networked database , an object-oriented database or combinations thereof.

A database management system in the form of a software application which is executed in the form of instructions on the processor 32 can be used to access the data stored in records of the database 50 in response to a query, when the query can be determined dynamically and executed by the operating system 44, the other applications 46 or one or more modules. Although embodiments of the invention may be described herein using relational, hierarchical, network, object-oriented, or other terminology in specific cases, those skilled in the art will understand that Embodiments of the invention may use any suitable database management model, and are not limited to any particular type of database, FIG. 3 illustrates an embodiment of the GDS 12 having a distributed architecture 5 which includes a service integrator 52 in communication with a plurality of application servers 54a-54p. The service integrator 52 may include a hardware and / or software module, such as a router or an enterprise service bus, configured to route messages between the network 24 and the application servers 54a-54p, as well only between the 54a-54p application servers themselves. The application servers 54a-54p may include an OBE layer 56 which hosts the server applications providing the services to external and / or internal client applications. External systems which may be in communication with GDS 12 on network 24 may include provider systems 14a -14m, travel agency systems 16a-l 6n or any other relevant external system, such as a system user connected to a web application server on the Internet.

The exemplary GDS 12 applications hosted by servers in the OBE layer can include, but are not limited to, a reservation application, a departure control application (DCS), a ticketing application, a pricing application, an availability application, and / or a web server application. Each application running on the application servers 54a-54p can communicate with other applications via the service integrator 52 using any appropriate communication protocol, such as EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) and / or Extensible Markup Language (XML).

The messages generated by the applications in the OBE layer 56 can be published outside using standard web service protocols, such as the simple object access protocol (SOAP). The interface for messages sent from and to external client applications can use freely available XML schemas. The exchange of internal messages between applications in the OBE 56 layer can use an open protocol or a proprietary protocol and can be context-based. Context-based communication may involve attaching a context of the registration being processed by the application (eg, the context of one of the PNRs of a reservation record registration) to each message transmitted from an application server to another application server.

The context may, for example, include information that allows an application to retrieve a current copy of the record in question, or synchronization information that allows the destination server to determine whether a local copy of the record is valid. Referring now to FIG. 4, and in accordance with an embodiment of the invention, the GDS 12 may include a context coordinator application 58, a folder services application 60, a record storage application 62, a web access application a record 64 and the aggregated database 22. The context coordinating application 58, the file services application 60, the record storage application and the application for accessing a record 64 can be considered as collectively forming a database management application that creates, modifies, stores, and retrieves reservation record records and / or reservation records in the aggregated database 22. The applications and the database can, for example, be provided or managed by one or more servers in the OBE 56 layer.

The context coordinating application 58 can be configured to maintain the context of a recording with the GDS 12 during a user session during which the recording can be modified if not used to process data. For this purpose, the context coordinating application 58 can attach the context to incoming interrogations and forward the interrogation to the relevant application. When the external applications involved in the user session use reservation file records, the context coordinating application 58 can retrieve a reservation file record associated with the transaction from the aggregated database 22 and attach the reservation file record to the message being transmitted by storing the reservation file in a context header. Storing the reservation record in the context header may include attaching the reservation record record to the message using a standard Internet Protocol (IP), such as a multi-use extension for Internet messaging (MIME). When a reservation record is not used (eg, one or more applications involved are not compatible with reservation record), the context coordinator application 58 can attach the context of a reservation record being processed at the message.

The folder services application 60 can be configured to create reservation record records and make any changes to a reservation record record requested during the user session. The record storage application 62 can be configured to generate a record identifier which uniquely identifies the reservation record record and stores the reservation record record in the aggregated database 22. The application Access to the records 64 can be configured to retrieve reservation file records from the aggregated database 22 in response to queries from other applications, such as the context coordinating application 58. The applications making it possible to store the and accessing records can collectively manage the storage and retrieval of reservation record records in the aggregated database 22. The storage and access applications can also be configured to manage the creation, storage of records and their access to the database e aggregative data 22. [0064] The sequential diagram of FIG. 5 shows by way of example the exchange of messages between applications of a data processing system for the creation of a reservation file record. To initiate the process of creating a record, a client application 70, such as the reservation application that operates on one of the travel agency systems 16a-16n, can transmit a query 72 to the GDS 12 by requesting the creation of a reservation file record. The query can be transmitted via an application programming interface (API) 73 which defines a set of protocols for communication between the client application 70 and the context coordinator 58. The query can include a data defining a label for the reservation file, p. eg, "Trip for Mr. Smith to New York", and can be transmitted in response to receipt of an entry via the user interface of client application 70. The query can be received by the service integrator 52 and routed to the context coordinating application 58. In response to receiving the query, the context coordinating application 58 can attach the context header 74 to the query and transmit the query 76 to the application of file services 60.

The 60 folder services application may, in response to receipt of

ΓQuery from the context coordinator application 58, create a reservation record 78. The reservation record may include a plurality of segments or fields, each of which includes one or more elements. Elements can be formatted, for example, using the JavaScript object exchange format (JSON) or any other suitable format. Each element can be identified by an identifying element, p. e.g., a three-digit code that identifies the type of item. An exemplary reservation record record in this case may include three segments and be displayed as follows:

fld {key: FolderlD str; } fld {key: Label str: Trip for Mr. Smith to New York} fld {key: BookingFiles ctn {}}

As can be seen, the above exemplary booking record record includes a record identifier field "FolderlD" which contains a string defining the label of the record reservation record and a field titled "BookingFiles Which can also be empty initially [0066] The folder services application 60 can store, at 80, the reservation file recording in the context header and transmit, at 82, a response including the context header to the context coordinating application 58. In response to receiving the response from the case services application 60, the context coordinating application 58 may store, at 84, the case record in an active memory and detach, at 86, the context header from the response. The context coordinating application 58 can then transmit, to 88, the response to the client application 70, thereby informing the client application 70 that the reservation file record has been created.

The reservation file record may include a context agent which is maintained in parallel with an existing reservation record, eg. e.g., a PNR.

The context coordinator application 58 can process reservation record registration and reservation registration simultaneously, without affecting the activities of other users who can perform their usual work on reservation registration. Both booking record registration and reservation registration can have separate lifetimes and can be handled independently. The folder services application 60 can receive a current reservation record in a user context, but typically cannot modify the reservation record.

In response to the reception of the response from the ODS 12, the client application 70 can transmit, to the 90, a query to the GDS 12 requesting that the GDS 12 associate one or more PNRs with the registration of booking. The interrogation can be received by the service integrator 52 and routed to the context coordinating application 58. At 92, in response to the reception of ation interrogation, Γ context coordinating application 58 can retrieve the record of reservation from active memory, attach the context header to the query and store the reservation record record in the context header. The context coordinating application 58 can then transmit, to 94, the query to the file service application 60. In response to receipt of the query, the file service application 60 can, at 96, modify the reservation file registration in accordance with the query.

The modification may, for example, include the addition of one or more fields to the reservation file registration including identifiers or from registration locators which identify the PNR (s). For example, the folder services application 60 can add a field to each PNR identified in the query. Each of these added fields may contain the registration locator for each respective PNR. Once the reservation record record has been changed, the record services application

60 can, at 98, transmit a response including the context header which contains the reservation file record to the context coordinating application 58. For a query requesting the addition of three PNRs to the file record reservation, the copy of the modified reservation file record may look like the following:

fld {këy; FolderlD str:} fld {key: Label str: Trip for Mr. Smith to New York} fld {key: BookingFiles ctn {

fld { key: ÜID str: ABCDE1} fld 1 key: UXD str: ABCDE2} fld { key: ÜID str: ABCDE3}

As can be seen, three fields or sub-fields have been added to the reservation dossier registration in the "BookingFiles" field. PNRs are identified by the identifiers or exemplary record locators "ABCDE1", "ABCDE2", and "ABCDE3" contained in these fields.

Other types of modifications are possible. For example, in response to a query, one or more of the PNRs identified in the query can be removed from the reservation record record by removing the respective record locator from a field in the reservation record record . This modification dissociates the PNR from the reservation file registration.

Upon receipt of the response from the folder service application 60, the context coordinating application 58 can, at 100, store the modified reservation record in the active memory and, at 102, detach the context header from the response. The context coordinating application 58 can then, at 104, transmit the response to the client application 70.

Once the reservation file record has been created and filled with the

PNR, the client application 70 can, at 106, transmit a validation command to the GDS 12. The command can be received by the service integrator 52 and routed to the context coordinating application 58. At 108, in response to on receipt of the validation command, the context coordinating application 58 can retrieve the reservation file record from the active memory, attach the context header to the order and store the reservation file record in the context header. The context coordinating application 58 can then, at 110, transmit the command to the recording storage application 62. The recording storage application 62 can in turn, at 112, transmit a query to the base of aggregative data 22 asking the database to index and store the reservation file record. At 114, in response to receipt of the query, the aggregated database 22 can assign a folder identifier to the reservation record record and store the reservation record record in the database. The exemplary stored reservation record may look like the following:

fld {key: FolderlD str: ”1234567890} fld {key: Label str: Trip for Mr. Smith to New York} fld {key: BookingFiles” ctn {fld {key: ”UID” str: ABCDE1} fld {key: ÜID ”Str: ABCDE2} fld {key: UID str: ABCDE3”)}}

As can be seen, the reservation record record now includes the folder identifier "1234567890" stored in the "FolderlD" field of the record of 10 reservation records.

Once the reservation file record has been indexed and stored, the aggregate database 22. can, at 116, send a confirmation to the record storage application 62 confirming that the record of reservation file has been validated. The confirmation can include the folder identifier in the body of the message and an empty context header. In response to receiving confirmation, the context coordinator application 58 can detach the header and, at 120, send a response to the client application 70 confirming that the reservation file has been validated.

FIG. 6 represents a sequential diagram illustrating an exemplary messaging system which can be associated with the retrieval of the reservation file registration in the aggregated database. The client application can, for example, retrieve the reservation file record in the aggregated database 22 to display or modify a travel itinerary defined there. For this purpose, the client application can, at 130, transmit a query to the GDS 12 via the API 73 requesting the registration of the reservation file. The query can be transmitted, for example, in response to the reception by the client application 70 of a request to consult a reservation file via the user interface of the customer consultation application 70. L the query can include the booking record registration identifier to be retrieved, and can be received by the service integrator 52 and be routed to the context coordinating application 58. In response to the receipt of the query , the context coordinating application 58 can, at 132, attach a context header to the interrogation and, at 134, transmit the interrogation to the record access application 64.

In response to the receipt of the query, the record access application 64 can, at 136, transmit a query including the file identifier to the aggregated database 22. The query can ask the aggregative database 22 to retrieve the reservation file record indexed to the file identifier, which can be included in the body of the query. The aggregative database 22 can, at 138, retrieve the reservation file record identified by the file identifier and, at 140, transmit a response to the record access application 64 which includes the record of reservation file. The record access application 64 can, in response to receipt of the response, store the reservation record in the context header and, at 142, transmit the response including the header to the context coordinator application 58.

At 144, in response to receipt of the response, the context coordinating application 58 can store the reservation record record in the active memory and detach the context header from the response. The context coordinating application 58 can then, at 146, transmit a response to the client application by including the reservation file record in the body of the message.

FIG. 7 represents an exemplary aggregated view, or reservation file 150, which can be displayed on a user system by a user interface, such as the interface of the client application 70. The aggregative database 22 can allow the applications used by travel agents and carrier agents to manage a trip, such as applications running on a reservation system, a departure control system (DCS), and / or the systems of intermediate and rear counters, for display the reservation files. The reservation file 150 includes a file identifier data field 152, a label data field 154 and one or more reservation file data fields 156a-156q. The folder identifier data field 152 and the label data field 154 can display the folder identifier and the label defined in the reservation record record being accessed. Each reservation file data field 156a-156q can correspond to a PNR 158a-158q or to another reservation record identified by the reservation file record. Each reservation file data field 156a-156q can also display the contents of the respective PNRs 158a-158q, and can also display additional elements, such as an offer 160 comprising an unfinalized reservation stored in the associated reservation record. 158q.

[0078] FIG. 8 represents the exemplary reservation file 170 which aggregates different parts of a traveler's journey into a consolidated itinerary. The reservation file 170 can be displayed in response to the request for retrieving a reservation file record associated with PNRs for flights reserved for a single traveler by different GDSs. The reservation folder 170 may include a folder identifier data field 172, a label data field 174, a cross-sectional data field 176, and a plurality of reservation file data fields 178,180. The folder identifier data field 172 can provide a folder identifier, e.g. eg, "1569245632" and the label data field 174 can display a descriptive label for the trip stored in the booking record record, p. eg, "Business trip for N. Steely". The descriptive label can, for example, indicate the functional reason for the reservation file.

Cross-sectional data field 176 can display data common to the trip which is stored in the reservation file record. This data can, for example, include the identities and / or contact information of the parties concerned, p. eg the name of the traveler "Nancy Steely". one or more forms of payment (eg, credit card, voucher, cash, etc.) used to purchase at least a portion of travel products including travel, travel summary, one or more counters group, or any other relevant information or back office information.

The reservation file fields 178, 180 of the registration file 170 can also display the contents of the reservation records identified in the reservation file registration, p. e.g. PNR 54JZDV from the PNR IA database (AMADEUS®), and PNR XJ42HK from the PNR 1S database (SABRE®). Reservation records can be linked to each other by the common names found in the name elements "1" of PNR 54JZDV and PNR XJ42HK, and / or by the common contact information in contact element "7" of PNR 54JZDV and contact element "5" of PNR XJ42HK. Reservation records can also be linked to the reservation record record by the common names found in the name elements of each of these records ("STEELY / NANCY").

Groups of travelers can sometimes be dispersed between multiple booking records. However, decisions made by the travel supplier may require consolidated figures for the entire group, e.g. e.g., the total number of confirmed / ticketed passengers vs. the contracted allowance. The booking record record can allow the aggregation of all the booking records for the group. The registration of the reservation file can thus facilitate the calculation of the tariffs for the group and provide a registration in which the decisions applicable to the group, such as the deadlines, can be stored. Deadlines can, for example, include a time limit for issuing a ticket and / or a time limit for adding a name. Reservation record records can also be used to aggregate non-homogeneous reservations for a group of travelers, thereby consolidating the entire trip while allowing for an individual itinerary (eg, by a separate reservation record) for each traveler. FIG. 9 illustrates an exemplary reservation file 190 which demonstrates certain advantages which can be brought by the registration of the reservation file when it is used to manage groups of travelers. The reservation file 190 can be displayed by the client application 70 in response to the request to retrieve a reservation file record which is associated with the PNRs for flights reserved for a group of travelers. In this exemplary travel scenario, John and Jane Smith may have been recently married and have planned to go on their honeymoon in Greece. However just before the planned departure,

John Smith will be on a business trip to Paris while Jane Smith will be in London. To meet these requirements, PNR 65KAEW may have been created to book a flight for Jane Smith from Heathrow Airport in London to Charles de Gaulle Airport in Paris where Jane Smith plans to join John Smith . Another PNR 76LBFX may have been created to book a flight for Jane and John Smith from Charles de Gaulle in Paris to Athens.

The reservation file 190 includes a file identifier data field 192, a label data field 194, a transverse data field 196 and a plurality of reservation file data fields 198,200. The transversal data field 176 can display data stored in the reservation file record, such as the identity and / or contact information of the parties concerned, p. eg, the names of the travelers "Jane Smith" and "John Smith" and the conference which was the subject of John's presence in Paris. The fact that this trip is associated with a particular event (e.g. the conference) can, for example, allow Jane and John Smith to benefit from a reduced price on the flight from London to Paris and / or the flight from Paris to Athens which would not otherwise have been available. The reservation file data fields 198, 200 of the reservation file 190 may display the contents of the reservation records (e.g. PNR 65KAEW and PNR 76LBFX) identified in the reservation file record.

The reservation files can provide a complete aggregated view of the trip to the travel agent or to another user who would not have been available otherwise. This view can improve the management of disturbances on a portion of the trip by indicating the need to adjust other portions of the trip. For example, in the scenario described above, the travel agent (or a disturbance watch app) may be notified of a delay or cancellation of Jane Smith's flight from London. By viewing Reservation File 190, the travel agent (or disruption watch app) can determine the need to change the flight to Athens for a later departure due to the delay in the flight from Jane Smith from London. Without the aggregated view provided by the booking file 190, it is unlikely that the travel agent will become aware of the need to change the booking of the flight to Athens since this flight was booked under a booking record separate from the check-in for booking a flight from London.

The registration of reservation files does not only allow aüx applications to display aggregated views for the travel agent, it can also give systems to commercial counters (front office), intermediate systems (middle office) ) and back office systems the ability to obtain aggregated trip data from a single data container. Booking record registration can enable services that provide travel management functionality and facilitate new business opportunities in the future for travel agents and travel providers.

For example, a commercial application for recording reservation files can include the management of the integrity of receipts by identifying redundant reservations. The redundancy of reservations can occur when a place is reserved, when it is not going to be used. A redundant reservation can be determined by identifying a place in at least one of several reservations that a passenger cannot use due to a conflict between reservations. Redundant reservations can, for example, occur when a passenger has two reservations on the exact same flight, the passenger has two overlapping reservations, or the passenger has two reservations for the same route without sufficient time between the two reservations to be able to take the return flight. In order for the carrier to identify redundant reservations, the carrier may need to identify the reservations based on the passenger rather than on contracts with travel agencies. This may be due to the possibility that the passenger has redundant reservations scattered between multiple booking records and / or with multiple travel agencies.

In some cases, a carrier who detects a redundant reservation can allocate time to the travel agents involved to resolve the redundancy of reservation with the passenger before the carrier takes action. For this purpose, the carrier may establish a deadline for identified redundant reservations; after this period, the carrier can take corrective actions if the travel agents were unable to resolve the redundancy of the reservation. By linking passengers to booking records on multiple booking systems, booking record recording can allow carriers to quickly identify and link redundant passenger name records, and set up alarms to verify that redundant booking records have been changed to resolve the problem.

By providing a single database record that is linked to each booking record associated with a particular traveler, the booking record record can allow carriers to reassess these associated booking records in near real time. The reservation record record can link multiple reservation records that apply to the same passenger even when these reservation records are stored in different databases. Carriers can calculate discrepancies between these booking records and apply pricing rules such as time periods, or minimum length of stay, for the entire trip. If discrepancies are found, faulty booking records can be queued for correction or cancellation.

The registration of the reservation file can also facilitate the management of the integrity of the receipts for all the groups of travelers. Carriers may have specific policies for large groups, but enforcing these policies can be difficult when travel arrangements are spread across multiple booking records. Revenue integrity rules require that certain conditions be met when reservations are made for a group of travelers. For example, the group may be required to provide a minimum deposit before a specified date and to provide passenger names, passport information and other required data, in specified increments that meet required thresholds, before certain dates. The carrier may also be required to collect payment and issue tickets for passengers, in specified increments that meet the required thresholds, before certain dates. These conditions can apply to the entire group without taking into account the spreads between multiple booking records. Booking record registration can facilitate monitoring of this type of group rules by linking all reservation records that have been booked as a group. The consolidated view provided by the booking file can allow agents to check and apply the carrier's group policies, store any delays for tour operators and allow the carrier's agents to trigger actions when booking conditions are not met.

In some cases, the pricing of the carrier and other policies may be based on the origin and destination of the trip rather than on each portion of the route independently. In other words, carriers may prefer to establish policies that take into account a complete passenger itinerary rather than individual segments connecting origin and destination. For example, policies regarding pending payments for a portion of a trip may apply different rules when the passenger has already started their trip or when the trip turns out to be longer than the predetermined duration. When trips include travel products booked through multiple bookings, it may not be possible to apply such policies using systems lacking the feature of the booking record. The booking record may allow the application of policy rules which apply the integrity of the recipes to the complete itinerary of the traveler and which provide improved treatment to passengers with complex routes.

As another example, the registration of reservation files can facilitate the provision of services to the traveler or to groups of travelers whose booked trips are disseminated through multiple reservation records. Typically, providing a service to a traveler whose travel itinerary is spread across multiple booking records requires that the service be booked individually for each booking record. With conventional systems, this requires that a travel agent can identify each travel reservation. Providing the service may also require the carrier's agent to depart from the default rules in order to apply specific fares or discounts, such as group discounts or reduced fares because a return flight is booked on another booking record. In addition to increasing the workload of agents and increasing the chances of making mistakes, the result is a lack of capacity to provide services automatically when faced with multiple booking records, which can, for example, prevent carriers to offer services directly on their website or through online travel agencies due to a lack of automation.

An example of services that can be reserved for multiple registrations of

1S reservation may include the reservation of cabin baggage. The reservation of cabin baggage may be a chargeable service, the total price of which may be higher if the reservation is made for several individual flights compared to the price of a reservation for the service for a single connecting flight. Another possible example is that of family members across multiple booking records who wish to sit together on 20 of the common flights on their route. By linking together all booking records including a trip, the booking file can also allow travel providers to automatically associate the booking records of a passenger or group of passengers and to make joint requests for services for all linked booking records.

Here is yet another possible example of a feature made possible by the registration of a reservation file: carriers and travel agencies can use the registration of the reservation file to maintain a personal travel registration for travelers with a high level of travel. value. Personal trip registration may allow authorized parties to access historical and current information on journeys made by the high-value traveler. Personal travel registration can be provided by assigning permanent identifiers to the high value traveler and the booking record registration associated with the traveler. The booking record record can be used to provide a container for all trips made by the traveler, thus allowing travel agents and carriers to have a view of all past and current trips booked by the traveler at high value. Providing views of other trips made by the high-value traveler in real time can enable travel agents to provide improved service to these travelers. [0094] If only for the reasons described above by way of example, the recording of reservation files can increase productivity by reducing the amount of time required to add a service to multiple reservation records and manually apply price exemptions and reductions. Booking record registration can also allow carriers to increase the value of their products by offering services, fares and discounts directly through travel agents or automated websites, generating more satisfaction for the customer and favoring cross-trade or high-end trade. Booking record registration also allows a single payment for services recorded on multiple booking records, thereby simplifying the booking process and potentially reducing credit card fees for multiple transactions.

FIG. 10 represents an exemplary process 210 which can be executed by one or more of the GDS 12 and by the client application 70 to create a reservation file. In an exemplary scenario, a travel agent may be asked to assist in planning a trip. In response, the travel agent can enter the client application 70 indicating the desire to create a reservation file. To initiate the creation of the reservation file, the client application 70 can transmit a query to the GDS 12 asking the GDS 12 to create a reservation file record. In block 212, and in response to receiving the request from the client application 70, the GDS 12 can create a reservation file record and store the reservation file record at the memory location active as described above with reference to FIG. 5. In response to the confirmation of the creation of 1 reservation record record by the GDS 12, the client application 70 can then invite the travel agent to enter the information concerning the stakeholders of the trip. This data can, for example, include the names of all travelers and their contact information. In response to the entry of this data by the travel agent, the client application 70 can transmit another query to the GDS 12, requesting that the data entered be stored in the reservation file record. In block 214. and in response to receipt of the query, GDS 12 can add one or more fields to the reservation record and store stakeholder data in the added fields.

When the travel agent has finished entering the data of the stakeholders, the travel agent can provide an indication to the client application 70 indicating that he wishes to validate the reservation file. In response, the client application 70 can transmit a validation command to the GDS 12. In block 216, and in response to the reception of the validation command, the GDS 12 can validate the registration of the reservation file by generating a new booking record registration identifier and save the booking file recording in the booking file database 20. The validation of the booking file recording by saving it in the database 20 can make the reservation file registration visible to other applications.

The unique registration identifier can be assigned to the reservation file upon initial validation of the registration of the registration file * In one embodiment of the invention, the unique registration identifier may be a multi-digit number (e.g., 10 digit). Unlike some conventional reservation records, such as PNRs, this digital format can provide access to the record of the reservation record worldwide, including in countries where the Roman alphabet is not of usage, e.g. Asia, Russia, the Middle East.

Once the reservation record registration has been validated, travel agents can start looking for travel products that meet the traveler's travel criteria. As travel products are identified, the travel agent may create one or more reservation records (eg, PNRs) that include a reservation for the identified travel products. Travel records can be stored in a single reservation system or in multiple reservation systems. During the booking process for travel products, the travel agent can enter the client application to indicate that one or more booking records should be added to the booking file. In response, the client application 70 can send a query to the GDS 12 which identifies the reservation records to be added, for example. ex. by transmitting a query that includes the record locators for the reservation records and the identity of the corresponding databases in which the reservation records are stored.

In response to the reception of this interrogation, the GDS 12 can continue to block 218 and recover the registration of reservation file in the reservation database 20.

The GDS 12 can then continue to block 220 and associate the reservation records with the reservation file record. Reservation records can be associated with the reservation record record, for example, by adding one or more fields to the reservation record record and by storing record locators in the added fields. In this way, the booking records can be associated with the booking file record without impacting the booking records. Once the travel agent has finished adding the reservation records to the reservation file, the travel agent can enter the client application indicating that they wish to validate the reservation file. In response to the reception of this entry, the client application 70 can send a validation command to the GDS 12. The GDS 12 can then proceed to block 222 and validate the reservation file registration by saving the updated file registration in the reservation files database 20. Once saved, the changes made to the reservation file registration may be visible to other applications which access the reservation files database 20.

[00101] FIG. 11 represents an exemplary process 230 which can be executed by one or more of the GDS 12 and by the client application 70 to add a travel product to an existing trip using the characteristic of the reservation file. After a period of time (eg, several days), the traveler in the above exemplary scenario can contact the travel agent and request the addition of an additional product, such as a car rental, to trip. The client application 70 can allow the travel agent to search for a reservation file on the basis of the file identifier, of a record locator of one of the reservation records associated with the reservation file, the name of the passenger or another stakeholder, or any other element stored in the record of the reservation file or associated with it. Thus, if the traveler does not know the file identifier, the travel agent can search the reservation file based on the name of the traveler.

For this purpose, the travel agent can enter the name of the traveler in a search field of the client application 70 and the client application 70 can send a query to the GDS 12 asking the GDS 12 to return the records of reservation file which include the search term. In response to receipt of the search query, the

GDS 12 can continue to block 232 and search the reservation records database 20 to find the reservation record records that match the name of the traveler. In response to identifying a corresponding reservation record, the GDS 12 may continue to block 234, retrieving the corresponding reservation record from the reservation record database 20, storing the record in an active memory location and transmit the recording to the client application 70. When more than one corresponding reservation file record is found, the GDS 12 can transmit a response to the client application 70 by inviting the agent of travel to select the correct booking record, or request that a new search be performed if none of the records appear correct.

In response to the reception of the reservation file registration, the client application 70 can retrieve the reservation records associated with the reservation file registration in their respective databases and display the reservation file at travel agent. The travel agent can then provide an entry to the client application 70 identifying a reservation record for the vehicle rental to be added to the trip. In response, the client application 70 can continue to block 236, retrieve the reservation record from its respective database, add the reservation record to the reservation file and display a new total price for the trip which includes the reservation. newly added. Retrieving and adding reservation records to the reservation record record can be done without impacting the reservation records themselves.

If the traveler does not wish to accept the new price, the travel agent can search for a vehicle rental at a lower cost, for example by booking a cheaper vehicle category. Once a replacement vehicle has been reserved, the travel agent can enter the client application 70 indicating that the new reservation record must replace the previous reservation record. In response to receipt of this entry, the client application can continue to block 238, remove the old reservation record from the reservation file, add the new reservation record to the reservation file and display a new total price for the trip. .

If the traveler agrees to pay the new total price, the travel agent can enter the client application 70 which causes the client application 70 to send a validation command to the GDS 12. In response to the reception of the validation command, the GDS 12 can continue to block 240, add the registration locator for the new reservation registration to the reservation file registration and validate the reservation file registration by storing the registration reservation file in the reservation file database. Once the booking record has been validated, the travel agent can send a summary of Γ itinerary to the traveler for the entire trip. To generate this summary, the client application 70 can send a query to the GDS 12 to retrieve the reservation file registration. In response to receipt of the query, the GDS 12 may continue to block 242, retrieve the reservation record record from the reservation record database 20 and transmit the reservation record record to the application client 70.

In response to receipt of the reservation file registration, the client application 70 can retrieve the reservation records associated with the reservation file registration in their respective databases and display the reservation file at travel agent. The client application 70 can then, on invitation from the travel agent, continue to block 244. In block 244, the client application 70 can generate an aggregated route based on the contents of the reservation file and transmit the aggregated route to the traveler, p. e.g. using an email address or other contact information from the traveler in the booking file.

Later, typically before departure, an intermediate office application (not shown) can generate an invoice for the trip and send the invoice to the traveler. For this purpose, the intermediary office application can send a query to GDS 12 requesting the registration of the reservation file corresponding to the file identifier for the trip. In response to the reception of the search query, the GDS 12 can retrieve the reservation file record identified by the file identifier in the reservation file database 20, store the recording in a storage location. active memory and transmit the recording to the intermediate office application. The intermediary office application can, in turn, retrieve the reservation records identified by the reservation file registration in their respective databases, generate an invoice based on them and transmit the invoice to the traveler.

The reservation record registration allows the aggregation (ie, grouping) of multiple reservation records without replicating copy data of reservation records from different systems. The reservation file record is kept in a centralized database so that an external system can access it and retrieve the reservation file for consultation or modification based on the file identifier. The reservation records associated with the reservation file registration are specified on the basis of the registration identifiers in the retrieved reservation file and are retrieved from their corresponding databases to fill the reservation file with the details of the registration records. reservation and to allow changes. Links to booking records through T through a single centralized source, i.e. _s the reservation record, can eliminate the need to replicate and store multiple copies of reservation records between different databases at GDS 12 and 14a-14m provider systems. In a conventional system with distributed copies containing replicated data, the trip data stored in the different databases may become out of sync when a copy of a reservation record is changed in the database of a system without that a copy of the reservation record stored in a database of another system is also modified, The centralization enabled by the reservation file can eliminate the need to perform a synchronization operation which updates and corrects the copies data in reservation records on the various system platforms operated by GDS 12 and by supplier systems 14a-14m.

In general, the routines executed to implement the embodiments of the invention, whether implemented as part of an operating system or of a specific application, of a component, of a program, object, module, or sequence of instructions, or even a subset of them, may be referred to herein as "computer program code" or simply "computer code program ".

Program code typically includes computer readable instructions which reside at various times in various memory and storage devices in a computer and which, when read and executed by one or more processors in a computer, bring the computer to perform operations necessary for the execution of operations and / or elements specific to the implementation of the various aspects of the embodiments of the invention. The instructions of a program, readable by computer, to implement the operations of the embodiments of the invention can be, for example, the assembly language, or even a source code or an object code written in combination with one or more programming languages.

Various coded programs described herein can be identified depending on the application in which they are implemented in specific embodiments of the invention. However, it will be noted that any nomenclature of a particular program which follows is used purely for convenience and that the invention is therefore not limited to the sole use of a specific application identified and / or implied by said nomenclature. Furthermore, in view of the generally infinite number of means by which computer programs can be organized according to subroutines, procedures, procedures, modules, objects, and so on, as well as the various ways of allocating the functionality of a program among various layers of software that resides in a typical computer (eg, operating systems, libraries, program application interfaces [APIs], applications, applets, etc. .), it will be noted that the embodiments of the invention are not limited to the specific organization and to the specific allocation of the program functionalities as described herein.

[001 H] The program code integrated into any of the applications / modules described herein can be distributed individually or collectively as a computer program product, in a variety of forms. In particular, the program code can be distributed using a computer readable storage medium, having in itself computer readable program instructions allowing a processor to implement aspects of the embodiments of the program. invention.

The machine-readable storage media, being intrinsically durable, can include volatile and non-volatile, removable and non-removable tangible media, implemented in any data storage process or technology, such as computer-readable program instructions , data structures, program modules, or other data. Computer readable storage media can also include RAM, ROM, Programmable and Erasable Exclusive Read Memory (EPROM), Electrically Erasable Programmable Exclusive Read Memory (EEPROM), 5 Flash memory, or any solid support technology memory, a portable compact disc with read-only memory (CD-ROM), or other optical storage, magnetic recording tapes, magnetic disc memory, or any other medium that can be used to store desired data and suitable for reading by a computer. A computer-readable storage medium cannot be interpreted as "transient signals" per se (eg radio waves or any other electromagnetic waves propagating through a transmission medium such as a waveguide, or electrical signals transmitted by cable). Computer-readable program instructions can be downloaded to a computer, another type of programmable data processing device, or any other machine-readable storage medium, or to an external computer or to an external storage device via a network.

Computer readable program instructions stored on a computer readable medium, other types of programmable data processing apparatus or other devices to operate in a particular way, such as instructions stored on a computer readable medium, produce an article of manufacture comprising the instructions which implement the functions, actions and / or operations specified in the flowcharts, sequence diagrams and / or block diagrams. The computer program instructions may be supplied to one or more processors of a general purpose computer, a dedicated computer or other programmable data processing apparatus to produce a machine, so that the instructions, when executed using one or more processors, perform a series of calculations to implement the functions, actions, and / or operations specified in the flowcharts, sequence diagrams and / or block diagrams.

In certain alternative embodiments, the functions, actions and / or operations specified in the flowcharts, sequence diagrams, and / or the block diagrams can be ordered again, processed in series, and / or processed at the same time in accordance with the embodiments of the invention. In addition, any flowchart, sequential diagram, and / or block diagram can include more or less blocks than those illustrated in accordance with the embodiments of the invention.

The terminology used herein is intended to describe only specific embodiments and is not intended to limit the embodiments of

5. the invention. Furthermore, the verbal forms "includes", "include" and / or "comprising", when used in this specification, specify the presence of characteristics, whole numbers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more characteristics, whole numbers, steps, elements, components and / or groups, in this. In addition, to the extent that the verb forms "includes", "having", "a", or variants, are used in the detailed description of the claims, these terms are intended to be inclusive in a manner similar to the verb "to understand".

Although the invention is illustrated by a description of various embodiments and although these embodiments are described in great detail, it is not the intention of the applicant to restrict or limit, to in any way, the scope of the claims herein to these details. Additional advantages and possible modifications will be readily apparent to those skilled in the art. The invention from a wider angle is therefore not limited to specific details, representative methods and apparatus, and to the illustrations shown and described by way of example. Therefore, it is possible to move away from

50505 A5013280FRP00Mm Amended claims (clean copy) September 12, 2017

Claims (7)

1. A data processing system comprising: one or more processors; and a memory coupled to one or more processors, the memory storing data comprising a reservation file database and a program code configured to, when executed by one or more processors, cause the system to: receive a first request to consult the reservation file, the first request including a search term; in response to receipt of the first request, retrieving a reservation record record corresponding to the search term in the reservation record database, the reservation record record defining a first identifier which identifies a first reservation registration; the use of the first identifier of the reservation file record to retrieve the first reservation record; and transmitting the reservation file to a user system, the reservation file including a first item of data from the first reservation record. 2. The data processing system according to claim 1 in which the program code is configured to cause the system to: create the reservation file record in the reservation file database; and associate the booking record with a booking record. The data processing system according to claim 1 or claim 2 wherein the reservation record record defines a second identifier which identifies a second reservation record, and the program code is further configured to bring the system at : use the second identifier of the reservation file record to retrieve the second reservation record; and adding a second item of data from the second reservation record to the reservation file. 17 50505 A5013280FRP00Mm Amended claims (clean copy) September 12, 2017 4. The data processing system according to any one of claims 1 to 3 in which the program code causes the system to retrieve the reservation file registration by: attaching a context header to the request using a context coordinator; transmitting the request from the context coordinator to the reservation file database; retrieving the reservation file from the reservation file database; storing the reservation record in the context header attaching the context header to a response; transmitting the response from the reservation file database to the context coordinator; and the context coordinator detaching the context header from the response. 5. The data processing system according to any one of claims 1 to 4 in which the program code is configured to cause the system to create the reservation file record in the reservation file database by: receiving, before the first request, a second request which includes the search term and the first identifier; in response to receipt of the second request: storing the search term in a first field of the reservation file record, storing the first identifier in a second field of the reservation file record, generating a file identifier, and storing the file identifier in a third field of the reservation file record; and storing the reservation record in the reservation record database. 17 50505 A5013280FRP00Mm Amended claims (clean copy) September 12, 2017 6. The data processing system according to any one of claims 1 to 5 in which the reservation file is transmitted to the user's system via an application programming interface, and further comprising: a client computer running a client application serving as an interface with the application programming interface and providing a user interface for displaying the reservation file; and a server computer running a database management application which manages the reservation file database. 7. The data processing system according to any one of claims 1 to 6 in which the reservation file record aggregates a plurality of reservation files without replicating the data in any of the reservation records seen ό LL · 2/11 3/11