KR101699613B1 - Content exchange method and system - Google Patents

Abstract

A method of exchanging content in a content management system (100) including an extended record data structure (9) is provided. The extended record data structure includes a standard record data structure 90 for storing records associated with standard content elements having a predefined type and a non-standard record data structure 91 for storing records associated with non-standard content elements , Each non-standard content element is a technical object that can serialize itself into the target format and includes a set of keys and a set of respective key values for each attribute of the non-standard data element. Each non-standard data element is further associated with a respective structure description file that defines the structure of the attributes of the non-standard data elements, the method comprising the steps of: using a data exchange message according to the data exchange format (15) , The data exchange message comprising a structure description file associated with a non-standard data container containing a non-standard data element within the extended record data structure (9), and a property description file associated with the non-standard data container Lt; / RTI >

Description

{CONTENT EXCHANGE METHOD AND SYSTEM}

background

The present invention relates generally to data management, and more particularly to a method, system, and computer program product for exchanging content in a content management system.

A content management system may provide access to particular content to one or more clients (e. G., End consumers) connected to the system via a dedicated communications network.

With the advent of an enormous number of content distribution providers in each industry area, there is a need for each consumer to be able to access multiple content providers through their own content management system.

For example, in the travel industry, a travel management system may be used to distribute content obtained from a set of travel provider systems (content providers) to a plurality of travel agency systems (content consumers). Over the past several decades, the travel industry has grown tremendously, and at the same time, the services provided by the travel industry have changed significantly, and a wide variety of services are now available to end users, including heterogeneous content. In addition, the travel industry now includes many players, from travel suppliers to end consumers, along with a huge amount of data that needs to be managed among these players. An intermediary, such as Global Distribution Systems (GDS), between a travel provider and an end user, allows a travel agent to retrieve information from a traditional travel provider (airline provider) Or a transaction between a final consumer and a traditional travel provider.

The travel agency business model, which has been purely focused on air freight distribution, is evolving and players are now making higher returns thanks to non-air related content. Thus, a very important and diverse service from a new kind of travel provider is offered at the destination.

Through the appeal of these alternative distribution channels, the travel agency can provide non-GDS content (eg hotels, rental cars, etc.) as well as normal GDS content (eg, flight or rail travel content) More and more.

However, conventional travel management systems do not provide adequate means to provide information directly related to non-GDS content to travel agencies.

1, the travel management system 1 includes a "Passenger Name Record" data structure 900 for storing records related to GDS content received directly from the GDS content provider 40 ) ≪ / RTI > Each record (PNR) is identified in the database (DB) by the record locator. The PNR record locator can then be used to access the GDS content and distribute it to a travel agent or client device, such as the end consumer system 60. [

The PNR 900 data structure maintains a record locator in relation to the travel data associated with a given passenger or a group of passengers traveling together (the record locator may also be referred to as a confirmation number, a reservation number, a confirmation code, a booking reference, Lt; / RTI > For example, if a reservation is made for a passenger or a group of passengers, a PNR is generated in the data structure 900, and the PNR is generated based on data corresponding to the record locator and reservation content (e.g., Air travel data such as time, etc.).

Currently, the travel management system can not receive non-GDS content directly from non-GDS travel provider 50 due to standardization constraints.

In practice, the manner in which the travel management system exchanges with the standard travel provider 40 is defined by the International Air Transport Association (IATA) as defined by AIRIMP (ATA / IATA Reservations Interline Message Procedures - Passenger) It depends on the rule. Specifically, the messages exchanged between the standard travel provider 40 and the travel content management engine 30 must satisfy the message exchange format (TTY (Teletype format) defined by the IATA standard) PNR 900 is configured to handle only content received in this TTY format.

There is no defined industry standard for content and layout of the PNR 900 that is usually mentioned. However, each travel management system (e.g., Computer Reservation System (CRS)) considers the constraints of AIRIMP and, in particular, the need to easily map PNR data to AIRIMP messages, for PNR content and layout. And define their own proprietary standards. Thus, there are many similarities to the format and data content of the PNR 900 maintained by different travel management systems. In particular, each PNR data structure 900 indicates that the travel data associated with the record locator must satisfy a number of predefined types corresponding to GDS content (air travel data, train travel data, etc.) standardized by IATA Such a structure.

Thus, only GDS content (e.g., air travel, train travel data) can be maintained in the PNR data structure 900 in a static format that meets the constraints associated with the IATA message exchange standard. Therefore, it is impossible to generate a record for non-GDS content (car rental, jet ski, etc.).

US2012259667 provides a solution for storing non-GDS content in PNR 900 in the form of a remark, guitar or ghost segment. This solution, however, permits the travel management system to dynamically and seamlessly store non-GDS content received directly from the non-standard travel provider in a structured manner at the head of the PNR 900, among other GDS elements I never do that.

Thus, the conventional travel management system 1 only handles content from GDS travel providers such as airline route providers. Conventional travel management systems include a travel content management engine 30 that uses a tremendous number of applications, each of which is associated with a particular travel service (e.g., booking, shopping, pricing, etc.) do. In response to a request from a given travel agent (Ai) 70, the travel content management engine 30 retrieves only the content from the GDS travel provider 40, creates a record within the PNR 900, A representation of the PNR record may be returned to the travel agent Ai.

Each travel agent should be directly connected to the set of non-GDS providers 50 if the travel agent needs to access non-GDS content, but the travel management system 1 is only directly connected to the GDS content provider 40 . 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, entertainment tickets, etc.). Thus, the travel content management engine 30 exposes n travel service platforms (one platform 2.1, 2.2 ... 2.i, 2.n) for each travel agent A1 to An, Only the standard travel content (GDS content) from the standard travel provider 40 is handled.

Thus, if a given travel agent Ai desires certain content (e.g., museum ticketing) from a non-standard travel provider 50, such content must be implemented by the travel agent Ai itself. This self-implementation is particularly costly and complex for travel agents.

Further, in the conventional method, the travel management system 100 stores the PNR contents in a local format (source PNR content format). However, the travel management system may be required to exchange data from the PNR with other external systems (travel providers, travel agencies) having their own format (the target PNR content format) for the PNR data. Thus, depending on the target system, the conversion of the PNR content associated with the PNR record of the travel management system may be performed in the target PNR content format. These transformations now involve hard coding and recompiling in a costly and static manner. Likewise, in an application flow using PNR content within the travel management system 100, each internal application (chained application) in the application flow that receives the PNR content has the PNR content in application format It is requested to convert. Thus, each application in the chain is required to decode, validate and encode the PNR content so that it can record or read the PNR content, which requires the component to be manually coded and is costly.

Accordingly, there is a need for an improved content management system, method, and computer program product for dynamically and seamlessly exchanging content.

summary

To solve these and other problems, there is provided a content management method as defined in the appended independent claim claim 1, a content management system as defined in the appended claim 15. Preferred embodiments are defined in the dependent claims.

Thus, the method and system according to various embodiments of the present invention make it possible to exchange data without complex validation, encoding and decoding mechanisms and complex components. Validation of values of non-standard data containers may only be used when creating and modifying data elements represented by non-standard data container objects. Thus, the read process is unnecessary in re-validating the validity of the data element associated with the key.

Additional advantages of the present invention will become apparent to those skilled in the art upon review of the drawings and detailed description. It is contemplated that any additional advantages should be incorporated herein.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the invention and, together with a general description of the invention given above, and the detailed description of the embodiments given below, .
1 is a schematic diagram of a conventional content management system according to the prior art;
2 is a schematic diagram of a content management system in accordance with some embodiments including a plurality of computing systems coupled through a network;
3 is a schematic diagram of an exemplary operating environment including a content management system;
Figure 4 is a schematic diagram of the exemplary computing system of Figures 2 and 3;
5 is a flow diagram depicting a process that may be executed to add new content to an extended record data structure;
6 is a schematic diagram of the structure of an internal application executed in a content management system according to a certain embodiment;
Figure 7 is a schematic depicting the operation of an internal application based on a technical object of a business model object type;
8 is a schematic diagram of a content management system depicting exemplary interactions between internal applications;
Figure 9 is a schematic diagram of an exemplary non-standard data container defined by a set of key values;
10 is a schematic diagram of an exemplary serialization format;
Figure 11 is a schematic diagram of the exemplary non-standard data container of Figure 9 with type information included in a non-standard data container;
Figure 12 is a schematic diagram of an exemplary structure description file associated with the non-standard data container of Figure 11;
13 is a flowchart of a process that may be executed for content access by an application;
14 is a schematic diagram of an exemplary content exchange unit;
15 is a flowchart of a process that may be executed to transmit content to a client device;
16 is a schematic diagram of an XSLT transformation of a standard data container of type C;
Figure 17 is a schematic diagram of an XSLT transformation of a non-standard data container of type C that is the same as the standard data container of Figure 16;
18 is a schematic diagram of an XSLT transformation of a standard data container of type D containing a set of attributes;
Figure 19 is a schematic diagram of an XSLT transformation of a non-standard data container of type E with some attributes identical to the attributes of the standard data container of Figure 18;
20 is a flow diagram of a process that may be executed to rearrange data elements; And
21 is a schematic diagram of an extended record data structure, in accordance with some embodiments.

details

The method, system, and computer program product according to an embodiment of the present invention may be used for dynamic management of any type of content (standard and non-standard) received from a content provider and for managing the center of the record It may also allow centralized storage. Content management system 100 may be based on a client / server architecture that enables reception of client requests.

Referring to Figure 2, a content management system 100 is provided in which a plurality of user clients 7 are connected to an arbitrary number of content providers 4, 5 provided by a set of content provider systems 4, Lt; RTI ID = 0.0 > content-specific < / RTI > The content handled by the content management system 100 is stored in a standard content provider system (e. G., A standard content provider system) that communicates with the content management system 100 in accordance with a first type of message exchange format 14, such as a pre- 4 from the non-standard content provider system 5 that communicates with the content management system 100 in accordance with a second type of message exchange format 15.

The content management system 100 may be coupled to the communication network 13 and the communication network 13 may be connected to the Internet, a local area network (LAN), a wide area network (WAN), a cellular voice / , One or more high-speed bus connections, and / or other types of communication networks.

The content management system 100 may be dedicated to one or more specific service areas (e.g., travel areas). Each of the one or more client devices 7 may be connected to the communication network 13 such that the user may initiate a service request session with the travel management system 1 and may initiate a service request session with the travel management system 1, Lt; / RTI >

Embodiments of the invention may be implemented by a computing system that includes one or more networked computers or servers. The computing system may 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 smart phone, and / or other such computing devices. Each client device 7 may host a web browser and / or custom application software (e.g., 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 host the one or more websites.

A user manipulating one of the client devices 7 (i.e., a traveler) may use the client device 7 during a service request session associated with the application (e.g., accessed by connecting to a web service) Or may interface with the system 100. The content management system 100 includes a content management engine 3 for processing a service request received from the client device 7. [

The content management engine 3 may exchange messages with the standard travel provider 4 using a standardized TTY message exchange format (first message exchange format 14) according to the IATA standard.

Content management engine 3 may further exchange messages with non-standard supplier 5 via data exchange unit 11 (also referred to herein as "content access unit"). The data exchange unit 11 is adapted to receive a search request from the user client 7 in response to a search request, a booking request, a pricing request, an issuance request related to the travel agent entity , A message defined in a data description language such as an extensible markup language (second message exchange format 15) to communicate with a non-standard content provider.

A user may enter information into the client device 7 via a user graphical interface created on the client device 7 by an application running on the content management system 100 (e.g., in the form of a web service) To the content management system 100. In this case, The 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 a user request, the content management engine 3 may request and obtain content from the content provider systems 4 and / or 5 according to the message exchange formats 14 and / or 15, The record may be stored in the extended record data structure 9. The extended record data structure 9 may be stored in a context and may be stored in one or more databases 8 in response to a storage 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 the standard data and a non-standard record data structure 91 for storing the records in relation to the non-standard data.

The record contains a record identifier (also referred to as a "record locator") in conjunction with the associated data element. The record identifier may be of any type and any format, such as a number.

The standard record data structure 90 is static, since it is adapted to store only records for predefined types of content that have one or more of the predefined set of attributes. As used herein, the term "standard" refers to a standard content having a format and / or type supported by a predefined format and / or a type corresponding to the format and / or a standard record data structure 90 do.

For received content that includes an associated data element, a record may be added to the standard record data structure 90 if the received content includes only standard data elements. The record includes a record identifier in association with the data element.

Alternatively, for received content that includes an associated data element, a record may be added to the non-standard record data structure 91 if the received content includes only non-standard data elements. The record includes a record identifier in association with at least one non-standard data container containing non-standard data elements.

In addition, for a received content that includes an associated data element, the standard record data structure 90 and the non-standard record data structure 91, if the received content includes a non-standard data element and a standard record data structure 90, A record may be added to the record. Both of the two records added to the standard record data structure 90 and to the non-standard record data structure 91 for the received content may be assigned the same record identifier (hereinafter referred to as a "common record identifier"). The common record identifier is shared between one or more standard data elements (standard content) in the standard record data structure 90 and / or one or more non-standard data containers (including non-standard data elements) do.

By using the same identifier in both the record data structures 90 and 91 to identify the relevant standard and non-standard data elements, the content management system 100 can provide two record data structures, as if they were unique record data structures As it forms, it manages transparently.

The content management engine 3 may maintain a plurality of applications associated with different services. The content management engine 3 can execute one or more applications in response to a service request received from the client device 7, which retrieves content from the content provider system and records related to the received content in an extended data structure 9 ≪ / RTI > The content management engine, based on the record stored in the extended record data structure 9, whatever the type of content, can be used to record the response to the service request to the user client < RTI ID = 0.0 >Lt; / RTI > In order to return a response to the client, the content management engine 3 is responsible for providing a uniform representation of the content on the client device 7, whatever the types of content contained in the retrieved record from the extended record data structure 9 The data exchange unit 11 may be used. Therefore, the content management engine 3 functions as an application aggregator for providing a service to the user client 7.

In a preferred embodiment of the present invention, the content management system 100 may be a travel management system. The travel management system 100 may be implemented by an operator operator (e.g., Global Distribution System (GDS) in the field of travel) to allow centralized management of travel content, such as Global Distribution System (GDS) ). ≪ / RTI >

FIG. 3 shows an exemplary operating environment 10 of such a travel management system 100 implemented in the GDS 1. In this embodiment, the standard content refers to GDS content (e.g., air travel, train travel content) that conforms to the IATA constraints provided by the standard travel provider system 4, while non-standard content refers to non-standard travel provider systems 5 (E.g., a car rental) provided by a non-GDS or non-GDS content that does not meet an IATA constraint that is outside the GDS. The standard record data structure 90 may be a standard PNR data structure (hereinafter also referred to as "standard PNR ", PNR is abbreviation of Passenger Name Record) configured to store standard content, Quot; non-standard PNR ") is configured to dynamically record any type of non-standard content, without having to predefine the type and attributes of the non-standard content by hard-coding the data mapping and editing mechanism . The standard PNR 90 includes a schedule of short trips with a predefined data structure (type, attribute, family) and / or other travel services including short trips such as hotel and rental car reservations Lt; RTI ID = 0.0 > a < / RTI >

The extended record data structure 9 forms an Extended Travel Record (hereinafter also referred to as an "ETR"), in which each content record is associated with a content management engine (3).

The client device 7 may be associated with a plurality of travel agency systems 700 requesting service via each client interface 2. More generally, the travel management system 100 is configured to communicate with each of the user interfaces 2 or even the travel provider system 4 or 5 (e.g., to exchange content stored in the extended travel record 9) Such as a traveler device 6, that submits a different type of request depending on the client / server manner via the client device.

The standard travel provider system 4 may include a plurality of carrier systems or traveler systems. The non-standard travel product supplier system 5 may include a vehicle rental system, a museum reservation system, and the like. The carrier system may, in implementation, include a billing system for each airline enabling a Computer Reservation System (CRS) and / or a GDS (1). The travel agency system 700 may be configured to reserve and pay for travel tickets and / or additional services provided by the non-standard travel provider 5. Some standard travel provider systems 4 may be provided either directly or via the GDS 1 to enable a validating carrier to sell a ticket for a seat provided by an operating carrier, They may interact with each other. The operating carrier may then charge the validing carrier for the provided service.

The GDS 1 may search for available intervals on one or more carrier systems 4 via the GDS 1, bookmarking reservations and adding additional services (e. G., Vehicles < / RTI > May be configured to facilitate communication between the travel providers 4 and 5 and the travel agency system 700 by making it possible to search for and book the travel agency, rental, museum tickets, and the like.

Each travel agency system 70 may include a web server that provides a publicly accessible web site. The web site may be configured to provide access to travel plan features, such as the ability to search for travel products that match the travel request. To that end, travel agency system 70 provides travelers with access to data from one or more databases hosted by GDS 1, travel providers 4 and 5, and travel agency system 70 You may. In an alternative embodiment of the present invention, the travel agency system 70 may be a proprietary system that restricts access to travel service providers or travel agents, in which case the access may be provided via a private web site or other application .

The traveler or travel agent may use the travel agency system 70 to create and / or retrieve travel offers that meet travel requests received from travelers using a particular travel application (e.g., a travel planning application) have.

The traveler device 6 may be connected directly to the travel management system 100 via an open or private network 13 (e.g., the Internet). The traveler device 6 may be any suitable computing system configured to communicate with the travel management system 100 via the network 13. For example, the traveler device 6 may include a desktop, laptop, or tablet computer, a smartphone, or any other computing device that enables a traveler to search and book travel services via the network 20 have. In an embodiment of the present invention, the traveler device 6 is a web browser application that communicates with a web service application hosted by the content management engine 3 of the travel management system 100 to submit travel requests in accordance with the web service application. .

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

The travel request can be used to create a travel restriction that meets the travel request, in order to obtain data relating to, for example, available travel segments, via the GDS (1) or other GDSs, and / (E. G., Vehicle rental, jet skiing, museum ticket bookings, etc.) corresponding to non-standard content provided by non-standard supplier 5 may be submitted.

4, the GDS 1, the travel management system 100, the travel provider systems 4 and 5, the travel agency system 70, the traveler device 6 of the operating environment 10 may include one or more Computing devices or systems (collectively referred to as a computer, e.g., computer 30). The computer 30 includes a processor 32, a memory 34, a mass storage memory device 36, an input / output (I / O) interface 38, and a Human Machine Interface ; 40). The computer 30 may be operatively coupled to one or more external resources 42 via the network 22 and / or the I / O interface 38. The external resources may include, but are not limited to, a server, a database, a mass storage device, a peripheral device, a cloud-based network service, or any other suitable computing resource that may be used by the computer 30.

The processor 32 may be a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuit, analog circuit, digital circuit, Or any other device that processes the signal (analog or digital) based on the computational instruction to be processed. The memory 34 may be a read only memory (RAM), 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 information. The mass storage memory device 36 may include a data storage device such as a hard drive, an optical drive, a tape drive, a non-volatile solid state drive, or any other device capable of storing information. The database 44 may reside on the mass storage memory device 36 and may be used to collect and organize the data used by the various systems and modules described herein.

The processor 32 may operate under the control of an operating system 46 resident in the memory 34. The operating system 46 may be configured to manage computing resources such that computer program code embodied as one or more computer software applications, e.g., applications 48 residing in memory 34, may have instructions to be executed by the processor 32 It is possible. In an alternative embodiment, the processor 32 may execute the application 48 directly, in which case the operating system 46 may be omitted. One or more data structures 50 may also reside in memory 34 and may be used by processor 32, operating system 46, and / or application 48 to store or process data.

The I / O interface 38 may provide a machine interface that operatively couples the processor 32 to other devices and systems, such as the network 22 and / or external resources 42. Thereby, the application 48 may cooperatively operate with the network 22 and / or external resources 42 by communicating via the I / O interface 38 to provide various features including embodiments of the present invention, Functions, applications, processes, and / or modules. The application 48 also includes program code that is executed by one or more external resources 42 or is otherwise dependent on functions and / or signals provided by other systems or network components external to the computer 30 You may. Those of ordinary skill in the art will appreciate that there may be a number of computers or other external resources 42 located outside of the computer 30 that are distributed among the computers or other external resources 42, It will be appreciated that embodiments of the present invention may include applications provided by computing resources (hardware and software) provided as services through the network 22, such as services.

The HMI 40 may be operatively coupled to the processor 32 of the computer 30 in a known manner that allows a user of the computer 30 to interact directly with the computer 30. [ The HMI 40 may include video and / or alphanumeric displays, touch screens, speakers, and any other suitable audible and visual indicators capable of providing information to the user. The HMI 40 may include an input such as an alphanumeric keyboard, pointing device, keypad, push button, control knob, microphone, etc., which may receive instructions or input from a user and transmit the input to the processor 32 Devices and controls may also be included.

The following description will be made with reference to the content management system 100 of FIG. 3 for illustrative purposes only.

Thus, different travel agents connected to the travel management system 100 through each travel agency system 70 may be configured to provide travel agent systems 100 with whatever type of content (e.g., standard airline content, taxi, entertainment tickets, etc.) Can be accessed directly via a platform specific to any type of content provided by the set of content (4, 5). Thus, the travel management system 100 can be used not only for standard content that complies with the standard PNR data structure 90, but also for other purposes, while preventing the travel agency from having to book these non-standard content outside the GDS system, Provides the possibility to store any new type of content (i.e., taxi path, movie tickets, concert, goody, etc.).

By attaching the non-standard PNR 91 to the standard PNR 90, the travel management system can dynamically and smoothly provide an unlimited number of travel services to the travel agency system 70.

Thus, the twice-extended travel record 9 forms a structured representation of the content provided by any travel provider system 4 or 5 (which may correspond to a product that is bugged outside the GDS), but the ETR 9 May be accessed and managed as if the standard PNR 90 and the non-standard PNR 91 formed a unique record data structure.

Standard data elements (e.g., products) in the standard PNR 90 may be qualified as mandatory or optional in accordance with the standard layout and format implemented by the GDS 1 to comply with the IATA standard It can be associated with a set of attributes.

The data held in the extended travel record 9 may be classified into a plurality of families, each family comprising a number of data elements, such as the five families shown in Table 1, for example. The ETR 9 is adapted to support any number of new data element types and families.

move Rooms Meals and drinks activity service airplane hotel restaurant Sports Activities insurance perry Apartment Bars & Clubs shopping Visa cruise Camping Other Show & Event Food train B & B walking tour Documentation carriage Other Excursions Leisure Equipment City traffic Other Local Services Transfer Meeting taxi vaccine car Other bicycle parking

The content management engine 3 is configured to manage the heterogeneous content of the ETR 9, and the management thereof may include:

- in response to a request from the travel agency system 70, for example, a new data element from any travel provider system 4 or 5, an extended travel record 9, whatever its content type, ;

- modifying the data elements in the extended travel record (9) by changing the start date of the "museum" product (eg, corresponding to a two-position pre-booking of the museum);

(Eg, by removing the product's bookkeeping from the extended travel record, if the user decides to remove the product "museum" from his or her New York trip) Delete;

- retrieving data elements from the extended travel record (9) (eg by retrieving all the structured attributes of the "museum" product from a particular travel record);

Thus, the extended travel record 9 may store both non-standard content and standard content as if they were part of a unique record data structure (PNR). The content management engine 3 manages the heterogeneous contents held in the extended travel record 9 in a manner transparent to the user client. The extended travel record 9 is more flexible and adapts to any type of new content (cab, metro, bus, museum ticketing, etc.), whatever the attributes associated with the new content.

The standard PNR (90) is organized according to the IATA standard. A given set of data elements is transferred from the 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 (e.g., a bookkeeping management flow) The following steps may be performed by the content management engine 3:

i. The data may be extracted by the content management engine 3 from an incoming message transmitted by the standard travel provider system 4,

ii. A record may be added to the standard PNR 90 which record identifier is associated with the data element corresponding to the data (content data) extracted by the content management engine 3. [

The data thus obtained may be used to build other messages to be sent to the next application in the application flow.

If the application flow involves a set of chained internal applications, step i may be performed by a given internal application of the application flow, but step ii may be triggered by another application of the flow.

The data added to the standard PNR 90 may have only a limited number of predefined attributes and must satisfy one or more predefined types and formats (normalized attributes).

The non-standard PNR 91 does not comply with the rules of the standard (IATA content definition, TTY message, IATA message) and historical constraints. However, the non-standard content can be part of the extended travel record 9 and is accessed smoothly and transparently by the application executed by the content management engine 3. [

Thus, the extended travel record 9 can include any type of standard content (e.g., GDS content such as air travel, hotels, cars, cruises, insurance, ferry) and non-standard content Etc.) in a structured manner and in a universal format.

In order to dynamically manage any type of content, the content management engine 3, in response to the received content comprising non-standard data elements transmitted from the non-standard content provider system 5 to the travel management system 100, Non-standard data container. The non-standard data container may be dynamically adapted to the format of the internal application of the content management system that receives the data element due to the automatic serialization nature of the non-standard data container. If the receiving internal application is an application of an application flow involving a set of chained applications (internal applications), then the non-standard data container may use the automatic serialization property of the non- Lt; RTI ID = 0.0 > format. ≪ / RTI >

More specifically, when the travel management system 100 is connected to a new travel provider 5 that provides a non-standard content type, the non-standard data elements received from the non-standard content provider system 5 may be associated with such non- Stored in a non-standard data container. A record may then be added to the non-standard record data structure 91 by an internal application (e.g., of an application flow). The record may include a non-standard data container having a record identifier and a non-standard content type. A nonstandard data container may contain a list of attributes, each attribute represented by a key and a value. Each attribute itself contains a list of sub-attributes, each represented by a key and value (as well as sub-attributes, etc.). Each attribute key is associated with a name and a type. A non-standard data container is configured to implement itself, whatever the structure it represents, or whatever data it contains, itself: a read-only access or read of any value of any attribute that is part of a non- / Non-standard data container, for write access (i. E. Acquiring and setting), may be implemented via a method that does not depend on either the key name or the key type, without having to implement a getter / setter method by hard- This makes access possible.

Thus, the non-standard data container can be used to create a new record in the non-standard PNR 91, whatever the type of content. Such records may be provided, for example, to execute a travel application, to generate an indication of a service request result for the client device 7, or to transmit content to an external device (e.g., a travel provider system or travel device) And can be accessed transparently by the content management engine 3 for any type of content management action.

Referring now to FIG. 5, a flow diagram depicting a process for creating a new record in an extended travel record 9 in response to content received from one or more travel provider systems is provided.

At block 501, the content management engine 3 may send one or more trips (e. G., ≪ RTI ID = 0.0 & And may receive content from providers 4, 5.

The content includes a plurality of related data elements, e.g., data items related to the same trip, such as sequentially received flight products (standard data elements) and taxi products (non-standard content) You may. The data elements associated with the common content may be received sequentially or in parallel. The data elements may include information identifying they are part of the same content.

The data elements may include standard data elements (e.g., air travel products) and / or non-standard data elements (e.g., taxi products).

Standard data elements (e.g., GDS content) may be received in accordance with a first message exchange format 14, such as TTY.

The non-standard data element may be received by the data exchange unit 11 in the form of a message defined according to a markup description language such as XML according to the second message exchange format 15. [ The following description will be made with reference to an XML message (also referred to as an XML document or file) for data exchange between the travel management system 100 and an external system. The data exchange message may include a structure description file for describing the structure of the message and the type and format of data included in the message. For example, for a data exchange message of type XML, an XML XSD schema may be used as a structure description file to provide a representation of the structure of the attributes of the XML message.

At block 502, for each element received for the common content, the content management engine 3 may extract the data element. Content extraction may be performed by an internal application of the content management engine 3. [

If the data element corresponds to a standard content (e.g., an airplane travel product), the content management engine 3 sends a standard data container (hereinafter " (Also referred to as a " standard container ") to generate a record R in a standard PNR 90 for standard content (e.g., an airplane travel product). A standard data container may be a static container configured for a predefined type of data element (a standard data element). The record R may be assigned a record identifier (I) and may be associated with a standard data container at block 504. The records may be stored in the temporary context and / or in at least one database 8.

If the data element corresponds to a non-standard content (e.g., a taxi product), the content management engine 3 uses non-standard data containers (also referred to below as "non-standard containers" (R) to the non-standard PNR (91) for the taxis (for example, taxi products). Step 505 may be triggered by one internal application of the application flow. An internal application that triggers the creation of a record in the ETR may be different from an internal application that receives non-standard data elements from the data exchange unit 11. [ For example, the first internal application A1 may receive the non-standard data element in the format F1 of application A1, and the non-standard data element may be a non- , And finally to the application An in the non-standard record data structure 91 (a non-standard data container with the format Fn) until it reaches the format Fn of the non- Triggers generation of records. A non-standard data container may be assigned to a type of data element (e.g., a taxi type).

A non-standard data container is adapted to include any type of data element (non-standard data element). The record R may be assigned a record identifier I and may be associated with a non-standard data container at block 506. The records may be stored in the temporary context and / or in at least one database.

In one embodiment, the non-standard data container generated at block 506 may be further allocated a tag at block 507. Such a tag may be used by the content management engine 3 when accessing the record R, for example, to identify a data element that should not be transmitted to the client device 7.

Thus, a record identifier (I) unique to the standard PNR 90 and the non-standard PNR 91 may be generated for all standard data elements and non-standard data elements corresponding to the common content (associated data element). Thus, this common record identifier can be shared to process records corresponding to them, such that heterogeneous data elements are maintained in a unique 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 non-standard data elements, whatever the type of the data.

In a simplified example, the extended travel record 9 may comprise, for example, several records assigned a common record identifier I1, which record identifier (ID1) is commonly associated with the following data elements:

- Type 1 standard data element (D1)

- a standard data element of type 2 (D2)

- Type 3 standard data element (D3)

- a tagged non-standard data element of type 4 (D4)

- Type 5 non-standard data element (D5)

- a tagged non-standard data element of type 2 (D6)

The records for the data elements D1, D2 and D3 are maintained in the standard record data structure 90 with respect to the record identifier ID1.

The records for the data elements D4, D5 and D6 are retained in the non-standard record data structure 91 with respect to the record identifier ID1 (in the non-standard data container).

The standard data container used to store standard data elements is specifically adapted to include data elements having a predefined set of types and attributes according to the IATA standard. Thus, standard data containers are only adapted to standardized data formats and data types.

A non-standard data container may be created whatever the type, attributes, and format of the non-standard data element. Each attribute itself may contain a plurality of sub-attributes.

Thus, the content management engine 3 uses a non-standard data container to dynamically create a new type of content in the extended travel record 9, whatever the type of the content.

A non-standard data container may be a polymorphic data container, unlike a standard container, that is not hard-coded into code for a given element. In contrast, the form it should take may be dynamically defined.

Non-standard data containers may also have automatic serialization / deserialization properties.

In some embodiments, the non-standard data container may be a technical object represented by a business object model 21 of an internal application that processes a non-standard data container, which may allow integration of new content into the extended travel record 9 .

Figure 6 schematically depicts the structure of an internal application of the content management engine 3 according to some embodiments of the present invention, where the non-standard data container is a business object model (21). The internal application may be a standalone application or an application within a chain of applications (forming the associated application).

Internal applications include:

- structured interfaces (2),

- Business object model (21),

- Business layer (22).

The structured interface 2 indicates how the applications communicate with each other. The structured interface may also convey functionality data to be processed by the application. They may be mapped to a business object model 21 used by the business layer 22 to perform and operate a validation action. The validation action corresponds to a functional check performed on the data by the business layer 22 in addition to the grammatical check. The data element may be inserted into the expanded record data structure 9 in a structured manner after validation.

As a result, modifications in the data structure of the extended PNR 9 may involve modification of the application business object model 21 and modification of its structured interface. Also, in order to benefit from the modification of the data structure, possible other related applications need to also adapt their business object model 21, their structured interface 2 and also incorporate a new version of the data model into the other module interface .

Various embodiments of the invention make it possible to limit the costs associated with such modifications by using a non-standard data container model.

The travel service application executed in the content management engine 3 may operate according to the diagram of Fig. The BOM 21 represents a business object model 21 used to represent an internal data model used by an application.

Service 210 may be any structured message received by travel management system 100 from travel device 6, client device 7, or non-standard travel provider 5 that an application may target, XML or electronic data exchange (Edifact) message.

Context server 211 represents storage (also referred to as a "context") of the context of the data used by the application between asynchronous interactions with other applications.

The data from the context may be stored in the database 8 in response to the request, periodically, or according to certain conditions.

Figure 8 illustrates the interaction between the chained applications A1 to AN of the content management engine 3, according to some embodiments. When the travel management system 100 is operated in a distributed architecture, the chained internal applications A1 to AN responsible for the process may call each other, which may be a number of application servers 30 ) (Also referred to as a back-end server), and each application server 30 is associated with a respective chained application Ai. At each stage of the chain of processes, in the conventional manner, the data transferred from the first back-end server 30 for the application A1 to the final server 30 for the application An is sent to the server 30, Encoded, and decoded in a different manner before being forwarded to other intermediate servers. Each backend server 30 also decodes the incoming data element and performs validation before accessing the data element for its own dedicated process. The data is then encoded and transmitted to the next application in the chain (Ai + 1). The business object model 21 may also be involved in the process of populating the information into the structured interface 2 or retrieving information from the structured interface 2 and may be used to write / read data. In a conventional manner, it requires a structured interface 2 and a hand-coded component for writing / reading data into / from the central record store. Thus, a single change to the data model may be costly. In addition, the data elements that an application is processing are generally subject to a number of functional constraints, such that each application may be required to ensure that the data being processed is in an appropriate format compatible with industry constraints.

As a result, in the conventional manner, the data elements must be modified each time in these chained applications, and every step of the process requires each process to transmit the new data to the next process and therefore decode it, It can be affected because it has to be verified and it will have to be encoded. Also, if new content is to be added to an existing application, each process must send additional content to the next process, and each process in the chain must decode, validate, and encode the new element.

The present invention in accordance with certain embodiments improves the situation by using the self-serialization property of non-standard data containers of the BOM type.

Specifically, the non-standard data container may be generated by the first application A1 in the chain, in response to receiving the data elements D1, D2 and D3 from the non-standard content provider 5. This non-standard content can not be stored in the standard PNR 90 as it is, since it does not contain data types and attributes that conform to the standard structure of the PNR 90. [ Non-standard content may take on various forms and may relate to various types and attributes.

The first application A1 may generate a non-standard container for each non-standard data element Dk, for example, in the format F1 of the first internal application A1 (e.g., protocol buffer) . The first application Al then uses a message M1 that uses the automatic serialization / deserialization feature of the non-standard container to pass the non-standard container to the next application in the chain. The message M1 may be a blob carrying the automatic serialization / deserialization information. The second application A2 may then extract the non-standard data container into the format F2 of the internal application A2. Likewise, the second application may use the messages (M2, M3, etc.) carrying the automatic serialization / deserialization information until the application An triggers the creation of a record in the ETR 9, You can also send non-standard containers to your application.

Thus, by using a non-standard data container, code changes are unnecessary for adding a new data structure to the ETR 9, updating the data structure, or sending data elements to a chain of internal applications. Also, there is no need to modify existing data structures. Data contained by a non-standard data container can be made available without having to extract it and convert it from one format to another. Thus, the intermediate / hand coded layer can be reduced.

As depicted in the example of FIG. 9, the non-standard data container 50 may be defined by a set of key values that describe a business object model that can be processed by an application. Each key 51 defines an attribute of the BOM and includes an associated value 52 (also referred to as "data" in FIG. 9). For example, a non-standard data container defined by the key "city " is associated with the value" Paris ". The data container may include a complex structure or may 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 FIG. 9) to associate a given data container with a set of related data containers. For example, a data container specified by a key / value pair of "phone / + 335551213 " includes a reference (" REF ") to the following data container:" mobile / + 336123456 " 335551213 ".

The non-standard data container 50 allows access to the content management engine 3 in a recording mode for any data element contained in a non-standard data container, without having to develop an accessor to allow such access. This ensures flexibility and scalability.

Access to the data elements contained in the non-standard data container can also be performed by the content management engine 3 at any time during application processing by using queries according to an appropriate query language such as Xpath.

Non-standard data containers can be programmatically compatible with backward and forward versions. From a programming perspective, code changes are unnecessary for use of a new version of the data element structure associated with a non-standard data container.

Non-standard data containers are configured to support serialization / deserialization. In particular, serialization may be performed upon creation and modification of one or more attributes of the non-standard content to encode the data container into an extensible format, and deserialization may be performed when the application needs to read at least one attribute of non-standard content .

In particular, the key and value of the non-standard data container may be used by a deserialization mechanism to restore the state of the technical object (e.g., BOM) that represents the non-standard data container to the original state, Can be serialized at any time by converting to a format that can be reconstructed (e.g., a binary representation). Thus, the non-standard data container can be transformed into any target format whatever the data contained in the data container. Serialization and deserialization mechanisms do not require hard coding. The serialization information may be embedded in a library associated with the data container. Thus, the use of such a BOM basically provides a serialization mechanism that may be supported for any kind of structure defined by a key of a non-standard data container, without requiring a specific coding. In some exemplary embodiments, the representation format of the non-standard data container used to transform the state of the non-standard data container according to the serialization / deserialization mechanism may be, for example, XML, ASCII, It may be based on JSON, a binary format.

Validation of the values of non-standard data containers may only be required upon creation and modification of data elements represented by non-standard data container objects. Thus, the read process is unnecessary in re-validating the validity of the data element associated with the key.

Through the use of non-standard data containers, information related to content types (e.g., flights, taxis, sports shows, parking, city traffic, etc.) can be conveyed into the non-standard data container itself. The type of the non-standard data container may be stored directly in the non-standard data container as a key.

In some embodiments, the validation mechanism in the creation or modification of a given non-standard data container may be based on a functionality type stored in a non-standard data element as a key instead of a C ++ type as in the conventional manner.

In some embodiments, each type of non-standard data container may be associated with a structure description file (e.g., XSD) that describes the attribute structure (attribute layout, attribute dependencies, and attribute format, etc.) of the data element.

A structure description file (e.g., XSD) further expresses the relationship between attributes and elements of a non-standard data container represented as a technical object (e.g., an XML object). Within the XSD schema associated with non-standard data containers, the different keys / values of the non-standard data container and the secondary constraints applied to it can be described using a set of XML tags. The structure description file may also be used in the creation and modification of non-standard data containers. In addition, auxiliary constraints may be applied to non-standard data containers using structure description files (e.g., XSD).

The structure description file associated with each non-standard data container may be used to validate the properties of the non-standard data container in the creation or modification of the non-standard data container. The validation mechanism may include verifying that the non-standard data element represented by the non-standard data container adheres to the description of the data element in which the content is to be located. In some embodiments, the validation mechanism may be implemented to verify that the data stored in the non-standard data container matches the target format by using a structure description file associated with the non-standard data container.

The trip management system 100 may maintain 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 may be updated at run time of the process.

The content management engine 3 may be configured to add new data to the non-standard data container by updating a structure description file (e.g., XSD) describing a non-standard data container structure, such as a new attribute.

A structure description file (eg, XSD) that defines a non-standard data container can be modified without having to hard-code the changes and re-file the code. Thus, modification of non-standard data containers is dynamic and updateable at runtime.

FIG. 11 is a schematic diagram of exemplary non-standard data containers of FIG. 9 showing their respective types: phone number type, address type, and GPS type. The information type may be stored as an attribute in a non-standard data container. This information may also be used to retrieve structure description files associated with non-standard data containers.

Figure 12 illustrates an XSD description file for an exemplary non-standard data container having different types (phone number type, address type, GPS type).

According to a certain embodiment, the content management engine 3 is capable of managing the type of content returned to the client device 7 and the application maintained by the content management engine 3, To generate a set of internal service interfaces (2) of the native platform exposed by the client device (7).

The extended travel record 9 may be used by an enormous number of applications. For example, the content management engine 3 may be configured to receive content from a standard travel provider system 4 (e.g., a flight product) or from any other travel provider system 5 (e.g., a non-flight product) May comprise a set of applications (e.g., travel applications) for delivering different types of travel services to the client device 7, whatever the type of content, based on the external content. Such services may include, for example, shopping, bookkeeping, pricing, issuing and refund services.

This service application is a system that is connected to the travel management system 100 via the client device 7 (for example, by way of example) without the need to adapt each application to N types of data added to the ETR 9 by hard- For example, in response to a service request from the agency system 70).

The result may be returned via the data exchange unit 11 using a response message of a given format, such as an XML message. Thus, the internal service interface 2 generated by the travel management system 100 may have an XML type.

A generic element (generic element type) having a unique type may be used to prevent the need to re-code and recompile each application to support any number of new types of non-standard data containers . A generic element is a megavata container configured to contain any type of non-standard data container. A generic element may appear as a container of a unique type by all service applications (hereinafter referred to as a "generic element type"), but a generic element may contain an infinitely large number of non-standard data types.

Thus, each application may instantiate a generic element so that it can handle non-standard containers smoothly, regardless of the type of data element contained in the data container. Thus, each application does not need to instantiate as many non-standard data containers as the new data types.

As a result, the addition of a new content type to the non-standard PNR 91 does not affect or require adaptation to the application handled by the content management engine 3 (e.g., by hardcoding ) Ensures backward compatibility.

13 is a flow chart depicting access by an application to a record from an ETR 9 having a given record identifier (I). For example, the record identifier (I) may include:

A standard data element SD2 of type T1;

- a standard data element (SD2) of type T2;

- a non-standard data element (NSD3) contained in a non-standard data container of type T3,

- Nonstandard data element (NSD4) included in the non-standard data container of type T4.

At block 600, the record associated with the record identifier (I) is retrieved from the ETR (9). The records may be associated with standard data elements SD1 and SD2 having respective types T1, T2, T3 and T4 and non-standard data elements NSD3 and NSD4 (non-standard data containers).

Each data element SD1, SD2, NSD3 and NSD4 is then processed separately.

Specifically, for each data element, e.g., NSD3, if the data element is a non-standard data element (block 601), the non-standard data element of type T3 includes a non-standard data element of type T3 at block 602 Lt; RTI ID = 0.0 > generic < / RTI > The generic element itself as a megavata container may include a non-standard data container of a particular type. A generic element may be implemented as a technical object, such as a BOM, or may be based on the same technology as a non-standard data container.

If the data element is a standard data element, e.g., SD1 (block 603), the standard data element of type T1 may be converted to a non-standard data container of the same type T1 at block 604.

At block 602, the non-standard data element thus obtained is then converted to a generic element of a unique generic element type that includes a non-standard data element of type T1 corresponding to the standard data element NSD1.

A generic element forms a transitory state of a non-standard data element that enables an application to process standard data elements and non-standard data elements, whatever their type. Thus, the application can process the data elements of the ETR 9 without explicitly knowing the type of non-standard content as if they had a unique type.

At block 605, if the application needs to be executed that one or more data elements are to be sent to the interface of the client device 7 originating the service request, then the application must pass the generic element to access the type of data element introspect).

In certain embodiments of the invention, non-standard data elements may be associated with each tag. In this embodiment, at block 601, only non-standard data elements associated with each tag may be selected by the application and converted to generic elements.

Thus, the generic element abstracts the types of non-standard data elements: instead of defining a new element type each time a new type of content (new content added to the ETR 9) is handled by the application, Thus instantiating a unique generic element that can support the new content type and attributes of.

3, the travel management system 100 may provide any type of content (standard and non-standard content) to the travel agency system 70, the non-standard travel provider system 5, or any other And may be adapted to exchange through the internal interface 2 with any external client device, such as a back-end server.

In the conventional manner, the travel management system 100 converts data from a standard PNR into a PNR content format (target PNR content format) by implementing a hard-coding conversion in a standard format supported by the interface of the target client device. (E.g., a travel provider system, a travel agency system) that has its own standard for the client device. This requires an encoding mechanism in the travel management system 100 and a decoding / validation mechanism in the target device. In fact, each travel management system may have its own standard for the format of the PNR content (source PNR content format) and therefore for the interface of the target device supporting only this format. This conversion (encoding / decoding / plausibility verification) now involves hard coding and recompiling in a costly and static manner.

The data exchange unit 11 allows the reception or transmission of the data exchange message from the 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 markup description language such as XML. Each data exchange message corresponding to a non-standard data element includes a structure description file defining the attributes of the data element (attribute layout and format), e.g., an XSD for an XML message, and a set of values corresponding to the value of the attribute.

14 shows the structure of the data exchange unit 11 according to a predetermined embodiment in more detail.

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. Specifically, the data exchange unit 11:

Receiving a non-standard data element from a client device; or

May be used to send a data element from the ETR 9 to the client device.

The data exchange unit 11 includes a structure conversion engine 111 such as an XSLT engine for converting a structure description file such as XSD from a source structure description file XSD1 to a target structure description file XSD2, And a data exchange message generator 112 for transmitting data in the form of a message defined according to the data exchange message. The XSLT engine may use a predefined local mapping rule 113 (e.g., an XSLT stylesheet) that defines a transformation rule for transforming the source structure description file (XSD1) in the receive mode, A predefined client mapping rule 117 (e.g., an XSLT stylesheet) may be used that defines transformation rules for transforming the structure description file (XSD1).

The travel management system 100 may maintain one or more predefined local structure description files 115 corresponding to different content types and corresponding to a structure description file to be locally applied by the travel management system 100, It can also be loaded dynamically.

In the receive mode, the data exchange unit 11 may receive the incoming data exchange message XML1 from the external client device 7 conforming to the source structure description file XSD1 defined by the external client device 7 . The incoming message (XML1) contains non-standard data elements of a given type Ti.

Each time this incoming data exchange message XML1 is received by the travel management system 100 comprising a non-standard data element, the conversion engine 111 is associated with the type of data element contained in the data exchange message XML1 The local mapping rule 113 may be used to convert the structure description file XSD1 of the incoming message into the target structure description file XSD2. Then, the target structure description file (XSD2) is added to the set of the local structure description file (115).

The data exchange unit 11 transmits the source structure description file XSD1 to the target structure description file XSD1 in order to verify the validity of a plurality of conditions related to the attribute of the structure description file XSD1 Prior to conversion to file (XSD2), a plausibility verification mechanism may be further applied to the incoming message (XML1).

The non-standard data container of type Ti may then be generated by mapping the field of the data exchange message (XML1) to a primitive of the non-standard data container. The non-standard data container is then added to the ETR 9 with respect to the target structure description file XSD2 stored at 115 for the type Ti, as described in connection with FIG. Any update or addition of new content in the ETR 9 can be done at run time.

Thus, the use of the data exchange unit 11 allows any incoming data exchange message received from the content provider systems 4, 5 to be sent to a number of non-standard data < RTI ID = 0.0 > Enables dynamic conversion to a container object.

In the transmission mode (dotted line), the travel management system 100 may transmit any data element from the ETR to the target interface of the external client device 7 via the data exchange unit.

In the transmission mode, the data exchange unit 11 receives as input the non-standard data container (including the standard data element or the non-standard data element of the type Ti previously transformed into the non-standard data container).

The non-standard data container of type Ti includes a structure description file (also referred to as a source structure description file), such as an XSD file 115, that contains a description of the attribute's layout and the attribute format of the attribute (key) Lt; / RTI > The non-standard data container is also associated with a key value corresponding to the value of the property.

If the data element to be transmitted by the travel management system 100 includes a non-standard data container of a given type Ti from the ETR 9, then the transformation engine 111 determines the client mapping rules 117 associated with the type of non- The structure description file XSD3 associated with the non-standard data container of the local structure description file 115 may be converted into the target structure description file XSD4. The client mapping rule 117 defines a conversion rule toward the format of the interface of the target client device 7, for example, for display on the GUI (graphical user interface) of the target client device 7 do.

If the data element to be sent to the client device 7 is a standard data element of type Ti (e.g. a GDS element), the standard data element is pre-transformed into a non-standard data container of the same type using the data container converter 12 It is possible. The standard data element may then be transmitted to the data exchange unit 11 in the form of a non-standard data container for transmission to the target client device 7.

15 depicts a flow diagram for transmitting data elements of type Ti to a target interface (graphical user interface (GUI)) of client device 7, in accordance with certain embodiments.

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

If the data element is a non-standard data element in the form of a non-standard data container of type Ti associated with the structure description file (XSD1) and key value Vi (block 700), then the non-standard data element of type Ti is directly processed at block 703.

At block 703, a source structure description file (XSD1) associated with the non-standard data container is retrieved.

At block 704, the source structure description file XSD1 parses the source structure description file XSD1 and parses the parsed field using the mapping rules 113 (e.g., an XSLT stylesheet) into the target structure description file XSD2 The target structure description file XSD2 is converted to the target structure description file XSD2 using the mapping engine 110 (for example, XSLT engine). The mapping rule 113 is defined according to the format of the target interface of the client device 7.

At block 705, the XML message containing the data element to be sent to the client device is generated by adding a value Vi associated with the non-standard data container.

At block 706, the XML message is transmitted over the network 13 to the target interface of the client device 7. The target interface may be dynamically and transparently adapted in response to the response of the XML message.

The external client device 7 also extracts the data elements contained in the XML message, without having to apply decoding and complex validation mechanisms to the data, whatever the type of the data and the format of the target interface Store according to your own standards.

By using a non-standard data container associated with the structure description file (XSD) and having the ability to serialize itself as a data exchange message of any format 15 (e.g., XML), a new kind of interface 2 ) Can be constructed.

In one embodiment, the data exchange unit 11 minimizes the software as hand-coded as possible so that whatever the type of content (standard, non-standard, mixed content) is, the client device 7 , The travel agency system), as shown in FIG.

The service application may use the homogeneous data structure directly to store the data in the interface (2). This eliminates the need to exchange another format of the data structure between the interface layer and the BOM layer. This also allows to reduce the overhead between the data representation in the service interface exposed to the client device 7 (e. G., The travel agency system) and the data stored in the extended travel record through its own platform.

Specifically, the method of FIG. 13 includes a representation of the results in response to a service request from the client device 7 (e. G., Travel agency system 70) and a representation of the results on the user- The representation of such a representation may be adapted to produce whatever content type (standard content or non-standard content) guarantees that the presentation is homogeneous.

When a record identifier associated with non-standard content and / or standard content is added to the extended record data structure 9, the service application is adapted to dynamically and uniformly generate a representation of the record whatever the new type.

The application of the content management engine 3 corresponding to the service request may access the record corresponding to the result obtained from the ETR according to the access method of Fig. 12 using the generic element.

An implementation of access to a non-standard data container 50 based on a unique generic element, whatever the type of content to be returned to the client device 7, may be used to access any type of content from the non-standard content provider system 5 Of applications to support. Therefore, the application of the content management engine 3 is independent of the type of the content.

In order to return the results to the interface of the travel agency system 70, the application may introduce a generic element to access the non-standard data container (block 605 of FIG. 6). The non-standard data container thus accessed may be returned according to the method of FIG.

Thus, the content management engine 3 is capable of providing a unique (non-GDS) service, regardless of the type of product being processed (e.g., traditional GDS flight product (air travel) / GDS vehicle rental / non- GDS taxi / Is adapted to provide a unique platform to all client devices (7) including a set of interfaces for each service (e.g., travel service) representing the response.

To facilitate integrating new content into the application, the internal service interface 2 associated with the application may comprise a set of common attributes for each content family. This makes it possible for a new element of an already existing content family to benefit from all the display functions available to the family.

In particular, the underlying data structure of the non-standard data container 50 may share a common format within a particular element category. For example, a format description file (XSDi) used to indicate a data element of a type airline section may be associated with the airline route section through the travel management system 100 or other external bookkeeping system, . In addition, an air route section may share a set of common data with elements from another category (e.g., a shipping category).

In particular, the transformation engine 111 is configured to determine whether a non-standard data element and a standard data element are of the same generic type (e.g., a non-standard data element and a standard data element) for a given record identifier I1 in the ETR 9 associated with both the non-standard data element and the standard data element, By mapping the structure description file XSD1 associated with the nonstandard data element and the structure description file XSD2 associated with the standard data element to the same structure description file of the common type conforming to the target interface, It may also be defined that the same representation may be generated for both data elements.

For example, as depicted in FIG. 15, a standard data element of type (type C) is first transformed into a non-standard container associated with the same type (type C) (block 701 of FIG. 7) A representation (XSD2) for type C is generated for the client device using a mapping rule (117) (style sheet) defined for the type C at the client device (111). As shown in the example of FIG. 17, the same representation (XSD2) will be used for non-standard containers of type (Type C).

In addition, the transformation rules 117 are used to determine whether the attributes of the same type of any data element are the same sub-representation, including attributes (in the target description file), whatever the content type (non-standard or standard) . ≪ / RTI >

In the example depicted in Figure 18, a standard container of type (Type D) containing a set of attributes A1, A2, A3, A4 (as defined in the source structure description file XSD1) (Block 701 of FIG. 15), and then a representation (XSD2) for the type D (target structure description file) is created in the client device using the transformation engine 111 , The expression XSD2 includes the rendering attributes {E1, E2, E3, E4} corresponding to the source attributes {A1, A2, A3, A4}. By applying the same mapping rule 117 to similar attributes of a source structure definition file (XSD), as shown in the example of FIG. 19, a set of attributes {C1, A2, A3, C4} The same expression {E2, E3} may be generated for attributes A2 and A3 of the non-standard container of the other type (type C). Accordingly, the mapping engine 11 will generate a representation (XSD3 = {F1, E2, E3, F4, F5}) having the same representations E2 and E3, respectively, for attributes A2 and A3.

Thus, content management engine 3 provides a unique platform to all client devices 7 (e.g., associated with a travel agency system) that includes a set of interfaces for each application, (For example, GDS air travel products, GDS car rentals, non-GDS taxis, non-GDS restaurants, etc.).

Thus, a service application can directly use a homogeneous data structure to store data in an interface. This eliminates the need to exchange another format of the data structure between the interface layer and the BOM layer. This also reduces the overhead between the data representation in the service interface exposed to the client device 7 (e. G., A travel agency system) over the native platform and the data stored in the extended travel record 9 Allow.

Thus, the data exchange unit 11 is capable of dynamically generating a representation that conforms to the result, whatever the type of content (standard, non-standard, mixed content) .

In particular, the data exchange message used to return the results to the client device 7 has a format close to the internal structure (e. G., XML), which is the structure description file used to define the element itself in the generic element (E.g., XSD).

Thus, the content management system 100 is capable of providing a unique (non-GDS), regardless of the type of product to be processed (e.g., traditional GDS flight product (air travel) / GDS vehicle rental / non- GDS taxi / Provides a set of interfaces for each travel service that represents the response.

Figure 20 depicts a flowchart of a content placement method in accordance with certain embodiments. The content associated with the common record identifier of the ETR 9 includes a set of data elements associated with the same trip. Depending on the application requesting a specific record identifier in the ETR 9, the application may require that different data elements associated with a given record locator be arranged (aligned) according to predefined reordering criteria when accessed by the application It is possible.

The content rearrangement method may be implemented to rearrange the data elements according to a rearrangement criterion predefined by the application such as chronological order, ranking criterion, and the like. The reordering method may merge standard and non-standard data elements into an abstract ranking model based on an abstract element. The abstract element may also be used to sort data elements according to the reordering criteria. Thus, an application may return an aligned merged data element according to a target interface constraint. This may result, for example, in an aggregated routing document where the PNR segment and the extension element (non-standard content) can be merged into the same view.

Specifically, 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 a unique element of the type Type abstract element. The attributes of the non-standard data container are filtered according to the filtering criteria generated based on the reordering criteria (e.g., the chronological order in which the filtering criteria select the date properties). The abstract element may be implemented as a technical object, such as a BOM, or may be based on the same technique as a non-standard data container and / or generic element. It should be noted that both the generic element and the abstract element allow abstraction of the type of data element.

If the data element is a standard data element of type Ti (block 803), it may be converted to a non-standard data container of the same type Ti at block 804 (as at block 604 of FIG. 6).

At block 805, the attributes of the non-standard data elements thus obtained are filtered according to a filtering criterion.

In block 806, the non-standard data element obtained in step 804 is transformed into an abstract element containing a set of filtered attributes of a non-standard data element of type Ti corresponding to a standard data element of type Ti.

Like the generic element, the obtained abstract element forms a transient state of the non-standard data element that makes it possible to abstract the data container type. It also enables global processing of the filtered data elements, whatever their type of attributes, by arranging the abstract model, and clearly arranges them according to the reordering criteria.

In the travel field, the standard PNR 90 may be stored in a storage area that is shared among a plurality of systems. Standard data elements maintained in the standard PNR 90 may have different types and each element may have its own serialization format. The standard data elements may share the same record identifier (e.g., common to the same passenger or itinerary) to which the data element is associated.

Likewise, the data element of the non-standard PNR 91 may share the same record identifier if the data elements are associated with the non-standard PNR 91 or other data element of the standard PNR. The non-standard PNR 91 may be stored in the same storage area as the standard PNR. Alternatively, the standard PNR 90 and the non-standard PNR 91 may be stored in different storage areas. The two areas may be managed by a global management mechanism to allow synchronization of the common data. The global management mechanism is responsible for linking a storage area dedicated to the non-standard PNR 91 to another storage area dedicated to the standard PNR 90, for all queries that require processing the entire extended travel record (9) .

Even if the ETR 9 is divided into two record structures 90 and 91, the ETR 9 is also able to determine, based on the common record identifier identifying the record data structure information, auxiliary container data and / It can be managed as a unit.

The ancillary data container data may include control information regarding each data container (e.g., creation date, last modified date, etc.). In a conventional manner, this information is stored directly in each standard data container in relation to record identifier 0 and may be accessed to manage a standard PNR (e.g., to periodically erase a standard PNR). However, this approach does not allow for optimal management of the two record data structures 90 and 91.

21 shows a structure of an ETR 9 according to a predetermined embodiment. As shown, in order to optimize the global management of the two record data structures 90 and 91, in some embodiments, the extended travel record 9 is stored in the respective data container < RTI ID = 0.0 > (Also referred to as a "centrally managed data structure" or "central management area") for maintaining auxiliary container data associated with the data container, e.g., the date of creation of the data container, . The information maintained in the ancillary data structure 92 may be used to manage both areas in a synchronous manner. Each entry in the ancillary data structure 92 may share the same record identifier as the data container created in the ETR 9. In addition, each record in the ancillary data structure 92 may be associated with a set of auxiliary container data associated with a data container (having the same record identifier) maintained in the ETR 9. The ancillary data structure 92 may be populated with the standard record data structure 90 and the data container information contained in the non-standard record data structure.

In some embodiments, each entry in the ancillary data structure 92 may include a set of auxiliary attributes associated with the data container that share the same record identifier in the expanded record data structure 9. Each entry may include an auxiliary data container for storing a set of auxiliary container data associated with a record of the ETR 9 that share the same identifier. The set of auxiliary container data may include a control attribute indicating control information associated with the record of the ETR 9 that shares the same record identifier, such as the previous date of erasure of the record.

In some embodiments, the data container information associated with every record in a given record data structure 90 or 91 may be maintained in a dedicated record (also referred to as a "container information record") of this record data structure 90 or 91 And may be assigned a specific record identifier (e.g., record identifier 0). The container information records of the standard record data structure 90 and / or the container information records of the non-standard record data structure 91 may be stored at different time intervals, for example periodically or in response to a query, or alternatively, May be copied to the non-ancillary data structure 92 whenever it is stored in one or more databases 8.

The ancillary data structure 92 may include record data structure information related to the standard record data structure and / or the non-standard record data structure, such as version information identifying the final version of the standard record data structure 90 in the database, Lt; / RTI >

The travel management system 100 may be configured to provide the ETR (e. G., Based on the auxiliary container data information and / or the standard record data structure information 90 and / or the non-standard record data structure information 91) 9 for managing the ETR control unit 18.

In one embodiment, the ETR control unit 18 is configured to determine whether the common PNR (90) for the common data using the common record identifier, auxiliary container data held in the auxiliary data structure 92, and / And an erase module 180 configured to periodically erase the records from the non-standard PNR 91 in a synchronous manner.

In some embodiments, the ETR control unit 18 handles concurrent access to the same record identifier in the standard PNR 90 and in the non-standard PNR 91 based on the data held in the ancillary data structure 92 The access manager 181 may be used. In this embodiment, the ancillary data structure may further maintain version information identifying the final version of the non-standard record data structure 91 and the standard record data structure 90 in the database 8. For example, each time the ETR 9 is stored in the database from the context, the version information is updated in the auxiliary data structure 92. The access manager 18 may be configured to manage access to the ETR 9 based on the version information maintained in the ancillary data structure 92. [

The program code embodying any of the embodiments of the invention described herein may be distributed individually or collectively as various other types of program products. In particular, the program code may be distributed using computer readable media, which may include computer readable storage media and communication media. An essentially non-volatile, computer-readable storage medium includes volatile and nonvolatile, removable and / or nonvolatile storage media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, Lt; RTI ID = 0.0 > non-removable type media. The computer-readable storage medium may be RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other solid state memory technology, Magnetic disk, CD-ROM (compact disc read-only memory), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, But may also include any other medium that can be read. The communication medium may embody computer readable instructions, data structures, or other program modules. By way of non-limiting example, communication media may include wired media such as a wired network or direct connection, and wireless media such as acoustic, RF, infrared and other wireless media. Any combination of the above should also be included within the scope of computer readable media.

The methods described herein may be implemented by computer program instructions that are provided to a processor of any type of computer to produce a machine with a processor for executing 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 the computer to function in a particular manner. To this end, the computer program instructions may be loaded to cause the execution of a series of operating steps to create a computer implemented process that causes the executed instructions to provide a process for implementing the functions / acts specified herein.

While the embodiments of the invention have been illustrated by the description of various examples and these embodiments have been considered in detail, it is not the intention of the applicant to restrict or limit the scope of the appended claims in any way. Additional advantages and modifications will be apparent to those skilled in the art. Accordingly, the invention in its broader aspects is not limited to the specific details, representative methods, and illustrative examples shown and described. In particular, while abstract elements have been described for rearranging content, it may be more commonly used by internal applications accessing content for different kinds of operations. The filtering rules applied to filter the attributes of the data container may vary depending on the intended action.

Claims (15)

A method of exchanging content in a content management system (100) comprising an extended record data structure (9), the method comprising:
Wherein the extended record data structure (9) comprises a standard record data structure (90) for storing records associated with standard data elements having a predefined type and a record associated with a non-standard data element having a different type than the predefined type Standard data record structure 91 for storing a non-standard data container in the form of a non-standard data container, each non-standard data container being a technical object capable of serializing itself into a target format, Wherein each non-standard data container is also associated with a respective structure description file defining a structure of attributes of the non-standard data container,
The method includes transmitting the non-standard data element from the non-standard record data structure (91) to a client device using a data exchange message according to a data exchange format (15)
Wherein the data exchange message is generated from an attribute value contained in the structure description file and the non-standard data container associated with a non-standard data container comprising the non-standard data element in the extended record data structure (9) To exchange content. The method according to claim 1,
The method includes converting the structure description file associated with the non-standard data container including the non-standard data element into a target structure description file using a predefined mapping rule associated with the client device (7) , A method for exchanging content in a content management system. 3. The method of claim 2,
Wherein the predefined mapping rules relate to attributes required to create a graphical user interface of the client device (7). 4. The method according to any one of claims 1 to 3,
Further comprising transmitting a standard data element from the standard record data structure (90) to a client device using a data exchange message according to a data exchange format (15)
The generation of the data exchange message comprises:
Transforming the standard data element into the non-standard data container to provide a non-standard data container associated with the structure description file and a set of attribute values; And
And generating the data exchange message from the attribute description value included in the non-standard data container and the structure description file associated with the non-standard data container including the standard data element.
A method for exchanging content in a content management system. 4. The method according to any one of claims 1 to 3,
And retrieving the structure description file associated with the non-standard data container based on the type of the non-standard data element.
A method for exchanging content in a content management system. 4. The method according to any one of claims 1 to 3,
And the type of the non-standard data element is stored in the non-standard data container as an attribute key. The method according to claim 2 or 3,
The content management system (100) includes a set of internal applications executable in response to a service request from a client device, each application being adapted to return a response to the graphical user interface of the client device (7) Wherein the response comprises a set of data elements transmitted in one or more data exchange messages in accordance with the data exchange format. 8. The method of claim 7,
The mapping rule may be used to map a data element of a given type to a corresponding data element of the same type in the target structure description file or to map a given attribute of a given type to a respective attribute of the same type in the target structure description file ≪ / RTI > wherein the method further comprises: 4. The method according to any one of claims 1 to 3,
A non-standard data element of a given type from a client device, a data exchange message in accordance with said data exchange format (15), said data exchange message being defined according to a source structure description file and comprising said attribute value and said non-standard Including an attribute associated with a non-standard data container containing a data element;
Using the predefined mapping rules associated with the content management system (100) to associate the source structure description file associated with the data exchange message to a target structure description file, the target structure description file associated with the type of the non- Storing in the content management system;
By mapping the attribute and attribute values of the data exchange message to keys and key values of the non-standard data container including a set of keys for each attribute of the non-standard data container and a set of respective key values, Creating the non-standard data container of the container; And
Further comprising: adding a record in the non-standard record data structure (91) in association with the non-standard data container.
A method for exchanging content in a content management system. 10. The method of claim 9,
Wherein the step of creating a non-standard data container is performed by a given internal application in a set of chained applications and the step of adding a record is triggered by any application in the set of chained applications. How to exchange content. 11. The method of claim 10,
Wherein the non-standard data container can be passed from an internal application to another application in the set of chained applications by using a message carrying serialization information. 8. The method of claim 7,
Further comprising updating the non-standard data element by modifying the structure description file stored in the content management system for the type of non-standard data element of the non-standard data container. 4. The method according to any one of claims 1 to 3,
Wherein each record in the expanded record data structure (9) comprises a record identifier. The method according to claim 2 or 3,
Wherein the data exchange message comprises an XML message and each structure description file comprises an XSD schema and the predefined mapping rule comprises an XSLT stylesheet. 1. A content management system comprising a computing device and a memory for storing an extended record data structure (9)
Wherein the extended record data structure (9) comprises a standard record data structure (90) for storing records associated with standard data elements having a predefined type and a record associated with a non-standard data element having a different type than the predefined type Standard data record structure 91 for storing a non-standard data container in the form of a non-standard data container, each non-standard data container being a technical object capable of serializing itself into a target format, Wherein each non-standard data container is associated with a respective structure description file that defines a structure of the attribute of the non-standard data container,
The computing device is configured to transmit the non-standard data element from the non-standard record data structure 91 to a client device using a data exchange message in accordance with data exchange format 15,
Wherein the data exchange message is generated by the computing device from the structure description file associated with the non-standard data container comprising the non-standard data element in the extended record data structure (9) and an attribute value contained in the non-standard data container Content management system.

Images