FR3021787A1 - - Google Patents

Abstract

A content management method provided by one or more content providers (4, 5) in a content management system comprising an application aggregator (3) comprising a set of applications and a data structure extended recording (9). The extended record data structure includes a standard record data structure (90) for storing a record associated with standard data elements of standard predefined types and a non-standard record data structure (91) for store records associated with non-standard data items having a non-standard type other than the standard predefined types. The method includes receiving content from one or more content providers (4, 5), said content comprising a set of associated data items of respective types, and, for each data item: - the creation of a record for the data item in the standard record data structure (90) if the data item has a standard type, said record including a common record identifier and data values corresponding to the item of data ; generating a non-standard data container for said data element if the data element has a non-standard type and creating a record for the data element in the registration data structure non-standard (91), the record including the common record identifier and data values corresponding to the data item; the content management method further comprising managing access to the records maintained in the extended record data structure (9) based on the common registration identifier.

Description

BACKGROUND OF THE INVENTION The present invention relates generally to data management systems, and particularly to methods, systems and computer program products for managing content including standard content and non-content content. standard. Content management systems can provide access to specific content to one or more customers (eg, end users) connected to the system via dedicated communication networks.

With the emergence of a huge number of content distribution providers in each industry sector, there is a need for each consumer to be able to access multiple content providers via a single content management system. For example, in the tourism industry, travel management systems 15 can be used to distribute content obtained from a set of travel provider systems (content providers) to a plurality of travel agency systems. travel (consumers of content). The tourism industry has grown considerably in recent decades and, at the same time, the services offered by the tourism industry have changed considerably, so that a wide variety of services 20 is now available to end consumers , involving heterogeneous content. In addition, the tourism industry now involves many players between travel suppliers and end consumers, with a huge amount of data to manage between these different actors. Between the travel supplier and the end user, travel intermediaries such as Global Distribution Systems (GDS) provide Travel Management Systems to enable tour operators to retrieve information from suppliers. traditional travel (airlines), or to conduct transactions between end consumers and traditional travel providers. The travel agency business model, which focused primarily on the exclusive distribution of air transport, is evolving and players are now achieving higher margins through non-airline content. A wide variety of services offered by new types of travel providers are thus offered at destination. With the attractiveness of these alternative distribution channels, travel agencies tend to distribute more non-GDS content (eg hotels, car rentals, etc.) in addition to the usual GDS content (for example, a travel content by 5 plane or by train). However, conventional travel management systems do not provide adequate means to directly provide travel agencies with non-GDS content information. As shown in Figure 1, a travel management system 1 generally includes a registration data structure such as a "Passenger Name Record" data structure 900 for storing records associated with received GDS content. directly from GDS content providers 40. Each record (PNR) is identified in a database BD by a folder mark. PNR file markers can then be used to access GDS content and distribute it to client devices such as tour operator or end-user systems (60). The PNR 900 data structure contains a file mark in association with travel data associated with a given passenger or a group of passengers traveling together (the file mark is also known as a confirmation number, a reservation number, a confirmation code, a reservation reference, etc.). For example, when a reservation is made for a passenger or a group of passengers, a PNR is created in the data structure 900, this PNR comprising a file reference and data corresponding to the content of the reservation (for example, data flight such as arrival time, departure time, etc.).

Currently, travel management systems can not directly receive non-GDS content from non-GDS 50 travel providers due to standardization constraints. Indeed, the manner in which a travel management system exchanges with a standard travel provider (40) is subject to the rules defined by the International Air Transport Association (IATA) in the Procedures. of ATA / IATA Reservations Interline Reservations - Passengers 3021787 3 (AIRIMP, "ATA / IATA Reservations Interline Message Procedures - Passenger"). In particular, the messages exchanged between a standard travel provider 40 and the travel content management engine 30 must satisfy a TTY message exchange format (Teletype format) defined by the IATA standard and the conventional 900 PNRs are 5 configured to process only the content received in such a TTY format. No industry standard is defined as such for the topology and content of a PNR 900. However, each travel management system (for example, a Computer Reservation System (CRS) ) defines its own proprietary standards for the topology and content of the PNR, taking into account the limitations of the AIRIMP and in particular the need to easily match PNR data with AIRIMP messages. similarities in the content and formats of PNR 900 data maintained by different travel management systems, in particular, each PNR 900 data structure is such that travel data associated with a file reference must satisfy number of predefined types that correspond to the GDS content standardized by IATA (aerial data, rail data, etc.) Therefore, only GD content S (for example, aerial, railway data) can be stored in the PNR 900 data structure in a static format satisfying the constraints associated with the IATA message exchange standard. It is therefore not possible to create a record for non-GDS content (vehicle rental, jet-ski, etc.). Document US2012259667 proposes a solution for the storage of non-GDS content in the PNR 900 in the form of remarks, various segments or ghosts. However, such a solution does not allow the travel management system to dynamically and fluidly store non-GDS content received directly from a non-standard travel provider in a structured manner in advance. in the PNR 900 among other non-GDS elements. Conventional travel management systems 1 only deal with content from GDS travel providers, such as airline providers. A conventional travel management system includes a travel content management engine using a considerable number of applications, each application being associated with a specific travel service (eg booking, shop, price, etc.). In response to a request from a given travel agent Ai (70), the travel content management engine 30 can only retrieve content from GDS travel providers 40, generate a record in the PNR 900 and send back a representation of the PNR record thus created to the travel agent Ai.

Each travel agent must be directly connected to a set of non-GDS 50 content providers if the travel agent needs access to non-GDS content, while the travel management system 1 is directly connected only to In addition, each travel agent is directly connected to a specific set of travel providers 50 to obtain non-GDS travel content (taxi, show tickets, etc.). The travel content management engine 30 thus exposes n travel service platforms (a platform 2.1, 2.2, ... 2.i, 2.n for each tour operator Al to An), while dealing only with the content Standard travel (GDS content) from standard travel providers 40. Therefore, if a given travel agent Ai wishes for specific content from a non-standard travel provider 50 (for example, a museum ticket), this content must be implemented personally by the travel agent Ai. This personal implementation is particularly expensive and complex for tour operators. There is therefore a need for improved content management computer program systems, methods and products for content management, to dynamically and fluidly distribute any type of content from any content provider (at a time). standard and non-standard content) through a single platform. SUMMARY In order to solve these and other problems, there is provided a content management method as defined in the independent claim 1 presented in the appendix, and a content management system as defined in the independent claim 12 presented in the appendix. Preferred embodiments are defined in the dependent claims. The method and system according to the various embodiments of the invention enable the content management device to directly receive any type of content, while eliminating the need for the client device to receive the content separately. not standard. In addition, the use of a common identifier shared by the standard registration data structure and the non-standard registration data structure allows the non-standard data container to manage access to the data items as if they were stored in a single record data structure.

Other advantages of the present invention will become clear to those skilled in the art upon review of the drawings and the detailed description. It is expected that any additional benefits will be incorporated here. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated herein and which constitute a part of the present application, illustrate various embodiments of the invention and, together with the general description of the invention given above and the Detailed description of the embodiments given below serve to explain the embodiments of the invention. Figure 1 is a schematic view of a conventional content management system according to the prior art; Figure 2 is a schematic view of a content management system according to some embodiments including a plurality of computer systems connected via a network; Figure 3 is a schematic view of a representative operating environment including a content management system; Figure 4 is a schematic view of a computer system representative of Figures 2 and 3; Fig. 5 is a flowchart describing a process that can be executed to add new content to the extended record data structure; Figure 6 is a schematic view of the structure of an internal application running in the content management system according to some embodiments; Figure 7 is a schematic view describing the operation of an internal application based on technical objects of the type Business Object Model; Figure 8 is a schematic view of the content management system describing representative interactions between internal applications; Figure 9 is a schematic view of a representative non-standard data container defined by a set of key values; Figure 10 is a schematic view of representative serialization formats; Figure 11 is a schematic view of the representative non-standard data container of Figure 9 with type information included in the non-standard data container; Fig. 12 is a schematic view of the representative structure description file associated with the non-standard data container of Fig. 12; Figure 13 is a flowchart of a method that can be executed for content access by an application; Figure 14 is a schematic view of a representative content exchange unit; Figure 15 is a flowchart of a process that can be executed to transmit content to a client device; Fig. 16 is a schematic view of an XSLT conversion of a standard C-type data container; Figure 17 is a schematic view of an XSLT conversion of a non-standard data container of the same type C as the standard data container of Figure 16; Figure 18 is a schematic view of an XSLT conversion of a standard D-type data container comprising a set of attributes; Figure 19 is a schematic view of an XSLT conversion of a non-standard type E data container having certain attributes identical to the attributes of the standard data container of Figure 18; Figure 20 is a flowchart of a process that can be executed to rearrange data items; and Figure 21 is a schematic view of an extended record data structure, according to some embodiments. DETAILED DESCRIPTION The methods, systems, and computer program products according to embodiments of the invention can enable dynamic management of any type of content (standard and non-standard) received from content providers and a user. centralized storage of records associated with this content, regardless of the type of content. The content management system 100 may be based on a client / server architecture 5 for receiving customer requests. Referring to Figure 2, there is provided a content management system 100 through which a number of user clients 7 can directly access, via a single platform, any type of content provided by a set of Content provider systems 4, 5. The content processed by the content management system 100 may be received from standard content provider systems 4 communicating with the content management system 100 according to a first type of format. message exchange 14, such as a predefined standardized message exchange format, or non-standard content provider systems 5 communicating with the content management system 100 according to a second type of message exchange format. messages 15.

The content management system 100 may be connected to a communication network 13, which communication network 13 may include the Internet, a local area network (LAN), a wide area network (WAN), a cellular voice / data network, one or more high speed bus connections, and / or other communication networks of this type. The content management system 100 may be dedicated to one or more specific fields (for example, the travel field). One or more client devices 7 may each be connected to the communication network 13, so that a user can initiate a service request session with the travel management system 100 and receive content from the management system of the service. 100 trips in response to the service request.

Embodiments of the invention may be implemented by a computer system comprising one or more computers or networked servers. The computer system can provide processing and database functions for content management. Each client device 7 may be a personal computing device, a tablet computer, a thin client terminal, a smartphone and / or such other computing devices. Each client device 7 may host web browsers and / or custom application software (for example, a client system) and may include a client user interface. Each content provider system 4 or 5 may be connected to the communication network 13. Each content provider system 4 or 5 may host one or more websites and / or have a hosting service hosting one or more websites. . A user (ie, a traveler) using one of the client devices 7 can connect to the content management system 100 using the client device 7 during a service request session associated with an application (accessed, for example by 10 connection to a web service). The content management system 100 includes a content management engine 3 for processing the service request from the client device 7. The content management engine 3 can exchange messages with the standard travel providers 4 using the data format. standardized IATA message exchange according to the IATA standard (first message exchange format 14).

The content management engine 3 can furthermore exchange messages with the non-standard providers 5 via a data exchange unit 11. The data exchange unit 11 can use messages defined according to a description language such as the extensible markup language (second message exchange format 15) for communicating with non-standard content providers, for example in response to a search, a reservation, a quote, a delivery a cancellation request from a user client 7 associated with a travel agent entity (for example, a travel agent operator or a travel agent system). The user can submit the service request to the content management system 100 by entering information at the client device 7 via a graphical user interface generated on the client device 7 by an application running on the management system. content 100 (for example, in the form of a web service). Information received from the user may be accumulated until the user submits the service request to the content management system 100 (for example, by performing a submission action).

In response to the user request, the content management engine 3 may request and obtain content from the content provider systems 4 and / or the message exchange formats 14 and / or 15 and store a record related to the retrieved content in an extended record data structure 9. The extended record data structure 9 may be stored in context and stored in one or more databases 8 in response to a backup request or else periodically. Alternatively, in some embodiments, the extended record data structure 9 may be stored directly in one or more databases 8. The extended record data structure 9 includes a data structure of standard record 90 for storing records in association with standard data and a non-standard record data structure 91 for storing records in association with non-standard data. A record includes a record identifier (also referred to as a "folder mark") in association with related data items. The registration identifier may be of any type or format, such as a number.

The standard record data structure 90 is static because it is only adapted to store a record for predefined types of content (called "standard" content) having one or more of a predefined set of attributes. As used herein, the term "standard" refers to standard content having a predefined format and / or type corresponding to the format and / or types supported by the standard record data structure 90. A record may be added in the standard record data structure 90 for a received content including related data items, if the received content includes only standard data items. The record includes a record identifier in association with the data items.

Alternatively, a record may be added to the non-standard record data structure 91 for a received content including related data items, if the received content includes only non-standard data items. The registration includes a registration identifier in association with at least one non-standard data container including non-standard data elements.

In addition, a record may be added to the standard record data structure 90 and the non-standard record data structure for content received including related data items, if the content received includes non-standard data items and a standard record data structure 90. The two records added for the content standard received in the record data structure 90 and the non-standard record data structure. standard 91 can both be assigned the same registration identifier (hereinafter referred to as "common registration identifier"). The common registration identifier is shared between one or more standard data elements (standard content) in the standard registration data structure 90 and / or one or more non-standard data containers (including non-standard data elements). -standard) in the non-standard record data structure 91. Using the same record identifier in the two record data structures 90 and 91 to identify related standard and non-standard data items, the content management system 100 can handle the two record data structures transparently as if they formed a single record data structure. The content management engine 3 can register a number of applications associated with different services. The content management engine 3 may execute one or more applications depending on the service request received from the client device 7, which may trigger content recovery from content provider systems and the storage of the related records. this content received in the extended data structure 9. The content management engine may further be configured to return the response to the service request, based on the records stored in the extended record data structure 9, regardless of whether or the content type, to the user clients using the content stored in the extended registration data structure 9. To return the response to the clients, the content management engine 3 may use a data exchange unit 11 to generate a uniform representation of the content of the client devices 7, regardless of the types of content included in the The content management engine 3 thus acts as an aggregator of applications to provide services to the client users 7. In a preferred embodiment of invention, the content management system 100 may be a Travel Management System. The travel management system 3021787 11 100 can be implemented by an intermediate operator (for example, a global distribution system (GDS) in the travel field) to allow centralized management of the travel content, implemented for example by a GDS (acronym for "Global Distribution System").

Figure 3 shows an operating environment representative of such a content management system 100 implemented in a GDS 1. In this embodiment, the standard content refers to the GDS content compatible with the IATA constraints (such as as aerial, railway data) provided by standard travel provider systems 4, while non-standard content may be any type of non-GDS content that does not meet IATA constraints (eg, car rental). ) provided by non-standard 5 or non-GDS travel provider systems. The standard registration data structure 90 may be a standard PNR data structure (hereinafter also referred to as "standard PNR", PNR being the acronym for "Passenger Name Record") which is configured to store standard content while the non-standard registration data structure 91 (hereinafter also referred to as "non-standard PNR") is configured to dynamically record any type of non-standard content without It is necessary that the types and attributes of non-standard content be predefined by a hardware encoding of the mechanisms for mapping and compiling data. The standard PNR 90 generally includes a complete set of data for a travel route, including segments from multiple carriers, with predefined data structures (types, attributes, families) and / or other services constituting the trip, such as hotel and rental vehicle reservations. The extended registration data structure 9 forms an Extended Travel Record (hereinafter also referred to as "Extended Travel Record"), where each content record can be handled in a fluid manner by the search engine. content management 3 regardless of the type of content associated with the record. The client devices 7 may be associated with a plurality of travel agent systems 700 requesting services via respective client interfaces 2. More particularly, the travel management system 100 may also access different types of client devices submitting different types of requests according to a client / server approach, such as traveler devices 6 via respective user interfaces 2 or even travel provider systems 4 or 5 (for example, for the exchange of content stored in the server). 'Extended Travel Registration 9). Standard travel provider systems 4 may include a plurality of airline or traveler systems. Non-standard travel product provider systems 5 may include vehicle rental systems, museum reservation systems, and the like. When implemented, company systems may include a Computer Reservation System (CRS) and / or billing system for the relevant airline, which allows GDS 1. Travel agencies 700 may be configured to book and pay for travel tickets and / or additional services provided by non-standard travel providers. Some standard travel provider systems may also interact with each other, either directly or via GDS 1, to allow an issuing company to sell tickets for seats provided by an operating company. The operating company may then charge the issuing company 15 for the services provided. GDS 1 can be configured to facilitate communication between travel providers 4 and 5 and travel agency systems 700 by allowing travel agents, carriers, or other indirect sellers to search for available segments and make bookings on one or more systems of 20 companies 4 and search and book additional services (eg vehicle rental, museum tickets, etc.) via the GDS 1. Each travel agency system 70 may include a web server that provides a publicly accessible website. This website may be configured to provide access to travel planning features, such as the ability to search for travel products matching a travel request. For this purpose, the travel agency system 70 can provide the traveler with access to data from one or more databases hosted by GDS 1, travel providers 4 and 5, and the agency system. In another embodiment of the invention, the travel agency system 70 may be a proprietary system that limits access to travel service providers or tour agents, in which case be provided via a private website or other application. Travelers or travel agents may use the travel agency system 70 to generate and / or search for travel proposals that satisfy a travel request received from the traveler using a specific travel application. travel (for example, a travel planning application). Passenger devices 6 can be connected directly to the travel management system 100 via a public or private network 13 (for example, the Internet). The traveler device 6 may be any appropriate computer system configured to communicate on the network 13 with the travel management system 100. For example, the traveler device 6 may comprise a desktop computer, a laptop computer or a tablet, a smartphone, or any other computing device that allows a traveler to search and book travel services on the network 20. In one embodiment of the invention, the traveler device 6 may include a browser application. A web that communicates with a web services application hosted by the content management engine 3 of the travel management system 100 for submitting travel requests based on the web services application.

Alternatively, the traveler device 6 may include a web browser application that communicates with a web services application hosted by the travel agency system 70. The web services application may, in turn, communicate with the travel management system 100 to submit the travel requests based on the travel service application.

Travel requests can be submitted, for example, to obtain data related to available travel segments, to generate travel proposals that satisfy the travel request and / or to reserve ancillary services (for example, vehicle rental, jet ski reservation, museum ticket reservation, etc.) corresponding to the non-standard content provided by non-standard providers 5, in connection with a trip provided via GDS 1 or via another GDS. Referring now to Figure 4, GDS 1, Travel Management System 100, Travel Provider Systems 4 and 5, Travel Agent Systems 70, Traveler Devices 6 of the Travel Environment, exploitation 10 may be implemented on one or more computer devices or systems, collectively referred to as a computer, such as the computer 30. The computer 30 may include a processor 32, a memory 34, a mass storage device 36, an input / output (I / O) interface 38 and a Human Machine Interface (HMI) 40. The computer 3021787 14 30 can also be operatively coupled to one or more external resources 42 via the network 22 and / or an I / O interface 38. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or all Another suitable computer resource that can be used by the computer 30. The processor 32 may include one or more devices selected from microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, networks user programmable logic controllers, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, or other devices that manipulate signals (analog or digital) according to instructions of operations that are stored in the memory 34. The memory 34 may include a single memory device or a plurality of memory devices including, but not limited to, a read only memory (ROM), a random access memory (RAM), a memory volatile, a nonvolatile memory, a static random access memory (SRAM), a random access memory dyn a memory, a cache memory, or any other device capable of storing information. The mass storage memory device 36 may include data storage devices such as a hard disk, an optical disk, a cassette player, a nonvolatile semiconductor device, or any other device capable of storing data. informations. A database 44 may reside on the mass storage memory device 36, and may be used to collect and organize data used by the different systems and modules described herein. The processor 32 may operate under the control of an operating system 46 that resides in the memory 34. The operating system 46 may manage computer resources such that an integrated computer program code in the form of one or more software applications, such as an application 48 residing in the memory 34, may have instructions executed by the processor 32. In another embodiment, the processor 32 may execute the application 48 directly, in which case the operating system 46 may be omitted. One or more data structures 50 may also reside in the memory 34, and may be used by the processor 32, the operating system 46 and / or the application 48 for storing or manipulating data.

The I / O interface 38 may provide a machine interface that functionally couples the processor 32 to other devices and systems, such as the network 22 and / or an external resource 42. The application 48 can thus work cooperatively with the network 22 and / or an external resource 42 communicating via the I / O interface 38 to provide the various features, functions, applications, processes and / or modules comprising embodiments of the invention. The application 48 may also have program code that is executed by one or more external resources 42, or otherwise rely on functions and / or signals provided by other system or network components external to the computer 30. Indeed, given the almost infinite number of possible hardware and software configurations, those skilled in the art will understand that the embodiments of the invention may include applications that are located outside the computer 30, distributed over several computers or other external resources 42, or provided by computer resources (hardware or software), in the form of a service on the network 22, such as a cloud computing service.

The HMI interface 40 may be operably coupled to the processor 32 of the computer 30 in a known manner to allow a user of the computer 30 to interact directly with the computer 30. The HMI interface 40 may include video and / or alphanumeric screens, a touch screen, a speaker, and any other appropriate audio and visual indicators capable of providing information to the user. The HMI 4020 may also include input devices and controls such as alphanumeric keyboard, pointing device, keypads, push buttons, control buttons, microphones, etc. capable of receive commands and input data from the user and transmit the inputs entered into the processor 32.

The following description will be made with reference to the content management system 100 of Figure 3, by way of example only. Different travel agents connected to the content management system 100 via respective travel agency systems 70 can therefore directly access, via a single platform, any type of content provided by a set of travel provider systems (4). , 5), regardless of the type of content (such as standard airline content, taxis, show tickets, etc.). The Travel Management System 100 therefore offers the possibility of storing not only standard content 3021787 compatible with the standard PNR data structure 90, but also any new type of content (ie, taxi rides, theater ticket, concert , gifts, etc.) while making it unnecessary for travel agencies to reserve such non-standard content outside the GDS system over the phone, or over the Internet, etc.

With the addition of a non-standard PNR 91 to the standard PNR 90, the travel management system can dynamically and seamlessly provide an unlimited number of travel services to the travel agency systems 70. Thus, a two-layer expanded travel record 9 thus forms a structured content representation provided by any travel provider system 4 or 5 (it may correspond for example to a product booked outside of the GDS), while the records recorded in ETR 9 can be accessed and managed as if the standard PNR 90 and the non-standard PNR 91 formed a single registration data structure. A standard data item (e.g., a product) in the standard PNR 90 is associated with a set of attributes that can be qualified as optional or mandatory depending on the topology and format implemented in the GDS 1 to be compatible with the IATA standard. The data recorded in the Extended Travel Record 9 can be classified into a plurality of families, each family including several types of data items such as, for example, the families shown in Table 1. The ETR 9 is adapted to support any number of new types and new families of data items. Table 1 Travel Overnight Meals Activities Services Air Hotel Restaurant Sports Activities Insurance Ferry Apartment Bar & Club Shops Visa Cruise Camping Other Shows & Sp Gifts Events Rail B & B Excursions Documentation 3021787 17 Coach Other Visits Recreational Equipment City Transportation Other Local Services Transfer Reunion Taxi Vaccin Car Other Bicycle Parking The content management engine 3 is configured to handle heterogeneous content of the ETR 9 which may include: adding new data items from any travel provider system 4 or 5 into the extended travel record 9, regardless of the type of content, for example in response to requests from travel agency systems 70; - the modification of data elements in the extended voyage record 9 (for example by changing the start date of a "Museum" product corresponding to a pre-reservation of two entries for a Museum); Erasing data elements from the extended trip registration 9 (for example by deleting the "Museum" product from the extended trip registration if a user has decided to remove this product from his trip to New Zealand. York). the retrieval of data items from the extended travel record 9 (for example by retrieving all the structured attributes of the "Museum" product in a specific travel record). The Extended Travel Record (9) can therefore store non-standard content and standard content as if they were part of a single registration data structure (PNR). The content management engine 3 manages the heterogeneous content recorded in the extended travel record 9, in a manner transparent to the user clients. The extended trip registration 9 is also flexible and adapted to any type of new content (taxi, metro, bus, museum ticketing, etc.), regardless of the attributes associated with the new content. The standard PNR 90 is organized according to the IATA standard. When a given set of data items is transmitted by a standard travel provider system 4 to the content management engine 3 via a message according to the first message exchange format 14 in an application flow associated with given service (for example, a reservation management flow), the following steps can be performed by the content management engine 3: i. the data may be retrieved by the content management engine 3 from the incoming message transmitted by the standard travel provider system 4, and ii. a record may be added in the standard PNR 90, the record including a record identifier in association with the data items corresponding to the data retrieved by the content management engine 3 (content data). The resulting data can be used to construct another message to be sent to a next application in the application stream. When the application flow involves a set of linked internal applications, step i. can be performed by a given internal application in the application flow, while step ii. can be triggered by another application of the stream. The data added in the standard PNR 90 may have only a limited number of predefined attributes and must respect one or more predefined types and formats (standard attributes). The non-standard PNR 91 is not compatible with the standard rules and constraints of the standard (IATA content definition, TTY messages, TATA messages). However, the non-standard content can be part of the Extended Travel Record 9 2 5 and be accessed in a fluid and transparent manner by the applications executed by the content management engine 3. The Extended Travel Record 9 can therefore store any type of standard content (eg, GDS content such as flight, hotel, vehicle, cruise, insurance, ferry) and non-standard content (such as bus / taxi / restaurant / etc.) in a structured manner 3 0 and in a universal format.

For dynamic management of any type of content, the content management engine 3 is configured to create a non-standard data container in response to received content including non-standard data elements transmitted to the management system. The non-standard data container 5 can dynamically adapt to the format of the internal application of the content management system that receives the data item. because of the self-serialization properties of the non-standard data container. When the receiving internal application is an application stream application involving a set of chained applications (internal applications), the non-standard data container can dynamically adapt to the format of each application. internally to which it is transmitted using the auto-serialization properties of the non-standard data container. More specifically, when the Travel Management System 100 connects to a new travel provider providing a non-standard content type, the non-standard data items received from the non-standard content provider system 5 may be stored in this non-standard data container assigned to the non-standard content type. A record can then be added to the non-standard registration data structure 91 by an internal application (for example, in an application stream). The record may include a record identifier and the non-standard data container having the non-standard content type. The non-standard data container may comprise a list of attributes, each attribute being represented by a key and a value. Each attribute itself may include a list of sub-attributes, each of which is represented by a key and a value (similarly for sub-attributes, etc.). Each attribute key is associated with a name and type. The non-standard data container is configured to self-implement which structure (s) it represents or the data they contain: for read-only access or access read / write (for example, get or set) any value of any attribute that is part of the non-standard data container, the non-standard data container allows such access via a method that does not depend on the name of the non-standard data container. the key and the type of the key, without it being necessary to implement methods of obtaining / parameterizing by hardware coding. The non-standard data container can therefore be used to create a new record in the non-standard PNR 91, regardless of the content type. This recording can be accessed transparently by the content management engine 3, for any type of content management actions, for example to execute travel applications, generate a service request result display on client devices 7, or transmit content to external devices (e.g., travel provider systems or travel devices). Referring now to Figure 5, there is shown a flowchart that describes a method for creating a new record in Extended Travel Record 9 in response to content received from one or more vendor systems. of travel.

In block 501, the content management engine 3 can receive content from one or more travel providers 4, 5 via message exchange formats 14 and / or 15, for example in response. a service request from a client device 7, such as a travel agency system. The content may include a plurality of related data items, e.g., data items relating to the same trip, such as a product of type Vol (standard data item) and a product of type Taxi (content not standard) received sequentially. Data elements associated with common content can be received sequentially or in parallel. Data elements may include information to identify that they are part of the same common content.

The data elements may comprise standard data elements (for example, a flight product) and / or non-standard data elements (for example, a Taxi product). Standard data elements (e.g., GDS content) may be received according to the first message exchange format 14 such as the TTY format.

The non-standard data elements can be received by the data exchange unit 11 in the form of a message defined according to a tag description language such as the XML language according to the second format of the exchange of data. messages 15. The following description will be made with reference to the XML message (also called document or XML file) for data exchange between the travel management system 100 and external systems. The data exchange message may include a structure description file to describe the message structure and the types and formats of the data contained in the message. For example, for data exchange messages of the XML, XML XSD type, schemes such as structure description files can be used to provide a representation of the structure of the attributes of the XML message. At block 502, for each piece of data received for the common content, the content management engine 3 can retrieve the data items. The content extraction can be performed by an internal application of the content management engine 3. If the data item corresponds to a standard content (for example, a product of the type Flight), the content management engine 3 creates a record R in the standard PNR (90) for the standard content (e.g., product of type Vol) using a standard data container (hereinafter also referred to as "standard container") at block 503 having the data element type (for example, the type Vol). The standard data container may be a static container configured for predefined data element types (standard data elements). The record R may be assigned a record identifier I and may be associated with the standard data container at block 505. The record may be stored in a temporary context and / or in at least one database 8. If the data item corresponds to non-standard content (for example, a taxi-type product), the content management engine 3 creates an R-record in the non-standard PNR (90) for the standard content (for example: Example, product of type Vol) using the non-standard data container (hereinafter also referred to as "standard container") at block 505. Step 505 can be triggered by an internal application of the application flow. The internal application triggering the creation of the record in the ETR may be different from the internal application receiving the non-standard data element of the data exchange unit 11. For example, a first internal application Al can receive the non-standard data element in the Al application F 1 format, the non-standard data element can be transmitted to the other internal applications of the chain until it arrives at a An internal application in the Fn format of the application An, and finally the application An triggers the creation of a record in the non-standard registration data structure 91 (the non-standard data container having the format Fn ). The non-standard data container can be assigned to the type of the data element (for example, Taxi type). The non-standard data container is adapted to contain any type of data element (non-standard data element). The record R may be assigned the same record identifier I and may be associated with the non-standard data container at block 506. The record may be stored in a temporary context and / or in at least one database .

In one embodiment, the non-standard data container created in block 506 may further be assigned a tag to block 507. This tag may be used by the content management engine 3 when accessing the file. R record, for example to identify data items that are not sent to client devices 7.

Therefore, a unique registration identifier I can be created in the standard PNR 90 and the non-standard PNR 91 for all standard data elements and the non-standard data elements corresponding to a common content (data elements related). This common registration identifier can thus be shared to handle records corresponding to heterogeneous data elements, as if they were held in a single record data structure. For example, the record identifier I may be used by the content management engine 3 to allow an application to read / write nonstandard data items, regardless of the type of data. In a simplified example, Extended Travel Record 9 may for example comprise a plurality of records to which a common record identifier H is assigned, which record ID1 is associated in common with the following data items: - Standard Data Item D1 Type 1 - Standard Data Element D2 Type 2 2 5 - Standard Data Element D3 Type 3 Non-Standard Data Element D4 Type 4 Labeled Non-Standard Data Element D5 Type 5 Non-Standard Data Element D6 type 2 labeled. The records of the data items D1, D2, D3 are recorded in the standard record data structure 90 in association with the record identifier ID1.

The records for the data elements D4, D5, D6 are recorded in the standard record data structure 90 in association with the record identifier ID1 (in non-standard data containers). The standard data container used to contain standard data elements is specifically adapted to contain data items having a predefined type and to set attributes according to the IATA standard. The standard data container is therefore only suitable for standardized data formats and data types. The non-standard data container can be created regardless of the type, attributes, and format of non-standard data elements. Each attribute itself may include a number of sub-attributes. The content management engine 3 therefore uses the non-standard data container to dynamically create a new content type in the Extended Travel Record (9), regardless of the content type. The non-standard data container may be a polymorphic data container which, unlike a standard container, is not hardware encoded into the code for a given element. On the other hand, the form it takes can be defined dynamically. The non-standard data container may also have self-serialization / deserialization properties.

In some embodiments, the non-standard data container may be a technical object represented by a Business Object Model 21 of the internal application that manipulates it, which facilitates the integration of new content into 9. The Figure 6 schematically illustrates the structure of an internal application of the content management engine 3 according to some embodiments of the invention, in which the non-standard data container is a Business Object Model 21. The internal application can be a stand-alone application or an application in a chain of applications (forming related applications). The internal application comprises: - structured interfaces 2, 3021787 24 - a Business Object Model 21, - a Business Layer 22. The structured interfaces 2 represent the way the applications communicate with each other. Structured interfaces can carry the functional data that applications can process. They can be mapped to the business object model 21 that is used by the business layer 22 to perform validation actions and operate. A validation action corresponds to functional checks performed by the business layer 22 on the data in addition to the grammar checks. The data elements may be inserted into the extended registration data structure 9 in a structured manner after validation. Therefore, a modification of the data structures of the extended PNR 9 may involve a modification of the Business Object Model 21 of the application and a modification of its structured interfaces. In addition, to take advantage of the data structure changes, other related applications may also need to adapt their Business Object Model 21, their structured interfaces 2 and to integrate the new version of the data model into the other module interfaces. The various embodiments of the invention make it possible to limit the costs associated with such a modification by using the non-standard data container model.

Travel services applications operating in the content management engine 3 may operate according to the scheme of Figure 7. The BOM 21 represents the Business Object Model 21 used to represent the internal data model used by the client. application. The service 210 represents any structured message received by the travel management system 100 (such as an XML or Edifact message) from a client device 7, a non-standard travel provider 5, or a communication device. traveler 6 that can be triggered by the application. The context server 211 represents the Contextual Storage of the data (also called "context") used by the application between asynchronous interactions with other applications. The context data may be stored in the database 8 in response to a request, periodically or under certain conditions. Figure 8 illustrates the interactions between chained applications A1 to AN in the content management engine 3, according to some embodiments. When the travel management system 100 is implemented according to a distributed architecture, the internal chained applications A1 to AN in charge of the processes can then call each other, which can lead to several duplications of the architecture 7 in several servers. application (30) (also called "main servers"), each application server 30 being associated with a respective chained application Ai. At each stage of the process chain, in conventional approaches, the data that is transported from the first main server 30 for the application A1 to the last server 30 for the application An is transformed, encoded and decoded in different ways before move from one server 30 to another in the middle of the process. Each primary server 30 then decodes the incoming data items and validates the data for its dedicated process before accessing the data items. Then, the data is encoded to be transmitted to the next application Ai ÷ i of the chain. In addition, the Business Object Model 21 may be involved in the process of filling and retrieving information in or from the structured interfaces 2 and may be used to write / read data. In conventional approaches, manually encoded components are required to write / read data to / from the structured interfaces 2 and the central registration repository. Therefore, a single change in the data model can be expensive. In addition, the data elements that applications manipulate usually have many functional constraints, so that each application may need to ensure that the manipulated data is in an appropriate format, compatible with industry constraints (validation ).

Accordingly, in conventional approaches, whenever a data element is to be modified in these chained applications, all process steps can be impacted because each process must transmit the new data to the next process and will therefore have to decode, validate and code them. In addition, when new content is to be added to an existing application, each process must further transmit the new content to the next process and each process in the chain must decode, validate and encode the new element. The invention according to some embodiments improves the situation by using the auto-serialization property of the BOM non-standard data container. In particular, a non-standard data container may be created by a first application Al of the chain, in response to the receipt of data elements D1, D2 and D3 from non-standard content providers 5. This content non-standard can not be stored as such in the standard PNR 90 because it does not include data types and attributes compatible with the standard structure of the PNR 90. The non-standard content can take different forms and be associated with different types and attributes. The first application A1 can for example create the non-standard container for each non-standard data element Dk in the format F1 of the first internal application Al (for example, protocol buffers). The first application Al then passes the non-standard container to the next application of the chain using an M1 message using the auto-serialization / deserialization properties of the non-standard container. The MI message may be a large binary object carrying self-serialization / deserialization information. The second application A2 can then extract the non-standard format data container F2 from the internal application A2. Similarly, the second application can transmit the non-standard container to other applications in the chain using messages M2, M3, etc. carrying the self-serialization / deserialization information until an An application triggers the creation of a record in the ETR 9.

As a result, through the use of a non-standard data container, no data changes are required for the addition of new data structures to the ETR 9, updating the structure of data or the transmission of a data element in a chain of internal applications. In addition, there is no need to modify existing data structures. The data held by the non-standard data container can be made available without the need to extract and convert from one format to another. Intermediate / manually coded layers can therefore be reduced. As described in the example of Figure 9, a non-standard data container 50 may be defined by a set of key values that describe a Business Object Model that can be manipulated by applications. Each key 51 defines an attribute of the BOM and includes an associated value 52 (also referred to as "data" in Figure 9). For example, the non-standard data container defined by the key "city" is associated with the value "Paris". The data container can comprise complex structures and be associated with any kind of data. For example, one or more keys of the data container may further be associated with a reference 53 (referred to as "REF" in Figure 9), for associating a given data container with a set of related data containers. For example, the data container designated by the key / value pair "phone / + 335551213" includes a reference ("REF") to the following data containers: "mobile / + 336123456" and "home / +335551213". The non-standard data container 50 provides access to the content management engine 3 in write mode for any of the data elements contained in the non-standard data container, without the need to develop an access module to allow this access. This guarantees flexibility and scalability. In addition, access to the data item contained in the non-standard data container can be performed by the content management engine 3 at any time from an application processing using language requests. appropriate interrogation such as Xpath. The non-standard data container may have backward and upward compatibility with respect to programming. From the programming point of view, no code change is required to use a new version of the data element structures associated with the non-standard data container.

The non-standard data container is configured to support serialization / deserialization. In particular, serialization may be performed at the time of creation and modification of one or more non-standard content attributes to encode the data container in an extensible format and deserialization may be performed whenever a application needs to read at least one attribute of non-standard content. In particular, the keys and values of the non-standard data container can be serialized at any time by translating the state of the technical object (eg, BOM) representing the non-standard data container into a format (for example for example, a binary representation) that can be stored and reconstructed by a deserialization mechanism to restore the data container to its original state. The non-standard data container can therefore be transformed into any target format, regardless of the data contained in the data container. Serialization and deserialization mechanisms do not require hardware coding. Serialization information can be integrated into a library associated with the Data Container. The use of this BOM therefore natively provides a serialization mechanism that can be supported by any kind of structure defined by the non-standard data container keys, without requiring specific coding. In some representative embodiments, the representation format of the non-standard data container used to translate its state according to the serialization / deserialization mechanisms can be based, for example, on the XML, ASCII, JSON, Binary formats, as illustrated. in Figure 10.

Validation of non-standard data container values may only be necessary when creating and modifying the data element represented by the non-standard data container object. Therefore, no read process is required to re-validate the data items associated with the keys. Using the non-standard data container, the type of content information (for example, air transport, taxi, sporting event, parking, urban transport, etc.) can be transported in the non-standard data container. standard itself. The non-standard data container type can be stored as a key directly into the non-standard data container. In some embodiments, the validation mechanism upon creation or modification of a given non-standard data container may be based on the functional type stored in the non-stored data item in the form of a key. instead of a C ++ type in the form of classical approaches. In some embodiments, each type of non-standard data container may be associated with a structure description file (e.g., XSD) describing an attribute structure of the data item (attribute topology, attribute dependency, and attribute format, etc.). The structure description file (for example, XSD) further represents the interrelation between attributes and elements of a non-standard data container represented as a technical object (for example, an XML object) . In an XSD scheme associated with a non-standard data container, the different keys / values of the non-standard data container and the ancillary constraints applied thereto may be described using a set of non-standard data containers. XML tags. Structure description files can be used when creating and modifying non-standard data containers. In addition, auxiliary constraints may be applied to the non-standard data container using the structure description file (for example, XSD).

The structure description file associated with each non-standard data container may be used to validate the attributes of the non-standard data container upon creation or modification of the non-standard data container. The validation mechanism may include verifying that the non-standard data item represented by the non-standard data container adheres to the description of the data item in which the content is to be placed. In some embodiments, the validation mechanism may be implemented to validate whether the data stored in the non-standard data container corresponds to a target format using the structure description file associated with the non-standard data container. . The travel management system 100 may contain a table for storing the data type of the non-standard data container in correspondence with the structure description file associated with the non-standard data container. The table can be updated when running processes. The content management engine 3 may be configured to add new data to a non-standard data container, by updating the structure description files (e.g. XSD) describing the structure of the non-standard data container. -standard, such as new attributes. The structure description file (for example, XSD) defining a non-standard data container can be modified without having to physically code the changes and recompile the code. The modification of a non-standard data container is therefore dynamic and updateable at runtime. Figure 11 is a schematic view of the representative non-standard data containers of Figure 9, showing their respective types: Telephone type, Address type, GPS type. The type of information can be stored as an attribute in the non-standard data container. This information can be used to retrieve the structure description file associated with a non-standard data container. Figure 12 illustrates XSD description files for the examples of non-standard data containers of Figure 11 which have different types ("Telephone Type", "Address Type", "GPS Type"). According to some embodiments, the content management engine 3 may further generate a set of internal service interfaces 2 in the single platform 5 exposed by the Travel Management System 100 on the client devices 7, regardless of the type of content returned to a client device 7 and the applications maintained by the content management engine 3. The Extended Travel Record 9 can be used by a considerable number of applications. For example, the content management engine 3 may include a set of applications (e.g., travel applications) for delivering different types of travel services to the client devices 7 based on external content received from travel provider systems. standard 4 (eg, airline products) and any other travel provider system 5 (eg, off-line products), regardless of the type of content. Such services may include, for example, the Stores, Reservations, Pricing, Insurance, Refund services. These service applications may be executed in response to service requests from systems (e.g., travel agency systems 70) connected to the travel management system 100 via a client device 7, without it being 20 necessary to adapt each application to the N types of data added to the ETR 9 by hardware coding. The results can be returned via the data exchange unit 11 using response messages in a given format such as XML messages. The internal service interfaces 2 generated by the travel management system (100) can therefore be of the XML type. To make it unnecessary to recode and recompile each application to support any number of new types of non-standard data containers, a generic element with a unique type (Generic Element type) can be used. The generic element is a mega-data container configured to hold a non-standard data container of any type. The generic element can be seen by all service applications as a container of a single type (hereinafter referred to as "generic element type") while the generic element can contain an unlimited number N of data types. not standard. Each application can therefore instantiate the generic element in order to be able to handle non-standard containers in a fluid manner, regardless of the type of data element contained in the data container. As a result, each application does not need to instantiate as many non-standard data containers as new data types. Accordingly, adding a new type of content in the non-standard PNR 91 does not impact and does not require adaptation to the applications handled by the content management engine 3 to ensure backward compatibility (for example, a hardware coding). Fig. 13 is a flowchart describing access to the records of the ETR 9 having a given registration identifier I by an application. For example, the record identifier I may comprise: a standard data element SD1 of type T1; a standard data element SD2 of type T2; a non-standard data element NSD3 contained in a data container non-standard, type T3 - a non-standard NSD4 data element contained in a non-standard T4 type data container. In block 600, the records associated with the record identifier I are retrieved from the ETR 9. The records may be associated with standard data items (SD1, SD2) and non-standard data items NSD3, NSD4 (non-standard data containers) having respective types T1, T2, T3, T4.

Each data element SD1, SD2, NSD3 and NSD4 is then processed separately. In particular, for each data item such as for example NSD3, if the data item is a non-standard data item (block 601), the non-standard data item of type T3 is transformed into an item. Generic Generic Element Type containing the T3 non-standard data element at block 602. The generic element such as a mega-data container may itself contain a non-data container 3021787. -standard having a specific type. The generic element can be implemented as a technical object such as a BOM, and can be based on the same technology as the non-standard data container. If the data item is a standard data item (block 603) such as, for example, SD1, the standard T1 data item can be converted to a non-standard data container of the same type T1 at block 604. At block 602, the non-standard data item thus obtained is then transformed into a generic element of a single Generic Element type containing the non-standard T1 data element corresponding to the NSD1 standard data element. .

The generic element forms a transient state of the non-standard data element, which allows the application to manipulate the standard data elements and non-standard data elements in a fluid manner, regardless of their type. The application can therefore manipulate the data elements of the ETR 9 without knowing explicitly the type of non-standard content as if they had a unique type.

In block 605, if the execution of the application requires that one or more pieces of data can be sent to the interface of the client device 7 sending the service request, the application can inspect the generic element to access the type of the data element. In some embodiments of the invention, non-standard data items may be associated with respective tags. In these embodiments, at block 601, only the non-standard data items associated with respective tags can be selected by the application and transformed into a generic element. Therefore, the generic element abstract the type of the non-standard data elements: instead of defining a new type of element each time a new type of content has to be manipulated by the applications (new content added in ETR 9), each application can thus instantiate a single generic element capable of handling any new type and attribute. Referring again to FIG. 3, the travel management system 100 may be adapted to exchange any type of data (standard and non-standard content) with any type of external client device such as a branch office system. 70 travel, a non-standard 5 travel provider system, and any other main server within the same 3021787 33 GDS via internal interfaces 2. In conventional approaches, the travel management system 100 can exchange data a standard PNR with other target customer devices (eg, travel provider systems, travel agency systems) having their own standard for PNR content format (target PNR content format) by implementing a hardware-encoded conversion to the standard format supported by the interface of the target client device. This requires a coding mechanism at the level of the travel management system 100 and decoding / validation mechanisms at the target device. Instead, each travel management system may have its own standard for PNR content format (source PNR content format) and therefore target device interfaces only support this format. This conversion (coding / decoding / validation) currently involves hardware coding and recompilation, in a costly and static approach. The data exchange unit 11 allows the reception or transmission of a data exchange message from an external client device according to the second data exchange format to exchange any type of content. In a preferred embodiment, the second data exchange format 15 is a tag description language such as XML. Each data exchange message corresponding to a non-standard data item includes a structure description file defining attributes of the data item (topology and attribute format), such as an XSD for messages. XML, and a set of values corresponding to the values of the attributes. Figure 14 shows in more detail the structure of the data exchange unit 11 according to some embodiments. The data exchange unit 11 can be used to exchange data items with an external client device, such as a non-standard travel provider 5, a travel agency system or other non-standard system. GDS. In particular, the data exchange unit 11 can be used to: - receive non-standard data elements from a client device; or transmitting data items from the ETR 9 to a client device. The data exchange unit 11 can comprise a structure transformation engine 111 such as an XSLT engine for the transformation of a structure description file such as an XSD of a structure description file. XSD1 source to an XSD2 target structure description file and a data exchange message generator 112 for the transmission of data in the form of a message defined according to a description language such as XML. The XSLT engine can use predefined local mapping rules 113 (for example, XSLT stylesheets) that define transformation rules for forwarding an XSD1 source structure description file in receive mode or predefined client mapping rules. (eg, XSLT style sheets) defining transformation rules for transforming an XSD1 source structure description file into transmission mode. The travel management system 100 can dynamically record or dynamically load at run time one or more predefined local structure description files 115 associated with different content types and corresponding to structure description files to be applied locally. by the travel management system 100. In the receive mode, the data exchange unit 11 can receive an incoming XML1 data exchange message from an external client device 7 compatible with a source structure description file. XSD1 defined by the external client device 7. The incoming XML1 message contains a non-standard data item of a given type Ti.

Whenever such an incoming XML1 data exchange message is received by the travel management system 100 comprising a non-standard data element, the transformation engine 111 may transform the XSD1 structure description file. of the incoming message into an XSD2 target structure description file using the local mapping rules 113 associated with the type of the data item contained in the XML1 data exchange message. The XSD2 target structure description file is then added to the set of local structure description files 115. The data exchange unit 11 may further apply a validation mechanism to the XML1 incoming message before the file transformation. XSD1 source structure description scheme into the target structure description file XSD2 to validate a number of conditions relating to the attributes of the XSD1 structure description file (e.g. presence of mandatory attributes).

3021787 The non-standard type Ti data container can then be generated by mapping the fields of the XML1 data exchange message to the non-standard data container primitives. The non-standard data storyteller is then added to the ETR 9 in association with the target structure description file (XSD2) stored at 115 for the type Ti as described in connection with FIG. 5. Any update or any addition of new content in the ETR 9 can be done at runtime. The use of the data exchange unit 11 thus makes it possible to dynamically convert any incoming data exchange message received from the content provider systems 4, 5 into several non-standard data content objects representing the data exchange units. 10 items to add / edit without requiring code changes. In transmission mode (dotted line), the travel management system 100 can transmit any data element of the ETR into the target interface of an external client device 7 via the data exchange unit. In transmission mode, the data exchange unit 11 receives as input a non-standard data container 15 (containing a non-standard data element or a standard data element of the Ti type previously converted to a non-standard data container). -standard). The non-standard type Ti data container is associated with a structure description file (referred to as the source structure description file) including a description of the attributes (key) of the non-standard data container, the attribute topology and the attribute format, such as an XSD file (115). A non-standard data container is also associated with key values that match the attribute values. If the data item to be transmitted by the travel management system 100 comprises a non-standard data container of a given type Ti from the ETR 25 9, the transformation engine 111 can transform the description file. of structure XSD3 associated with the non-standard data container in local structure description files 115 into an XSD4 target structure description file using client mapping rules 117 associated with the type of the non-standard data element standard. The client mapping rules 117 define the rules for transforming to the interface format of the target client device 7, for example to display the user graphical user interfaces (GUIs) of the target client device 7.

If the data element to be transmitted to the client device 7 is a standard data element (for example, GDS elements) of the type Ti, the standard data element may be previously converted to a non-standard data container of the data type. same type using the data container converter 12. The standard data element can then be sent to the data exchange unit 11 as a non-standard data container for transmission. of the target client device 7. Figure 15 depicts a flowchart for transmitting a data element of type Ti to the target interface of a client device 7 (User Graphic Interface, GUI), according to some embodiments.

If the data item is a standard data item (block 700), the standard data item of type Ti may be converted to a non-standard data container of the same type Ti at block 701 (similar to block 604). of Figure 12). The standard data item is then processed in block 703 as a non-standard type Ti data container, associated with an XSD1 structure description file and Vi key values.

If the data item is a non-standard data item in the form of a non-standard type Ti data container (block 700) associated with an XSD1 structure description file and Vi keys, the non-standard data element of type Ti is processed directly at block 703. At block 703, the source structure description file XSD1 associated with the non-standard data container is retrieved. At block 704, the source structure description file XSD1 is converted to an XSD2 target structure description file using the mapping engine 110 (e.g., XSLT engine) to parse the source structure description file XSD1 and convert the scanned fields to an XSD2 target structure description file using mapping rules 113 (e.g., XSLT stylesheets). The mapping rules 113 are defined according to the format of the target interface of the client device 7. At block 705, the XML message containing the data item to be transmitted to the client device is generated by adding the values Vi associated with the data container. not standard.

In block 706, the XML message is sent to the target interface of the client device 7 via the network 13. The target interface may be dynamically and transparently adapted in response to the response of the XML message. External client devices 7 can further extract the data element contained in the XML message and store it according to its own standard without the need to apply a complex decoding and validation mechanism to the data, regardless of the type of data. data and format of the target interface. Through the use of non-standard data container associated with structure description (XSD) files and having the ability to serialize as a data exchange message in any format (e.g. , XML), a new type of interfaces 2 can be built.

In one embodiment, the data exchange unit 11 may be used by the content management engine 3 to dynamically generate a coherent representation of request results on the interface of a client device 7 ( for example, travel agency system) regardless of the type of content (standard, non-standard, mixed content), with as little manual coding software as possible.

The service applications can directly use a homogeneous data structure to store the data in the interfaces 2. This renders unnecessary the exchange between the interface layers and the BOM layers of yet another format of the data structure. It further reduces the overhead between the data stored in the extended trip record and the representation of the data in the service interfaces exposed to the client devices 7 (eg, travel agency systems) via a platform. unique. Specifically, the method of Figure 13 may be applied to generate a representation of results in response to a service request from a client device 7 (eg, travel agency system 70) and display this representation on 2 5 the graphical user interface associated with the service on the client device interface, while ensuring that the representation is homogeneous regardless of the type of content (standard content or non-standard content). When a registration identifier associated with non-standard content and / or standard content is added in the Extended Registration Data Structure 9, the service applications are adapted to generate a registration representation of dynamic and homogeneous, whatever the new type.

The application of the content management engine 3 corresponding to the service request can access the records corresponding to the result obtained from the ETR according to the access method of FIG. 12 using the generic element. . Implementing access to non-standard data containers (50) based on the single wildcard regardless of the type of content to be returned to the client device 7 allows each application to support any type of content. content from non-standard content provider systems 5. The applications in the content management engine 3 are therefore independent of the content type. To return the results to the interface of the travel agency system 70, the application may inspect the generic element to access the non-standard data container (block 605 of Figure 6). The non-standard data container thus accessed can therefore be returned according to the method of FIG. 14. The content management engine 3 is therefore adapted to provide a single platform for all the client devices 7 comprising a set of interfaces per service. (eg, travel service) representing a single response regardless of the type of products to be handled (eg: conventional GDS airlift (flight) / GDS vehicle hire / non-GDS / non-GDS. .). To facilitate the integration of new content into an application, the internal service interface 2 associated with the application may have a set of common attributes for each content family. This allows new elements of an existing content family to take advantage of all the display features available to the family. Specifically, the underlying data structure of the non-standard Data Container (50) can share a common format in a specific item category. For example, the XSDi format description file used to represent a data element of the airline line segment type may be the same regardless of whether it has been reserved via the travel management system (100) or via another external booking system. It can therefore also share a set of common data with elements of another category (for example, transport category). In particular, the transformation engine 111 may be defined such that for a given record identifier H in the ETR 9 associated with a non-standard data item and a standard data item, if the non-standard data element and the standard data element are of the same general type (e.g., "hotel"), the same representation can be generated for both data elements at the target interface of the external client device 7 (eg, travel agency system) by mapping the XSD1 structure description file associated with the non-standard data element and the XSD2 structure description file associated with the standard data on the same common type structure description file compatible with the target interface. For example, as depicted in Figure 16, a TYPE C standard data item is first converted to a non-standard container associated with the same TYPE C type (block 701 of Figure 7), and then a representation (XSD2) is generated on the client device for TYPE C using the transformation engine 111 and mapping rules 117 defined for TYPE C at the client device (style sheets). As shown in the example of Figure 17, the same representation (XSD2) will be used for a non-standard TYPE C container. In addition, transformation rules 117 may be defined such that attributes of the same type of any data item is mapped to the same under-representation, regardless of the content type (non-standard or standard), which includes the attributes (in the target description file). In the example depicted in FIG. 18, a typical TYPE D container comprising a set of attributes A1, A2, A3, A4 (as defined in the source structure description file XSD1) is all first converted to a non-standard container associated with the same type TYPE D (block 701 of Figure 1), then an XSD2 representation (target structure description file) is generated on the client device for the TYPE D using the transformation engine 111, the XSD2 representation comprising representation attributes {E1, E2, E3, E4} corresponding to the source attributes {A1, A2, A3, A4}. As shown in the example of FIG. 19, a same representation {E2, E3} can be generated for the attributes A2, A3 of a non-standard container of another type TYPE C comprising the set of attributes {C1, A2, A3, C4} by applying the same mapping rules 117 for similar attributes of an XSD source structure description file. The mapping engine 11 will generate a representation XSD3 = {F1, E2, E3, F4, F5} with the same representation E2 and E3 for the respective attributes A2 and A3. The content management engine 3 thus provides a single platform for all client devices 7 (associated for example with travel agency systems) comprising a set of application interfaces, through which a single response can be provided. be generated regardless of the type of content that needs to be handled (for example, GDS flight product, GDS vehicle rental, non-GDS taxi, non-GDS restaurant, etc.).

Service applications can therefore directly use a homogeneous data structure to store the data in the interfaces. This makes the exchange between the interface layers and the BOM layers unnecessary for another format of the data structure. This further reduces the overhead between the data stored in the Extended Travel Record 9 and the data representation in the service 2 interfaces 2 exposed to the client devices 7 (eg, travel agency systems) via a single platform. Consequently, the data exchange unit 11 makes it possible to dynamically generate a coherent representation of the results regardless of the type of content (standard, non-standard, mixed content), with as little manual coding software as 15 possible. In particular, the data exchange message used to return the results to the client device 7 has a format close to the internal structures (for example, XML) and this format is inherited from the structure description files (for example, XSD) used. to define the elements themselves in the Generic Element.

The travel management system 100 thus provides a set of travel service interfaces representing a single response regardless of the type of products to be handled (eg conventional GDS airlift (flight) / vehicle rental product). GDS / non GDS taxi / non GDS restaurant ...). Figure 20 depicts a flowchart of a content management method according to some embodiments. Content associated with a common registration identifier in the ETR 9 includes a set of data items related to the same trip. Depending on the application requiring a particular registration identifier in the ETR 9, the application may require that the different data items associated with a given folder mark be arranged (eg, ordered) according to rearrangement criteria. predefined when accessed by the application. The content rearrangement method may be implemented to rearrange the data items according to predefined rearrangement criteria by the application, for example in chronological order, storage criteria, etc. The rearrangement process can merge the standard and non-standard data elements into an abstract-based abstract storage model. The abstract element can be used to sort the data elements according to the rearrangement criteria. The application can therefore return an ordered merged data item according to the target interface constraints. This can result, for example, from aggregated route documents where PNR segments and extended elements (non-standard content) can be merged into a single view. In particular, for each data element, if the data element is a non-standard data element (block 801), the non-standard data element of type Ti is transformed into an abstract element of a type. A single subset of the attributes of the non-standard data element of type Ti in block 802. The attributes of the non-standard data container are filtered according to filtering criteria generated according to the rearrangement criteria (eg for example, chronological order, the filtering criteria will select data attributes). The abstract element can be implemented as a technical object such as a BOM, and can be based on the same technology as the non-standard data container and / or the generic element. It should be noted that both the generic element and the abstract element allow abstraction of the type of a data element.

If the data item is a standard data element (block 803) of the type Ti, it can be converted to a non-standard data container of the same type Ti at block 804 (similarly to step 604). of Figure 6). In block 805, the attributes of the non-standard data item thus obtained are filtered according to filtering criteria.

In block 806, the non-standard data item obtained in step 804 is transformed into an abstract element containing the filtered set of attributes of the non-standard type Ti data item corresponding to the standard data element of type Ti. Similar to the generic element, the resulting abstract element forms a transient state of the nonstandard data element, which makes it possible to abstract the type of data container. This further allows global manipulation of the attributes of the application-filtered data items, regardless of their types, by inspection of the abstract model and in particular an arrangement thereof according to the rearrangement criteria. In the travel field, the standard PNR 90 may be stored in a storage area that is shared between a plurality of systems. The standard data elements recorded in the standard PNR 90 may be of different types and each element may have its own serialization format. Standard data items can share the same record identifier if the data items are linked (for example, common to the same pass or route). Similarly, a piece of data in the non-standard PNR 91 may share the same record identifier as another piece of data in the non-standard PNR 91 or the standard PNR if the data items are linked. The non-standard PNR 91 can be stored in the same storage area as the standard PNR. Alternatively, the standard PNR 90 and the non-standard PRN 91 may be stored in different storage areas. Both zones can be generated by a global management mechanism to allow synchronization of common data. The global management mechanism may be implemented to link the dedicated non-standard PNR storage area 91 to the other standard PNR storage area 90 with each request that requires handling the global extended travel record 9. While ETR 9 is divided into two record data structures 90 and 91, ETR 9 can be managed globally based on common record identifiers 20 identifying related data items, auxiliary container data, and / or recording data structure information. Auxiliary data container data may include control information about each data container (eg, creation date, last modified date, etc.). In conventional approaches, such information is stored directly in each standard data container in association with a registration identifier 0 and can be accessed to manage the standard PNR (e.g., to periodically purge the standard PNR). However, this approach does not allow optimized management of the two record data structures 90 and 91.

Figure 21 shows the structure of the ETR 9 according to some embodiments. As shown, to optimize the overall management of the two record data structures 90 and 91, in one embodiment, the extended travel record 9 may further include an auxiliary data structure 92 (also called "central management data structure" or "central management area") for recording auxiliary container data related to each data container created in the ETR 9, such as the date of creation of a container of data, the date of last modification of a data container, etc. The information stored in the auxiliary data structure 92 can be used to manage the two areas in a synchronous manner. Each input of the auxiliary data structure 92 may share the same record identifiers as data containers created in the ETR 9. In addition, each record of the auxiliary data structure 92 may be associated with a set of data records. auxiliary container data related to the data containers registered in the ETR 9 (having the same registration identifier). The auxiliary data structure 92 may be filled with data container information contained in the standard record data structure 90 and the non-standard record data structure 91. In some embodiments, each entry of the auxiliary data structure 92 may comprise the set of auxiliary attributes related to the data containers sharing the same record identifier in the extended record data structure (9). Each entry may include an auxiliary data container for storing the ancillary container data set related to the records of the ETR 9 sharing the same registration identifier. The auxiliary container data set may include control attributes representing control information relating to the ETR 9 records sharing the same record identifier, such as the previous purge date of the record.

In some embodiments, the data container information relating to all records of a given record data structure 90 or 91 may be recorded in a dedicated record (also called "container information record"). ) in this recording data structure (90 or 91) and being assigned a particular record identifier (eg, record identifier 0). The container information record of the standard record data structure 90 and / or the container information record of the non-standard record data structure 91 can be copied into the structure 3021787 44 of non-auxiliary data 92 at different time intervals, for example periodically or in response to a request or, alternatively, whenever the ETR 9 is stored in the database (s). Auxiliary data 92 may further record registration data structure information relating to the standard registration data structure and / or the non-standard registration data structure, such as version information identifying the latest version of the standard registration data structure 90 and the non-standard registration data structure 91 in the databases.

The travel management system 100 may include an ETR controller 18 for managing the ETR 9 based on the data included in the auxiliary data structure 92 (auxiliary container data information and / or the structure information). standard recording data 90 and / or the non-standard recording data structure information 91).

In one embodiment, the ETR control unit 18 may include a purge module 180 configured to periodically purge records of the standard PNR 90 and the non-standard PNR 91 synchronously for common data at the same time. using common registration identifiers, the auxiliary container data being stored in the auxiliary data structure 92 and / or the recording data structure information. In some embodiments, the ETR control unit 18 may include an access manager 181 for simultaneously processing access to the same registration identifier in the standard PNR 90 and in the non-standard PNR 91 based on stored in the auxiliary data structure 92. In this embodiment, the auxiliary data structure may further record version information identifying the latest version of the standard record data structure 90 and the structure. For example, each time the ETR 9 is saved in the database from the context, the version information is updated in the database. Auxiliary Data Structure 92. The access manager 18 may be configured to manage access to the ETR 9 based on the version information stored in the structure. auxiliary data 92.

The program code according to any of the embodiments of the invention described herein may be distributed on an individual or collective basis in the form of a program product in a variety of different forms. In particular, the program code may be distributed using computer readable media, which may include computer readable storage media and communication media. Computer readable storage media, which are inherently non-transient, may include volatile and nonvolatile tangible media, and removable and non-removable, implemented by any method or technology for storing information, such as readable instructions computer, data structures, program modules, or other data. Computer readable storage media may include RAM, ROM, EPROM, EPROM, flash memory, or other solid state memory technology, a portable compact disc (CD-ROM), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that can be read by a computer. The communication media may implement computer readable instructions, data structures, or other program modules. By way of example, and without limitation, communication media may include wired media such as a wired network or direct wired connection, and wireless media such as wireless, RF, infrared, and wireless media. other. Any combinations of the above are also included in the context of computer readable media. The methods described herein may be implemented by computer program instructions provided to the processor of any type of computer to produce a machine having a processor that executes the instructions for implementing the functions / acts specified herein. document. These computer program instructions may also be stored in a computer readable medium that can direct a computer to operate in a particular manner. For this purpose, the computer program instructions may be loaded onto a computer to cause a series of functional steps to be performed and thereby produce a computer implemented method so that the executed instructions provide methods for the execution of a computer program. implementation of the functions / actions specified in this document.

Although embodiments of the invention have been illustrated by a description of various examples, and although these embodiments have been described in great detail, it is not intended to Applicant to restrict or in any way limit these details to the scope of the attached claims. Additional advantages and modifications will be apparent to those skilled in the art. The invention, taken in its broadest aspects, is thus not limited to the specific details, representative processes, and illustrative examples presented and described. In particular, although the abstract element has been described for content rearrangement, it can be used in general by internal applications for accessing content for different kinds of operations. The filtering rules applied to filter the attributes of a data container may vary depending on the intended operations.

Claims (12)

REVENDICATIONS1. A content management method provided by one or more content providers (4, 5) in a content management system comprising an application aggregator (3) comprising a set of applications and an extended registration data structure ( 9), said extended record data structure including a standard record data structure (90) for storing a record associated with standard standard type predefined data items and a non-standard record data structure ( 91) for storing records associated with non-standard data items having a non-standard type different from said predefined standard types, said method comprising receiving (102) content from one or more content providers (4, 5). ), said content comprising a set of associated data elements of respective types, and, for each data element: n recording for the data item in the standard record data structure (90) if the data item has a standard type, said record including a common record identifier and data values corresponding to the item of data ; generating a non-standard data container for said data element if the data element has a non-standard type and creating a record for the data element in the data structure of the data element. non-standard record (91), said record including said common record identifier and data values corresponding to the data item; Said content management method further comprising managing access to the records maintained in the extended record data structure (9) based on the common registration identifier. The method of claim 1, wherein the non-standard data container 30 is a technical object comprising a set of keys and values, each key corresponding to an attribute of the data element. 3021787 48 The method of claim 2, wherein the non-standard data container comprises a key defining the type of the non-standard data container. The method of claim 2, wherein the non-standard data container is a business object model, said business model being auto-implemented. The method of claim 4, wherein the non-standard data container includes a self-serialization mechanism for serializing into an application target format, the non-standard data container comprising a library incorporating information serialization to serialize or deserialize the non-standard data container. The method of claim 1, wherein it comprises providing an access of an application to a record in the extended record data structure associated with a non-standard data item of a given type in accordance with the present invention. generating a generic container assigned a unique generic type, said generic container containing the non-standard data container of said given type. The method of claim 6, including providing an access of an application to a record in the extended record data structure associated with a standard data item of a given type by converting the item of standard data into a non-standard data element and generating a generic container to which said single generic type containing the non-standard data container resulting from said conversion is assigned. 25 The method of any of the preceding claims 5 and 6, wherein each application can access the type of a non-standard data container contained in the generic element by inspecting the non-standard data item. 30 The method of any of the preceding claims, wherein said standard registration data structure and said non-standard registration data structure are stored in a same storage area within the management system. content. 3021787 49 The method of any of the preceding claims, wherein said standard registration data structure and said non-standard registration data structure are stored in different storage areas within the management system. content. The method of any of the preceding claims, wherein said received content can be received by an application of a set of chained applications of the application aggregator (3), each non-standard data element of the application aggregator. Received content being transmitted between the applications of said set of chained applications by messages carrying auto-serialization information, storing the non-standard data container in the extended travel record (9) being triggered by the one of the applications of the set of chained applications. 15 12. Content management system for managing content provided by one or more content providers (4, 5), the content management system comprising an application aggregator (3) comprising a set of applications and a structure extended registration data structure (9), said extended registration data structure comprising a standard registration data structure (90) for storing a record associated with standard data elements of predefined standard types and a structure non-standard record data (91) for storing records associated with non-standard data items having a non-standard type different from said predefined standard types, said content management system (100) being configured to: 2 Receiving (102) content from one or more content providers (4, 5), said content comprising a set of associated data items of the type s, and, for each data item: create a record for the data item in the standard record data structure (90) if the data item has a standard type, said record including an identifier common record and data values corresponding to the data item; generating a non-standard data container for said data item if the data item has a non-standard type and creating a record for the data item in the non-standard record data structure (91). ), said record including said common record identifier and data values corresponding to the data item; said content management system being further configured to manage access to the records maintained in the extended registration data structure (9) based on the common registration identifier.