FR3021788A1 - - Google Patents

Abstract

A method of accessing content in a content management system includes a set of applications and an extended registration data structure. The extended data structure includes a standard record data structure for storing records, the records having standard data elements of standard types predefined as standard data containers and a non-registration data structure. standard for storing records comprising non-standard data elements of different types from the predefined standard types, in the form of non-standard data containers. The method includes, in response to an application access request to a set of associated data elements of the extended registration data structure, based on access criteria: a. for each data item in the set of associated data items, filtering attributes of the data container associated with said data item in the extended record data structure according to the filter rules (805), and b . generating (806) an abstract container to which a unique abstract type is assigned and including said set of attributes of the data container.

Description

BACKGROUND

Content Access Method and System

BACKGROUND

The present invention generally relates to data management, and in particular methods, systems and computer program products for accessing content in a content management system.

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 large 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 can be used to distribute content obtained from a set of travel provider systems (content providers) to a plurality of travel agency systems. (content consumers). 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 are 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, tour operator intermediaries such as Global Distribution Systems (GDS) provide Travel Management Systems to enable tour operators to retrieve information from service providers. 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 is thus offered at destination.

The present invention generally relates to data management, and in particular methods, systems and computer program products for accessing content in a content management system.

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 large 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 can be used to distribute content obtained from a set of travel provider systems (content providers) to a plurality of travel agency systems. (content consumers). 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 are 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, tour operator intermediaries such as Global Distribution Systems (GDS) provide Travel Management Systems to enable tour operators to retrieve information from service providers. 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 is 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 plane or 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 Registration" data structure 900 for storing records associated with GDS content received directly. of 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 reference is also known as a confirmation number, a reservation number, a confirmation code, 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 way 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 Interline Reservation Messages - Passengers (AIRIMP, "ATA / IATA Interline Message Procedures - Passenger Reservations"). 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 PNR 900 are 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 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, so there are many similarities relates to the contents and data formats of PNR 900 held by different travel management systems In particular, each PNR 900 data structure is such that the travel data associated with a folder reference must satisfy a number of predefined types which correspond to the GDS content standardized by IATA (aerial data, rail data, etc.).

Therefore, only GDS content (eg, overhead, 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 future. PNR 900 among other non-GDS items.

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 30 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 return a representation. of the PNR registration 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 to access non-GDS content, while the travel management system 1 is connected directly to On the other hand, 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 specific content from a non-standard travel provider 50 (for example, a museum ticket), this content must be personally implemented by the travel agent Ai. This personal implementation is particularly expensive and complex for tour operators.

In addition, in conventional approaches, the travel management system 100 stores the PNR content in a local format (source PNR content format). However, the travel management system may need to exchange data between the PNR and other external systems (travel suppliers, travel agencies) with their own PNR data format (target PNR content format). Therefore, according to the target system, a conversion of the PNR content associated with a PNR record of the travel management system can be performed to the target PNR content format. This conversion currently involves hardware coding and recompilation, in a costly and static approach. Similarly, in a stream of applications using PNR content within the travel management system 100, each internal application of the application flow (chained applications) that receives the PNR content must convert the PNR content to a new one. application format in order to manipulate it. Each application in the chain must therefore decode, validate and code the PNR content in order to write or read it, which requires manually coded components and is expensive.

In addition, in a conventional management system, the PNR can be used by a very large number of applications currently configured to handle only types of SUMMARY

In order to solve these and other problems, a content management method as defined in the independent claim 1 presented in the appendix is provided, and a content management system as defined in the independent claim 14 presented. in annex. Preferred embodiments are defined in the dependent claims.

The method and system according to the various embodiments of the invention therefore allow any application to dynamically access any type of content without the need to recode all internal applications each time. a new content type is added to the extended 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 standard contents. Therefore, in order to manipulate new types of content, it is currently necessary to recode all applications of the content management system, which is expensive.

There is therefore a need for improved computer program systems, methods and products for content management, enabling dynamic and fluid content exchange.

ABSTRACT

In order to solve these and other problems, a content management method as defined in the independent claim 1 presented in the appendix is provided, and a content management system as defined in the independent claim 14 presented. in annex. Preferred embodiments are defined in the dependent claims.

The method and system according to the various embodiments of the invention therefore allow any application to dynamically access any type of content without the need to recode all internal applications each time. a new content type is added to the extended 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 constitute a part of the present application, illustrate various embodiments of the invention and, in association with the general description of the invention given above and the detailed description of the forms of the invention. realization 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

The accompanying drawings, which are incorporated herein and constitute a part of the present application, illustrate various embodiments of the invention and, in association with the general description of the invention given above and the detailed description of the forms of the invention. realization 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;

Figure 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 flow chart 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 centralized storage. records associated with this content, regardless of the type of content. The content management system 100 may be based on a client / server architecture for receiving client 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 can be received from standard content provider systems 4 communicating with the content management system 100 based on a first type of content 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 15.

The content management system 100 can be connected to a communication network 13, which communication network 13 can include the Internet, a network

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 centralized storage. records associated with this content, regardless of the type of content. The content management system 100 may be based on a client / server architecture for receiving client 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 can be received from standard content provider systems 4 communicating with the content management system 100 based on a first type of content 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 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, or multiple high speed bus connections, and / or other such communication networks.

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 servers in a network. 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 other such 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 connecting 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 standardized TTY message exchange format according to the IATA standard (first message exchange format 14).

The content management engine 3 may furthermore exchange messages with the non-standard providers 5 via a data exchange unit 11 (also referred to as a "content access unit" in the present description). The data exchange unit 11 can use messages defined according to a data description language such as the extensible markup language (second message exchange format 15) for communicating with non-standard content providers, for example. example in response to a search, a reservation, a request for price, a delivery, a cancellation request from a user user 7 associated with a travel agent entity (for example, a travel agent operator or a travel agent system). travel agent).

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 content management system. 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 can request and obtain content from the content provider systems 4 and / or 5 according to the message exchange formats 14 and / or 15 and store a related record. 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 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 standard record data structure 90 for storing records in association with standard data and a non-standard record data structure 91 for storing records in association with data. not standard.

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 registration 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.

Further, a record may be added to the standard record data structure 90 and the non-standard record data structure 91 for a received content including related data items, if the received content includes elements of non-standard data 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 91 can be seen both assign 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 registration data structure 91.

By using the same registration identifier in both the registration data structures 90 and 91 to identify standard and nonstandard related data elements, the content management system 100 can handle the two registration data structures so that transparent 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 storage of related records. 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 the type of content, 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 can 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 en Thus, the content management engine 3 plays the role of an aggregator of applications for providing services to the client users 7.

In a preferred embodiment of the invention, the content management system 100 may be a Travel Management System. The travel management system 100 can be implemented by an intermediate operator (for example, a global distribution system (GDS) in the travel field) to enable 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 IAT constraints A (such as as aerial, rail 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, vehicle rental) provided by non-standard 5 travel provider systems or booked outside the GDS system. The standard record data structure 90 may be a standard PNR data structure (also referred to hereinafter 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 being 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 bookings of a hotel and a rental vehicle.

The extended registration data structure 9 forms a Extended Travel Record (hereinafter also referred to as "ETR" ("Extended Travel Record")), where each content record can be handled in a fluid manner by the search engine. content 3 regardless of the type of content associated with the record.

The client devices 7 can be associated with a plurality of travel agency systems 700 requesting services via respective client interfaces 2. More particularly, the travel management system 100 can also access different types of client devices submitting different types 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 exchanging content stored in the Travel Registration Extended 9).

Standard travel provider systems 4 may include a plurality of airline or traveler systems. Non-standard travel product provider systems may include vehicle rental systems, museum reservation systems, and the like. When implemented, company systems may include a Computer Reservation System (CRS) and / or a 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 offered by non-standard travel providers 5. Some standard travel provider systems 4 may also interact with each other, either directly or indirectly. via the GDS 1, to allow an issuing company to sell tickets for seats provided by an operating company. The operating company may then bill the issuing company 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 reservations on one or more company systems 4 and search for and book additional services (eg vehicle rental, museum tickets, etc.) via GDS 1.

Each travel agency system 70 may include a web server that provides a publicly accessible website. This website can be configured to provide access to travel planning features, such as the ability to search for travel products that match a trip 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 access may 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 ( for example, a travel planning application).

Traveler 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 web browser application. which communicates with a web services application hosted by the content management engine 3 of the travel management system 100 to submit 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 travel requests based on the travel service application.

Travel requests may 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, rental of vehicle, jet-ski booking, museum ticket reservation, etc.) corresponding to 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 devices or computer systems, collectively called computer, such as the computer 30. The computer 30 may include a processor 32, a memory 34, a mass storage memory device 36, input / output (I / O) interface 38 and a Human Machine Interface (HMI) 40. The computer 30 may also be operably coupled to one or more external resources 42 via the network 22 and / or an interface I / O 38. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or any other resource appropriate computer that can be used by the computer 30.

The processor 32 may include one or more selected devices among microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, user programmable gate arrays, programmable logic devices, state, logic circuits, analog circuits, digital circuits, or other devices that manipulate signals (analog or digital) according to operation instructions that are stored in memory 34. 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 volatile memory, a non-volatile memory, a static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any other device capable of storing cker information. The mass 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. information. 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 computing 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 system operation 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 in cooperation with the computer. 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 of the computer 30, distributed on multiple 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 operatively 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 interface 40 may also include input devices and commands such as an alphanumeric keyboard, pointing device, keypads, push buttons, control buttons, microphones, etc. capable of receiving 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 thus offers the possibility of storing not only standard content compatible with the standard PNR data structure 90, but also any new type of content (ie, taxi rides, theater tickets, concerts, gifts etc.) while making it unnecessary for travel agencies to book such non-standard content outside the GDS system over the phone, or via 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.

The Extended Two-Layer 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 the GDS), while the recorded recordings in the 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 element (for example, a product) in the standard PNR Table 1

Transportation Overnight Meals Activities Services

Air Hotel Restaurant Sports Activities Insurance

Ferry Apartment Bar & Club Shops Visa

Shows &

Cruise Camping Other Gifts Events

Rail B & B Excursions Documentation

Equipment of

Coach Other Visits hobbies

transport network

Other Urban Local Services

Transfer Meeting

Taxi Vaccine

Car Other

Bike

Car park

90 is associated with a set of attributes that can be qualified as optional or mandatory based on the topology and format implemented in 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 comprising 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

Transportation Overnight Meals Activities Services

Air Hotel Restaurant Sports Activities Insurance

Ferry Apartment Bar & Club Shops Visa

Shows &

Cruise Camping Other Gifts Events

Rail B & B Excursions Documentation

Equipment of

Coach Other Visits hobbies

transport network

Other Urban Local Services

Transfer Meeting

Taxi Vaccine

Car Other

Bike

Car park

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 to the extended trip record 9, regardless of the type of content,

The content management engine 3 is configured to handle heterogeneous content of the ETR 9 which may include:

adding new data elements from any travel provider system 4 or 5 to the extended trip record 9, regardless of the type of content, for example in response to requests from branch systems travel 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 York ).

- the retrieval of data items from the extended trip record 9 (for example by retrieving all the structured attributes of the "Museum" product in a specific trip 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 that is transparent to the client users. 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 a given service (for example, a reservation management flow), the following steps can be performed by the content management engine 3: i. the data can be extracted 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 send to a subsequent application in the application flow. 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 can have only a limited number of predefined attributes and must respect one or more predefined types and formats (standardized attributes).

The non-standard PNR 91 is not compatible with the standard rules and constraints of the standard (IATA content definition, TTY messages, IATA messages). However, the non-standard content can be part of the Extended Travel Record 9 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 way 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 travel management system 100 by non-standard content provider systems 5. The non-standard data container can dynamically adapt to the format of the internal content management system application that receives the data item because of the properties of the content management system. self-serialization 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 internal application to which it is passed 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 5 providing a non-standard content type, the non-standard data items received from the non-standard content provider system 5 can 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 include a list of attributes, each attribute being represented by a key and a value. Each attribute itself may include a list of subattributes, 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 one (s) the structure it represents or the data they contain: for read-only access or read access / 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 key or 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 record can be accessed transparently by the content management engine 3, for any type of content management actions, for example to run travel applications, generate a service request result display on the client devices. 7, or transmit content to external devices (for example, 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.

At 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 to a service request from a client device 7, such as a travel agency system.

The content may include a plurality of related data items, for example, data items relating to the same trip, such as a product of type Vol (standard data item) and a product of type Taxi (non-standard content ) 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 include standard data elements (e.g., a flight product) and / or non-standard data elements (e.g., 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 items may 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 according to the second message exchange format. The following description will be made with reference to the XML message (also called document or XML file) for a 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 (for example, product of type Vol) using a standard data container (hereinafter 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 product), the content management engine 3 creates an R record in the non-standard PNR (90) for the standard content (e.g. , product type Vol) using the non-standard data container (hereinafter also referred to as "standard container") in 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's Fl format, the non-standard data element can be transmitted to other internal applications in the chain until it arrives at an internal application An in the Fn format of the application An, and finally the application An triggers the creation of a record in the non-standard record 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 item (non-standard data item). The record R may be assigned the same record identifier I and may be associated with the nonstandard 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 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 standard PNR 90 and non-standard PNR 91 for all standard data elements and non-standard data elements corresponding to common content (related data elements ). This common registration identifier can therefore 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, the Extended Travel Record 9 may for example comprise a plurality of records assigned a common registration identifier II, this ID1 record being associated in common with the following data elements:

Standard Data Element DI Type 1 Standard Data Element D2 Type 2 - 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 items 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 hold 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, thereby facilitating the integration of new content into the Extended Travel Registration 9.

Figure 6 schematically shows the structure of an internal application of the content management engine 3 according to some embodiments of the invention, wherein the non-standard data container is a Business Object Model 21. L internal application can be a stand-alone application or application in a chain of applications (forming related applications).

The internal application includes:

- structured interfaces 2,

- a Business Object Model 21,

- a Business Layer 22.

Structured interfaces 2 represent the way 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 can 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 data structure changes, other possible related applications may also need to adapt their Business Object Model 21, their structured interfaces 2 and integrate the new version of the data model into other module interfaces. The various embodiments of the invention make it possible to limit the costs associated with such a modification by using the nonstandard data container model.

Travel service 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 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 traveler device 6. which 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 can be saved 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 applications chained 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 proceeding. from one server 30 to another in the middle of the processes. 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 coded for transmission to the next application A; ₊₁ of the string. In addition, the Business Object Model 21 can be involved in the process of filling and retrieving information in or from the structured interfaces 2 and can 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 ).

Consequently, in conventional approaches, whenever a data element must be modified in these chained applications, all the steps of the process can be impacted because each process must transmit the new data to the next process and will have to decode them, validate and code them. In addition, when new content needs to be added to an existing application, each process must further forward 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 self-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 nonstandard can not be stored as such in the standard PNR 90 because it does not include data types and attributes that are compatible with the standard structure of the PNR 90. 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 D in the format F1 of the first internal application A1 (for example, protocol buffers). The first application Al then passes the non-standard container to the next application of the chain using a message Ml using the auto-serialization / deserialization properties of the non-standard container. The message M1 can be a large binary object carrying self-serialization / deserialization information. The second application A2 can then extract the non-standard data container in F2 format from the internal application A2. Similarly, the second application may transmit the non-standard container to other applications in the chain using messages M2, M3, and so on. carrying the self-serialization / deserialization information until an An application triggers the creation of a record in the ETR 9.

Therefore, 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 data structure or transmitting a data item in a chain of internal applications. In addition, there is no need to modify existing data structures. The data contained in the nonstandard 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 nonstandard 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 "city" key is associated with the "Paris" value. 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 a 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 query 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 nonstandard 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 example, a binary representation) that can be stored and reconstructed by a deserialization mechanism to restore the data container to its original state. The nonstandard 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 non-standard data container keys, without the need for any 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, information on the type of content (eg air transport, taxi, sporting event, parking, urban transport, etc.) can be transported in the non-standard data container. himself. 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 nonstandard data container may be associated with a structure description file (e.g., XSD) describing an attribute structure of the data item (attribute topology, dependency of attribute, 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 schema associated with a non-standard data container, the different keys / values of the non-standard data container and the ancillary constraints applied to it may be described using a set of XML tags. Structure description files can be used when creating and modifying nonstandard 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 nonstandard data container can be used to validate the attributes of the non-standard data container when creating or modifying 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 can be configured to add new data to a non-standard data container, by updating the structure description files (for example, XSD) describing the non-standard data container structure. , 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 nonstandard data container is therefore dynamic and able to be updated 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 1 that have different types ("Phone 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 exposed by the Travel Management System 100 on the client devices 7, regardless of the type. content returned to a client device 7 and the applications maintained by the content management engine 3.

Extended Travel Registration 9 can be used by a considerable number of applications. For example, the content management engine 3 may comprise a set of applications (for example, travel applications) for delivering different types of travel services to the client devices 7 based on the external content received from standard travel provider systems. 4 (eg, airline products) and any other travel provider system 5 (eg, off-line products), regardless of the type of content. These services may include, for example, the services Boutiques, Reservations, Pricing, Insurance, Reimbursement. 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 the need for 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 nonstandard 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 non-standard data types.

Each application can thus instantiate the generic element to be able to handle the non-standard containers in a fluid manner, regardless of the type of the 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.

As a result, adding a new content type in the non-standard PNR 91 does not impact and does not require adaptation to the applications processed by the content management engine 3 to ensure backward compatibility (e.g. , 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 include:

- a standard data element SD1 of type Tl

- a standard data element SD2 of type T2 - a non-standard data element NSD3, contained in a non-standard data container, type T3

a non-standard data element NSD4, contained in a non-standard data container, of type T4.

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 non-standard T3 data element at block 602. The generic element such as a mega-data container may itself contain a non-standard data container 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 data item of type T1 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 Tl data item corresponding to the standard data item NSD1.

The generic element forms a transient state of the non-standard data element, which allows the application to manipulate 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, the nonstandard data elements 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 abstract generic element type of nonstandard data elements: instead of defining a new element type each time a new content type has to be manipulated by the applications (new content added in the ETR 9), each application can thus instantiate a single generic element capable of handling any new type and attribute.

Referring back to Figure 3, the travel management system 100 can be adapted to exchange any type of data (standard and non-standard content) with any type of external client device such as a travel agency system. 70, a non-standard travel provider system 5, and any other main server within the same GDS via the internal interfaces 2.

In conventional approaches, the travel management system 100 can exchange data of a standard PNR with other target customer devices (for example, travel provider systems, travel agency systems) having their own data. standard for the PNR content format (target PNR content format) by implementing a hardware-encoded conversion to the standard format supported by the target client device interface. 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 15 to exchange any type of content. In a preferred embodiment, the second data exchange format 15 is a tag description language

In some embodiments of the invention, the nonstandard data elements 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 abstract generic element type of nonstandard data elements: instead of defining a new element type each time a new content type has to be manipulated by the applications (new content added in the ETR 9), each application can thus instantiate a single generic element capable of handling any new type and attribute.

Referring back to Figure 3, the travel management system 100 can be adapted to exchange any type of data (standard and non-standard content) with any type of external client device such as a travel agency system. 70, a non-standard travel provider system 5, and any other main server within the same GDS via the internal interfaces 2.

In conventional approaches, the travel management system 100 can exchange data of a standard PNR with other target customer devices (for example, travel provider systems, travel agency systems) having their own data. standard for the PNR content format (target PNR content format) by implementing a hardware-encoded conversion to the standard format supported by the target client device interface. 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 15 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 element includes a stmcture description file defining the attributes of the data element (topology and attribute format), such as an XSD for XML messages, 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 may be used to exchange data elements with an external client device, such as a non-standard travel provider 5, a travel agency system or other non-GDS system. In particular, the data exchange unit 11 can be used for:

- receive non-standard data items from a client device; or

transmit data elements of the ETR 9 to a client device.

The data exchange unit 11 may comprise a structure transformation engine 111 such as an XSLT engine for the transformation of a structure description file such as an XSD of an XSD1 source structure description file. in a target structure description file XSD2 and a data exchange message generator 112 for transmitting the 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 the transmission of an XSD1 source structure description file in receive mode or predefined client mapping rules. (for example, 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 receive mode, the data exchange unit 11 can receive an XML1 incoming data exchange message from an external client device 7 compatible with an XSD1 source structure description file defined by the external client device 7. Incoming message XML1 contains a non-standard data element 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 can transform the XSD1 structure description file of the message. entering 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 target structure description file XSD2 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 incoming message XML1 before the transformation of the source structure description file XSD1 into the target structure description file XSD2 to validate a number of conditions relating to the attributes of the XSD1 structure description file (for example, presence of mandatory attributes).

The non-standard type Ti data container can then be generated by mapping the fields of the XML1 data exchange message to the primitives of the non-standard data container. The non-standard data teller 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 new content added to 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. elements to add / modify, without requiring a code change.

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 (containing a non-standard data element or a standard data element of the type Ti previously converted into a nonstandard data container) . 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 nonstandard data container is also associated with key values corresponding to the values of the attributes.

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 9, the transformation engine 111 may transform the description file of XSD3 structure associated with the non-standard data container in the local structure description files 115 into an XSD4 target structure description file using the client mapping rules 117 associated with the non-standard data element type . The client mapping rules 117 define the transformation rules to the format of the interface of the target client device 7, for example to display the graphical user interfaces (GUI) 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 can be converted into a non-standard data container of the same type beforehand. using the data container converter 12. The standard data item can then be sent to the data exchange unit 11 in the form of a nonstandard 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 Graphical Interface, GUI), according to some embodiments.

If the data element is a standard data element (block 700), the standard data element of type Ti can be converted to a non-standard data container of the same type Ti at block 701 (similar to block 604 of FIG. 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 element in the form of a non-standard type Ti data container (block 700) associated with an XSD1 structure description file and key values Vi, 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 (for example, XSLT stylesheets). The mapping rules 113 are defined according to the format of the target interface of the client device 7.

In 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 nonstandard data container.

In block 706, the XML message is sent to the target interface of the client device 7 via the network 13. The target interface can 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 the data. and the 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 (by example, travel agency system) regardless of the type of content (standard, nonstandard, mixed content), with as little manual coding software as possible.

Service applications can directly use a homogeneous data structure to store data in interfaces 2. This makes the exchange between the interface layers and the BOM layers of another format of the data structure unnecessary. This 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 single platform.

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 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 dynamically generate a registration representation and homogeneous, regardless of 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 non-standard data container access (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 nonstandard data container (block 605 of Figure 6). The non-standard data container thus accessed can be returned by the method of Figure 14.

The content management engine 3 is therefore adapted to provide a single platform for all client devices 7 comprising a set of interfaces per service (for example, travel service) representing a single response regardless of the type of products to be handled. (for example: classic GDS airlift (flight) / GDS vehicle hire / non-GDS taxi / non-GDS restaurant ...). 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 system. external booking. 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 can be defined such that for a given record identifier II in the ETR 9 associated with a non-standard data item and a standard data item, if the item non-standard data and the standard data element are of the same general type (for example, "hotel"), the same representation can be generated for both data items at the target interface of the client device external 7 (for example, travel agency system) by mapping the XSDI structure description file associated with the non-standard data element and the XSD2 structure description file associated with the standard data element to a non-standard data element; 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 the 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 type container.

In addition, the transformation rules 117 can be defined so that attributes of the same type of any data element are mapped to the same underrepresentation, regardless of the content type (non-standard or standard), which includes the attributes (in the target description file). In the example described in FIG. 18, a standard TYPE D container comprising a set of attributes A1, A2, A3, A4 (as defined in the source structure description file XSD1) is first converted. into 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 engine of transformation 111, the representation XSD2 comprising representation attributes {E1, E2, E3, E4} corresponding to the source attributes {A1, A2, A3, A4}. As shown in the example of Figure 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 the client devices 7 (associated for example with travel agency systems) comprising a set of application interfaces, through which a single response can be generated independently of the type of content that needs to be handled (eg, 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 data in the interfaces. This makes the exchange between the interface layers and the BOM layers unnecessary for another format of the data structure. It further reduces the overhead between the data stored in the Extended Travel Record 9 and the representation of the data in the service interfaces 2 exposed to the client devices 7 (eg, travel agency systems) via a platform. unique.

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 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) / GDS vehicle rental / non GDS taxi / non GDS restaurant ...).

Figure 20 depicts a flowchart of a content rearrangement 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 elements associated with a given file reference are arranged (eg, ordered) according to rearrangement criteria (eg pre-defined reordering criteria) when accessed by the application.

The content rearrangement method can be implemented to rearrange the data elements according to the reordering criteria predefined by the application, for example according to a chronological order, a storage criterion, 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 items 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 single type containing a 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 rules generated for example according to the rearrangement criteria ( for example, chronological order, the filter 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 element 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 FIG. 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 nonstandard data element of type Ti corresponding to the standard data element. of type Ti.

Similar to the generic element, the abstract element obtained forms a transient state of the non-standard data element, which makes it possible to abstract the type of data container. This further allows global manipulation of the attributes of data elements filtered by the application, 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 items 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 data element in the non-standard PNR 91 may share the same registration identifier as another data element in the non-standard PNR 91 or the standard PNR if the data elements are linked. The nonstandard 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 nonstandard 91 PNR storage area to the other standard PNR storage area 90 for each request that requires handling the global extended journey record 9.

Although ETR 9 is divided into two record data structures 90 and 91, ETR 9 can be managed globally based on the common record identifiers identifying related data items, auxiliary container data, and / or 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 "or" Central Management Area ") for the registration of auxiliary container data related to each data container created in the ETR 9, such as the date of creation of a data container, the last modified date 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 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 input 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 to be 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 non-standard data structure. auxiliaries 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 or databases 8.

The auxiliary data structure 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 record data structure 90 and the non-standard record data structure 91 in the databases.

The travel management system 100 may include an ETR control unit 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 of the auxiliary data structure 92). standard registration data 90 and / or non-standard registration data structure information 91).

In one embodiment, the ETR controller 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 data 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 data structure. For example, each time the ETR 9 is saved in the database from the context, the version information is updated in the 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 data structure. auxiliaries 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 for 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 media such as a wired network or direct wire connection, and wireless media such as acoustic wireless, RF, infrared, and other media. 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. 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 executed and thereby produce a computer implemented method so that the executed instructions provide methods for implementation. functions / acts 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 the intention of the Applicant to restrict or limit in any way to these details 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 (13)

A method of accessing content in a content management system (100) comprising a set of applications and an extended registration data structure, said extended data structure comprising a standard registration data structure ( 90) for storing records, said records having predefined standard data elements of standard types as standard data containers and a non-standard registration data structure (91) for storing records including non-standard data elements of different types from said predefined standard types, in the form of non-standard data containers, said method comprising, in response to an access request of an application to a set of data elements associated with the extended registration data structure, based on access criteria: a. for each data item in said set of associated data items, filtering attributes of the data container associated with said data item in the extended record data structure (9) according to the filter rules, and b. generating an abstract container to which a unique abstract type is assigned and including said set of filtered attributes of said data container. 2. Method according to the preceding claim, wherein each non-standard data container is associated with a structure description file describing the structure of the attributes of the non-standard data container, and step a. further comprising transforming the structure description file associated with the nonstandard data container according to a predefined mapping scheme into a target structure description file, said filtering rules being applied to said target structure description file. The method of any one of the preceding claims, wherein step a. includes, for each standard data element, the prior conversion of the non-standard data container associated with said data element in the extended registration data structure (9) into a non-standard data container associated with a description file of structure. A method of accessing content in a content management system (100) comprising a set of applications and an extended registration data structure, said extended data structure comprising a standard registration data structure ( 90) for storing records, said records having predefined standard data elements of standard types as standard data containers and a non-standard registration data structure (91) for storing records including non-standard data elements of different types from said predefined standard types, in the form of non-standard data containers, said method comprising, in response to an access request of an application to a set of data elements associated with the extended registration data structure, based on access criteria: a. for each data item in said set of associated data items, filtering attributes of the data container associated with said data item in the extended record data structure (9) according to the filter rules, and b. generating an abstract container to which a unique abstract type is assigned and including said set of filtered attributes of said data container. 2. Method according to the preceding claim, wherein each non-standard data container is associated with a structure description file describing the structure of the attributes of the non-standard data container, and step a. further comprising transforming the structure description file associated with the nonstandard data container according to a predefined mapping scheme into a target structure description file, said filtering rules being applied to said target structure description file. The method of any one of the preceding claims, wherein step a. includes, for each standard data element, the prior conversion of the non-standard data container associated with said data element in the extended registration data structure (9) into a non-standard data container associated with a description file of structure. The method of any of the preceding claims, wherein the abstract container is a Business Object template. The method of any one of the preceding claims, wherein said access criteria are scheduling criteria. The method of claim 5, wherein said method further comprises: c. scheduling said abstract elements according to said scheduling criteria; and D. the return of said ordered abstract elements to the application. The method according to any one of the preceding claims 5 and 6, wherein said scheduling criteria comprise a chronological order associated with temporal attributes and said predefined filtering rules correspond to said temporal attributes. The method according to any one of the preceding claims 5 and 6, wherein said predefined order is an alphabetical order associated with an attribute type and said predefined filtering criteria correspond to the attributes of said types. The method of any one of the preceding claims 2 to 8, wherein said non-standard data container comprises an attribute defining its type and said structure description file is stored in association with said type. The method of any one of the preceding claims 2 to 8, wherein said structure description file is an XSD schema and said predefined mapping schema is an SXLT style sheet. A method according to any one of the preceding claims, wherein each record in said extended record data structure (9) comprises a record identifier, the records in said extended record data structure corresponding to items of associated data sharing a common registration identifier, the application identifying said set of associated data items using said common registration identifier. The method of any one of the preceding claims, wherein the non-standard data item is a Business Object template capable of serializing into any application format. A system for accessing content in a content management system (100) comprising a set of applications and an extended record data structure, said extended data structure comprising a standard registration data structure ( 90) for storing records, said records comprising standard standard data items predefined as standard data containers and a non-standard record data structure (91) for storing records including non-standard data elements of different types from said standard predefined types in the form of non-standard data containers, said system being configured to: filtering the attributes of the data container associated with each data element in said set of associated data elements according to the predefined filtering rules, and generating an abstract container to which is assigned a unique abstract type and comprising said set of data elements. filtered attributes of said data container.