JP6559468B2 - Content management system - Google Patents

Description

  The present invention relates generally to data management systems, and more particularly to methods, systems, and computer program products for managing content including standard and non-standard content.

  A content management system may provide access to specific content to one or more clients (eg, end consumers) connected to the system through a dedicated communication network.

  As so many content distribution providers have emerged in each industry sector, there is a need for each consumer to have access to multiple content providers through a unique content management system.

  For example, in the travel industry, a travel management system allows a content obtained from a set of travel provider systems (content providers) to be distributed to multiple travel agency systems (content consumers). Can be used. The travel industry has grown significantly over the past few decades, and at the same time, the services provided by the travel industry have changed significantly, resulting in a wide variety of services now being offered to end consumers who need disparate content. ing. In addition, the travel industry now includes a large number of players, from travel providers to end consumers, with a large amount of data to be managed among those participants. Between the travel provider and the end user, a travel intermediary such as the Global Distribution System (GDS), where the travel agent obtains information from the previous travel provider (airline provider) or with the end consumer Provided is a travel management system that makes it possible to conduct transactions with conventional travel providers.

  The travel agency business model, focused on pure air transport distribution, has evolved, and now participants are generating higher sales profits thanks to non-air related content. Therefore, a variety of very important services from new types of travel providers are proposed at the destination.

  With the attraction of such alternative distribution channels, travel agencies distribute more and more non-GDS content (e.g. hotels, rental cars) in addition to regular GDS content (e.g. flight or railroad content). Tend.

  However, typical travel management systems do not provide an appropriate means of directly providing information related to non-GDS content to travel agents.

  As shown in FIG. 1, generally, the travel management system 1 is configured as a “Passenger Name Record” data structure 900 for storing records related to GDS content received directly from the GDS content provider 40. Contains known record data structures. Each record (PNR) is specified in the database DB by a record locator. The PNR record locator can then be used to access GDS content and distribute that GDS content to client devices such as travel agencies or end consumer systems (60).

  The PNR 900 data structure holds a record locator associated with travel data related to a given passenger or group of passengers traveling together (a record locator is a confirmation number, reservation number, confirmation code, reservation reference (booking also known as reference)). For example, when a reservation is made for a passenger or group of passengers, a PNR is generated in data structure 900, which includes a record locator corresponding to the reservation content (e.g., flight data such as arrival time, departure time, etc.) and Contains data.

  Currently, travel management systems cannot receive non-GDS content directly from non-GDS travel providers 50 due to standardization constraints.

  Furthermore, the way the travel management system interacts with standard travel providers (40) is determined by the ATA / IATA Reservations Interline Message Procedures-Passenger (AIRIMP). Follow the rules defined by the defined IATA (International Air Transport Association). In particular, messages exchanged between the standard travel provider 40 and the travel content management engine 30 must meet the message exchange format TTY (Teletype format) defined by the IATA standard, usually The PNR 900 is configured to handle only content received in such TTY format.

  No industry standards are so defined for PNR 900 layout and content. However, each travel management system (e.g., Computer Reservation System CRS) has its own specification for PNR layout and content that takes into account the limitations of AIRIMP and especially the need to easily map PNR data to AIRIMP messages. Define a standard. Thus, there are many similarities for the data content and format of PNR 900 held by different travel management systems. In particular, each PNR data structure 900 is such that the travel data associated with the record locator must satisfy several predefined types (flight data, railway data, etc.) corresponding to GDS content standardized by IATA. Is.

  Thus, only GDS content (eg, flight, railway data) can be held 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 related to non-GDS content (car rental, jet ski, etc.).

  US Patent Application No. 2012259667 provides a solution for storing non-GDS content in PNR 900 in the form of remarks, miscellaneous, or ghost segments. However, such a solution would allow a travel management system to dynamically process non-GDS content received directly from non-standard travel providers in a structured manner before other PDS 900, among other GDS elements. It does not make it possible to memorize seamlessly.

  Therefore, the normal travel management system 1 handles only content from GDS travel providers such as airline providers. A typical travel management system includes a travel content management engine 30 that uses a large number of applications, each application associated with a specific travel service (eg, booking, shopping, pricing, etc.). In response to a request from a given travel agency Ai (70), the travel content management engine 30 retrieves content from the GDS travel provider 40, generates a PNR 900 record, and the PNR record so generated Can only be returned to the travel agency Ai.

  Each travel agency must connect directly to a set of non-GDS content providers 50 if it needs to access non-GDS content, while travel management system 1 is only directly connected to GDS content provider 40. The 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 handles only standard travel content (GDS content) from the standard travel provider 40, while n travel service platforms (one platform 2.1 for each travel agency A1 to An. , 2.2, ... 2.i, 2.n).

  Thus, if a given travel agency Ai wants specific content from a non-standard travel provider 50 (e.g., museum ticketing), such content is uniquely implemented by the travel agency Ai (self -implement). Such a unique implementation is particularly costly and complex for travel agencies.

US Patent Application No. 2012259667

  Thus, an improved content management system, method, and method for dynamically and seamlessly distributing any type of content (both standard and non-standard content) from any content provider through a unique platform And there is a need for computer program products.

  To address these and other issues, a content management method as defined in the attached independent claim 1 and a content management system as defined in the appended claim 12 are provided. Preferred embodiments are defined in the dependent claims.

  Methods and systems according to various embodiments of the present invention allow a content management device to directly receive any type of content while eliminating the need for the client device to receive non-standard content separately. In addition, the use of common identifiers shared by standard and non-standard record data structures allows non-standard data containers to use them as if the data elements are stored in a unique record data structure. Allows you to manage access to data elements.

  Further advantages of the present invention will become apparent to those skilled in the art upon examination of the drawings and detailed description. All further advantages are intended to be incorporated herein.

  The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments of the present invention, together with an overview of the invention given above and a detailed description of the embodiments given below. It serves to explain the embodiment of the present invention.

It is a schematic diagram of the normal content management system by a prior art. 1 is a schematic diagram of a content management system according to a specific embodiment including a plurality of computing systems connected via a network. FIG. 1 is a schematic diagram of an exemplary operating environment including a content management system. FIG. 4 is a schematic diagram of the exemplary computing system of FIGS. 2 and 3. 6 is a flow diagram illustrating a process that may be performed to add new content to an extended record data structure. It is a schematic diagram of the structure of the internal application executed by the content management system according to a specific embodiment. It is the schematic which shows operation | movement of the internal application based on the technical object (Business model Object) type technical object (Technical object). 1 is a schematic diagram of a content management system showing an exemplary interaction between internal applications. FIG. FIG. 3 is a schematic diagram of an exemplary non-standard data container defined by a set of key values. FIG. 2 is a schematic diagram of an exemplary serialization format. FIG. 10 is a schematic diagram of the example non-standard data container of FIG. 9 in which types of information are included in the non-standard data container. FIG. 12 is a schematic diagram of an exemplary structure description file associated with the non-standard data container of FIG. 2 is a flow diagram of a process that may be performed for content access by an application. FIG. 3 is a schematic diagram of an exemplary content exchange unit. 2 is a flow diagram of a process that may be performed to send content to a client device. It is the schematic of XSLT transformation of a standard data container of C type. FIG. 17 is a schematic diagram of an XSLT transformation of a C-type non-standard data container that is the same as the standard data container of FIG. It is a schematic diagram of XSLT transformation of a standard data container of D type including a set of attributes. FIG. 19 is a schematic diagram of an XSLT transformation of an E-type non-standard data container having some attributes that are the same as those of the standard data container of FIG. FIG. 6 is a flow diagram of a process that may be performed to reorganize data elements. FIG. 6 is a schematic diagram of an extended record data structure according to a specific embodiment.

  The methods, systems, and computer program products according to embodiments of the present invention allow for the dynamic management of any type (standard and non-standard) content received from a content provider, whatever the content type. Even so, it may be possible to centrally store records related to such content. Content management system 100 may be based on a client / server architecture that enables receipt of client requests.

  Referring to FIG. 2, a content management system 100 is provided in which several user clients 7 can directly access any type of content provided by a set of content provider systems 4, 5 through a unique platform. Content handled by the content management system 100 is from a standard content provider system 4 that communicates with the content management system 100 according to a first type of message exchange format 14, such as a predefined standardized message exchange format, or It may be received from a non-standard content provider system 5 that communicates with the content management system 100 according to a second type of message exchange format 15.

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

  Content management system 100 may be dedicated to one or more specific service areas (eg, the travel field). One or more client devices 7 are each connected to the communication network 13 so that a user can initiate a service request session with the travel management system 100 and receive content from the travel management system 100 in response to the service request. There is a possibility.

  Embodiments of the invention may be implemented by a computing system that includes one or more networked computers or servers. A computing system may provide processing and database functions for content management.

  Each client device 7 may be a personal computing device, tablet computer, thin client terminal, smartphone, and / or other such computing device. Each client device 7 may host a web browser and / or custom application software (eg, a client system) and may include a client user interface.

  Each content provider system 4 or 5 may be connected to a communication network 13. Each content provider system 4 or 5 may host one or more websites and / or have a hosting service that hosts one or more websites.

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

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

  Further, the content management engine 3 can exchange messages with the non-standard provider 5 through the data exchange unit 11. The data exchange unit 11 is, for example, in response to a search, reservation, pricing, issuance, cancellation request from a user client 7 associated with a travel agency entity (e.g., a travel agency operator or a travel agency system) Messages defined by a data description language such as an extensible markup language (second message exchange format 15) may be used to communicate with non-standard content providers.

  A user requests a service request from the content management system 100 by entering information at the client device 7 through a user graphical interface generated at the client device 7 by an application running on the content management system 100 (eg, in the form of a web service). Can send. Information received from the user may be accumulated until the user sends a service request to the content management system 100 (eg, by performing a send operation).

  In response to a user request, the content management engine 3 requests and retrieves content from the content provider systems 4 and / or 5 according to the message exchange format 14 and / or 15, and records related to the retrieved content Can be stored in the extended record data structure 9. The extended record data structure 9 can be stored in a context and saved in one or more databases 8 in response to a save request or periodically. Alternatively, in certain embodiments, the expanded 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 relation to standard data and a non-standard for storing records in relation to non-standard data. Record data structure 91.

  A record includes a record identifier (also referred to as a “record locator”) associated with an associated data element. The record identifier can be any type and any format such as a number.

  The standard record data structure 90 stores records relating to a predefined type of content (called “standard” content) that has one or more attributes in a predefined set of attributes. It is static only because it is adapted. As used herein, the term “standard” refers to a standard having a predefined format and / or type corresponding to the format and / or type supported by the standard record data structure 90. Refers to content.

  If the received content includes only standard data elements, a record may be added to the standard record data structure 90 for the received content that includes related data elements. The record includes a record identifier associated with the data element.

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

  In addition, if the received content includes a non-standard data element and a standard record data structure 90, the standard record data structure 90 and the non-standard record for the received content that includes the associated data element Records can be added to the data structure 91. The two additional records for the received content in the standard record data structure 90 and the non-standard record data structure 91 are both assigned the same record identifier (hereinafter referred to as the “common record identifier”). There is a possibility. A common record identifier may be one or more standard data elements (standard content) in standard record data structure 90 and / or (nonstandard data elements in non-standard record data structure 91). Shared between one or more non-standard data containers.

  By using the same record identifier in both record data structures 90 and 91 to identify related standard and non-standard data elements, content management system 100 ensures that the two record data structures are unique record data structures. These two record data structures can be managed transparently as if they were formed.

  The content management engine 3 may have several applications related to different services. The content management engine 3 may receive a service request received from the client device 7 that may trigger the acquisition of content from the content provider system and storage of records associated with such received content in the extended data structure 9 Depending on the one or more applications can be run. The content management engine returns a response to the service request to the user client that uses the content recorded in the record data structure 9 based on the record stored in the expanded record data structure 9 regardless of the type of content. It can be further configured. In order to return a response to the client, the content management engine 3 can generate a constant representation of the content on the client device 7 whatever the content type contained in the record retrieved from the extended record data structure 9 A data exchange unit 11 may be used. Accordingly, the content management engine 3 functions as an application aggregator that provides 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 is an intermediary (e.g., a global distribution system (in the field of travel) (e.g. GDS)).

  FIG. 3 shows an exemplary operating environment 10 of such a management system 100 implemented with GDS 1. In such embodiments, standard content refers to GDS content that conforms to IATA constraints (such as flight, railroad content, etc.) provided by standard travel provider system 4, while non-standard content Can be any kind of non-GDS content (eg car rental) that does not meet the IATA constraints provided by non-standard travel provider system 5 or booked outside of GDS . The standard record data structure 90 is a standard PNR data structure (hereinafter referred to as "standard PNR") configured to store standard content, and PNR is an acronym for passenger name records On the other hand, the non-standard record data structure 91 (hereinafter also referred to as “non-standard PNR”) can be used to hard-code data mapping and compilation mechanisms by non-standard content. It is configured to dynamically record any type of non-standard content without the need to pre-define types and attributes. In general, the standard PNR 90 is from multiple transportation companies that use predefined data structures (types, attributes, families) and / or other travel services, including travel such as hotel and rental car reservations. It contains a complete set of data on the itinerary that includes a segment.

  The extended record data structure 9 forms an extended travel record (hereinafter also referred to as “ETR”) that can be manipulated seamlessly by the content management engine 3 regardless of the type of content each content record is associated with. To do.

  The client device 7 may be associated with a plurality of travel agency systems 70 that request services through the respective client interface 2. More broadly, the travel management system 100 can be used by the traveler's device 6 through the respective user interface 2 (or for example, the travel provider system 4 or 5, etc.) to exchange content stored in the extended travel record 9. It can also be accessed by different types of client devices that send different types of requests depending on the client / server approach.

  A standard travel provider system 4 may include multiple shipping company systems or traveler systems. Non-standard travel merchandise provider system 5 may include a car rental system, a museum reservation system, and the like. When implemented, the carrier system may include a computer reservation system (CRS) and / or billing system for each airline that enables GDS 1. The travel agency system 70 may be configured to book and pay for travel tickets and / or additional services provided by non-standard travel providers 5. Also, some standard travel provider systems 4 can be used either directly or to allow a validating carrier to sell seat tickets provided by an operating carrier. Can interact with each other either through GDS 1. At that time, the operating shipping company may charge the verification shipping company for the services provided.

  GDS 1 is a travel agency, verified shipping company, or other indirect seller that looks for segments available in one or more shipping company systems 4 through GDS 1, makes reservations, and makes additional Configured to facilitate communication between travel providers 4 and 5 and travel agency system 70 by allowing services to be found and booked (e.g. car rentals, museum tickets, etc.) obtain.

  Each travel agency system 70 may include a web server that provides a publicly accessible website. The website may be configured to provide access to travel planning features, such as the ability to find travel products that meet the travel requirements. For this purpose, travel agency system 70 provides GDS 1, travel providers 4 and 5, and one or more databases hosted by travel agency system 70 to allow travelers access. Can do. In an alternative embodiment of the invention, the travel agency system 70 may be a proprietary system that restricts access to a travel service provider or travel agency, in which case the access is private. May be provided through a website or other application.

  A traveler or travel agency uses the travel agency system 70 to generate a travel proposal that satisfies a travel request received from the traveler using a specific travel application (e.g., a travel planning application). And / or can be searched.

  The traveler's device 6 may be directly connected to the travel management system 100 through a public or private network 13 (eg, the Internet). Traveler device 6 may be any suitable computing system configured to communicate with travel management system 100 via network 13. For example, the traveler's device 6 includes a desktop, laptop, or tablet computer, smartphone, or any other computing device that allows travelers to find and book travel services over the network 20 obtain. In one embodiment of the present invention, a traveler device 6 communicates with a web service application hosted by the content management engine 3 of the travel management system 100 to send a trip request in response to the web service application. Can be included.

  Alternatively, traveler device 6 may include a web browser application that communicates with a web service application hosted by travel agency system 70. Further, the web service application may communicate with the travel management system 100 to send a travel request in response to the travel service application.

  Travel requests, for example, in connection with travel provided through GDS 1 or another GDS, obtain data related to available travel segments, generate travel proposals that satisfy travel requests, and Sent to book additional services (e.g. car rental, jet ski reservation, museum ticket reservation, etc.) corresponding to non-standard content provided by non-standard provider 5 there is a possibility.

  Referring now to FIG. 4, the GDS 1 of the operating environment 10, the travel management system 100, the travel provider systems 4 and 5, the travel agency system 70, and the traveler's device 6 are collectively referred to as a computer, such as the computer 30. It may be implemented with one or more computing devices or systems. The computer 30 may include a processor 32, memory 34, mass storage memory device 36, input / output (I / O) interface 38, and human machine interface (HMI) 40. Computer 30 may also be operatively coupled to one or more external resources 42 via network 22 and / or I / O interface 38. External resources may include, but are not limited to, servers, databases, mass storage devices, peripheral devices, cloud-based network services, or any other suitable computing resource that may be used by computer 30.

  Processor 32 is a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device that manipulates signals (analog or digital) based on operating instructions stored in memory 34 One or more devices selected from state machines, logic circuits, analog circuits, digital circuits, or any other device. Memory 34 can be read-only memory (ROM), random access memory (RAM), volatile memory, nonvolatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or information May include a single memory device or multiple memory devices including, but not limited to, any other device capable of storing Mass storage memory device 36 may include a data storage device such as a hard drive, optical drive, tape drive, non-volatile solid state device, or any other device capable of storing information. Database 44 may reside in mass storage memory device 36 and may be used to collect and organize data used by the various systems and modules described herein.

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

  The I / O interface 38 may provide a machine interface that operably couples the processor 32 to the network 22 and / or other devices and systems such as external resources 42. Thereby, the application 48 works in cooperation with the network 22 and / or external resources 42 by communicating via the I / O interface 38 to provide various features, functions, applications, Processes and / or modules may be provided. Application 48 may also have program code executed by one or more external resources 42, or functions and / or signals otherwise provided by other systems or network components external to computer 30. There is a possibility to rely on. Furthermore, given that almost unlimited hardware and software configurations are possible, one of ordinary skill in the art will recognize that embodiments of the present invention may be located outside of computer 30, multiple computers or other external resources. It will be understood that it may include applications provided by computing resources (hardware and software) distributed over 42 or provided as a service over a network 22, such as a cloud computing service.

  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 audio and visual indicators that can provide information to the user. The HMI 40 also accepts commands or input from the user, and input devices and control devices such as alphanumeric keyboards, pointing devices, keypads, push buttons, control knobs, microphones, etc. that can send input to the processor 32 May be included.

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

  Different travel agencies connected to the travel management system 100 through each travel agency system 70, therefore, no matter what the type of content (standard airline content, taxis, entertainment tickets, etc.) Any type of content provided by the travel provider system (4, 5) can be accessed directly through a unique platform. Thus, the travel management system 100 not only provides standard content that conforms to the standard PNR data structure 90, but also any new type of content (i.e. taxi courses, theater tickets, concerts, delicious food, etc.). It offers the possibility to remember while eliminating the need for travel agencies to book such non-standard content outside the GDS system, such as via phone or the internet.

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

  Thus, an extended trip record 9 with two elements is accessed as if the records held in ETR 9 form a standard record data structure with standard PNR 90 and non-standard PNR 91. Structured content of any travel provider system 4 or 5 that may be managed (the content may correspond to goods that are booked outside of the GDS, for example) Form an expression.

  Standard data elements (e.g. goods) in standard PNR 90 may be certified as optional or mandatory according to the standard layout and format implemented by GDS 1 to comply with the IATA standard. Associated with a set of attributes.

  The data held in the extended trip record 9 may be classified into multiple strains, each strain containing several data element types, for example, the five strains shown in Table 1. . ETR 9 is adapted to support any number of new data element types and lineages.

The content management engine 3 is configured to manage heterogeneous content in ETR 9, which may include:
-Add new data elements from any travel provider system 4 or 5 to the extended travel record 9, whatever the type of content, for example, upon request from the travel agency system 70
-Modify data elements in the extended travel record 9 (for example, by changing the start date of the “museum” product corresponding to the museum's two-entry advance reservation)
-Data from the extended trip record 9 (for example, by deleting a reservation for this item from the extended trip record if the user decides to delete the item "Museum" from the user's trip to New York) Deleting an element
-Obtaining data elements from the extended travel record 9 (for example, by retrieving all structured attributes of the "museum" product of 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 different types of content held in the extended travel record 9 transparently to the user client. The extended trip record 9 is more flexible and is adapted to any kind of new content (taxi, subway, bus, museum ticketing, etc.) whatever the attributes associated with the new content.

Standard PNR 90 is organized according to the IATA standard. A given set of data elements is sent from a standard travel provider system 4 to a content management engine 3 through a message in the first message exchange format 14 in an application flow (e.g. a booking management flow) associated with a given service When done, the following steps may be performed by the content management engine 3.
i. Data can be extracted by the content management engine 3 from incoming messages sent by the standard travel provider system 4
ii. A record may be added to the standard PNR 90, and the record includes a record identifier associated with the data element corresponding to the data (content data) extracted by the content management engine 3.

  Thus, the obtained data can be used to construct another message that will be sent to the next application in the application flow.

  Step i. Can be executed by a given internal application of an application flow while step ii. Can be triggered by another application of the flow when the application flow includes a set of continuous internal applications .

  Data added to the standard PNR 90 can only have a limited number of predefined attributes and must meet one or more predefined types and formats (standardized attributes). I must.

  Non-standard PNR 91 is not compliant with standard rules and traditional constraints (IATA content definition, TTY messages, IATA messages). However, non-standard content is part of the extended travel record 9 and can be seamlessly and transparently accessed by applications executed by the content management engine 3.

  Thus, the extended travel record 9 can be used for any kind of standard content (e.g. GDS content such as flights, hotels, cars, cruising, insurance, ferries, etc.) and non-standard content (bus / taxi / restaurant / Others etc.) can be stored in a structured manner in a universal format.

  In order to dynamically manage any kind of content, the content management engine 3 can convert received content containing non-standard data elements sent from the non-standard content provider system 5 to the travel management system 100. In response, it is configured to generate a non-standard data container. A non-standard data container can dynamically adapt to the format of the internal application of the content management system that receives the data elements due to the self-serialization characteristics of the non-standard data container. Non-standard data containers use the non-standard data container's self-serialization characteristics when the receiving internal application is an application flow application that includes a set of chained applications (internal applications). The non-standard data container can dynamically adapt to the format of each internal application being transmitted.

  More specifically, when the travel management system 100 connects 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 are: Stored in such non-standard data containers allocated to non-standard content types. A record can then be added to the non-standard record data structure 91 by an internal application (eg, in an application flow). A record may include a record identifier and a non-standard data container having a non-standard content type. A non-standard data container may contain a list of attributes, each attribute represented by a key and value. Each attribute may itself contain a list of subordinate attributes, each represented by a key and value (as with subordinate attributes etc.). Each attribute key is associated with a name and type. A non-standard data container will self-implement the non-standard data container itself, whatever the structure that the non-standard data container represents or the data it contains For any read-only or read / write access (i.e., get or set) of any value of any attribute that is configured in the non-standard data container, a non-standard data container is It allows such access through methods without having to implement getter / setter methods by hard coding, without depending on the key name or key type.

  Thus, a non-standard data container can be used to generate a new record with non-standard PNR 91 whatever the content type. Such a record may be for any kind of content management operation, e.g. running a travel application, generating a display of the result of a service request to the client device 7, or an external device (e.g. a travel provider system or Can be transparently accessed by the content management engine 3 to send content to the travel device.

  Referring now to FIG. 5, a flow diagram illustrating a process for generating a new record with a travel record 9 that is augmented in response to content received from one or more travel provider systems is shown.

  In block 501, the content management engine 3 retrieves content from one or more travel providers 4, 5 according to a message exchange format 14 and / or 15 in response to a service request from a client device 7, such as a travel agency system, for example. Can be received.

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

  The data elements may include standard data elements (eg, flight products) and / or non-standard data elements (eg, taxi products).

  Standard data elements (eg, GDS content) may be received according to a first message exchange format 14 such as TTY.

  Non-standard data elements may be received by the data exchange unit 11 in the form of messages defined by a markup description language such as XML according to the second message exchange format 15. The following description is made with reference to an XML message (also referred to as an XML document or file) for mutual exchange of data between the travel management system 100 and an external system. A data exchange message may include a structure description file that describes the structure of the message and the type and format of the data contained in the message. For example, for XML type data exchange messages, the XML XSD schema can be used as a structure description file that gives a representation of the structure of the attributes of the XML message.

  At block 502, for each data element received for 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 standard content (e.g., a flight product), at block 503, the content management engine 3 determines that the data element type (e.g., flight type) Record R is generated with a standard PNR (90) for standard content (eg, flight merchandise). A standard data container may be a static container configured for a predefined type of data element (standard data element). At block 505, record R may be assigned a record identifier I and may be associated with a standard data container. Records may be stored in a temporary context and / or at least one database 8.

  If the data element corresponds to non-standard content (e.g. taxi merchandise), at block 505 the content management engine 3 uses a non-standard data container (hereinafter also referred to as "non-standard container"). And record R with non-standard PNR (91) for non-standard content (for example, taxi goods). Step 505 may be triggered by one internal application of the application flow. The internal application that triggers the generation of records in the ETR may be different from the internal application that receives non-standard data elements from the data exchange unit 11. For example, the first internal application A1 may receive a non-standard data element in the format F1 of the application A1, and the non-standard data element is in the format of the application An. It may be sent to a series of other internal applications until it arrives at the internal application An on Fn, and finally the application An will receive a non-standard record data structure 91 (non-standard data with format Fn Trigger record generation in a container). Non-standard data containers can be allocated to data element types (eg, taxi type).

  Non-standard data containers are adapted to contain any kind of data element (non-standard data element). At block 506, record R may be assigned the same record identifier I and may be associated with a non-standard data container. Records may be stored in a temporary context and / or at least one database.

  In one embodiment, the non-standard data container generated at block 506 may be further assigned 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 data elements that should not be sent to the client device 7.

  Thus, a unique record identifier I is generated with standard PNR 90 and non-standard PNR 91 for all standard and non-standard data elements (related data elements) corresponding to common content Can be done. Thus, this common record identifier can be shared to manipulate records corresponding to disparate data elements as if the disparate data elements are held in a unique record data structure. For example, the record identifier I can be used by the content management engine 3 to allow an application to read / write non-standard data elements whatever the type of data.

In a simplified example, the extended travel record 9 may include, for example, several records that are assigned a common record identifier ID1, which is common to the following data elements: Associated with
-Type 1 standard data element D1
-Type 2 standard data element D2
-Type 3 standard data element D3
-Tagged type 4 non-standard data element D4
-Type 5 non-standard data element D5
-Tagged type 6 non-standard data element D6

  Records relating to data elements D1, D2, D3 are held in a standard record data structure 90 in association with record identifier ID1.

  Records relating to data elements D4, D5, D6 are held in a non-standard record data structure 91 (in a non-standard data container) in association with record identifier ID1.

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

  Non-standard data containers can be created whatever the type, attributes, and format of non-standard data elements. Each attribute may itself contain several sub-attributes.

  Therefore, the content management engine 3 dynamically generates a new type of content with the extended travel record (9), using a non-standard data container, whatever the type of content.

  A non-standard data container can be a diverse data container that is not hard-coded into the code for a given element, unlike a standard container. In contrast, the form that non-standard data containers must take can be dynamically defined.

  Non-standard data containers can still have self-serialization / deserialization properties.

  In a particular embodiment, the non-standard data container facilitates the incorporation of new content into the extended travel record 9 and the business object model (Business Object Model) of the internal application that operates that non-standard data container. Model) 21 may be a technical object.

  FIG. 6 schematically shows the structure of the internal application of the content management engine 3 according to a specific embodiment of the present invention in which the non-standard data container is the business object model 21. The internal application can be a stand-alone application or an application in a series of applications (forming an associated application).

Internal applications include:
-Structured interface 2
-Business object model 21
-Business layer 22

  The structured interface 2 represents how applications communicate with each other. A structured interface can carry functional data to be processed by an application. Those functional data may be mapped to a business object model 21 that is used by the business layer 22 to perform and operate validation operations. The verification operation corresponds to a functional check performed by the business layer 22 on the data in addition to the grammatical check. Data elements can be inserted into the expanded record data structure 9 in a structured manner after validation.

  As a result, the modification of the extended PNR 9 data structure may involve modification of the application's business object model 21 and modification of the structured interface of the application. In addition, to benefit from data structure modifications, other possible related applications may also adapt their application's business object model 21, their structured interface 2, and other modules' It may be necessary to incorporate a new version of the data model into the interface.

  Various embodiments of the present invention allow the costs associated with such modifications to be reduced by using a non-standard data container model.

  A travel service application running on the content management engine 3 may operate according to the diagram of FIG. BOM 21 represents a business object model 21 used to represent an internal data model used by an application.

  The service 210 is any structured (such as XML or Edifact message) received by the travel management system 100 from a client device 7, a non-standard travel provider 5, or a traveler device 6 that can be targeted by the application. Represents a message.

  The context server 211 represents the storage (also called “context”) of the context of data used by the application during asynchronous interactions with other applications.

  Data from the context can be stored in the database 8 on demand, periodically, or according to specific conditions.

FIG. 8 illustrates the interaction between a series of applications A1 to An in the context management engine 3 according to a specific embodiment. When travel management system 100 is operated in a distributed architecture, a series of internal applications A1 to An that are responsible for the process may call each other, which means that some applications of the architecture of FIG. There may be several replicas to the server 30 (also referred to as the backend server), and each application server 30 is associated with a respective series of applications Ai. At each step in the sequence of processes, in the usual way, the data carried from the first backend server 30 for application A1 to the last server 30 for application An is server 30 server in the middle of the process. It is converted, encoded and decoded in different ways before going to 30. Each back-end server 30 further decrypts the arriving data element and validates the data for the dedicated process of that back-end server 30 before accessing the data element. The data is then encoded for transmission to the next series of applications A _{i + 1} . In addition, the business object model 21 may be involved in the process of filling information into the structured interface 2 or retrieving information from the structured interface 2, for writing / reading data May be used. In the usual approach, writing / reading data to / from the structured interface 2 and centralized record repository requires manually coded components. Thus, a single change to the data model can be costly. Furthermore, in general, the data elements that an application is operating on have many functions so that each application can be required to verify (validate) that the data being operated on is in a suitable format that meets industry constraints. Have some constraints.

  As a result, the usual approach is that each time a data element needs to be modified in such a series of applications, each process must send new data to the next process, so that All steps of the process can be affected as new data must be decoded, verified and encoded. Furthermore, when new content is to be added to an existing application, each process must also send the new content to the next process, each series of processes decrypting the new element, Must be verified and encoded.

  The invention according to certain embodiments improves the situation by using the self-serialization property of BOM type non-standard data containers.

  In particular, a non-standard data container may be generated by a series of first applications A1 in response to receiving data elements D1, D2, and D3 from a non-standard content provider 5. Such non-standard content does not include data types and attributes that conform to the standard structure of PNR 90 and therefore cannot be stored as is in standard PNR 90. Non-standard content can take various forms and be associated with 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 (eg Protocol Buffers) of the first internal application A1. The first application A1 then passes the non-standard container to the next series of applications using message M1 using the non-standard container's self-serialization / deserialization property. Message M1 may be a blob carrying self-serialization / deserialization information. Then, the second application A2 can extract a non-standard data container in the format F2 of the internal application A2. Similarly, the second application is non-standard for a series of other applications using messages M2, M3, etc. that carry self-serialization / deserialization information until application An triggers the generation of a record in ETR 9. A typical container can be sent.

  Therefore, by using a non-standard data container, a series of internal applications can add new data structures to ETR 9, update data structures, or change any code to send data elements. Not needed. Furthermore, there is no need to modify existing data structures. Data contained by non-standard data containers can be made available without having to extract that data and convert it from one format to another. Thus, intermediate / manually coded layers can be reduced.

  As shown in the example of FIG. 9, a non-standard data container 50 may be defined by a set of key values that describe a business object model that can be manipulated by an application. Each key (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”. A data container includes a complex structure and can be associated with any type of data. For example, one or more keys of a data container may be further associated with a reference 53 (referred to as “REF” in FIG. 9) that associates a given data container with a set of related data containers. For example, the data container specified by the key / value pair "phone / + 335551213" will have a reference ("REF") to the next data container, namely "mobile / + 336123456" and "home / + 335551213". Including.

  Non-standard data container 50 allows content management for any of the data elements contained in the non-standard data container, without having to create an accessor that allows such access. Forgive Engine 3. This guarantees flexibility and scalability.

  Furthermore, access to data elements contained in non-standard data containers can be performed by the content management engine 3 at any point in the processing of the application by using a query in a suitable query language such as Xpath.

  Non-standard data containers may be programmatically backward and forward compatible. From a programming perspective, no code changes are required to use the new version of the data element structure associated with non-standard data containers.

  Non-standard data containers are configured to support serialization / deserialization. In particular, serialization may be performed during generation and modification of one or more attributes of non-standard content to encode a data container in an extensible format, and deserialization is May be executed whenever it needs to read at least one attribute of non-standard content.

  In particular, the keys and values of a non-standard data container are stored in the state of a technical object (eg, BOM) that represents the non-standard data container and restores the data container to its original state. Can be serialized at any time by converting to a format (eg, binary representation) that can be reconstructed by a deserialization mechanism. Thus, a non-standard data container can be converted to any target format whatever the data contained in the data container. Serialization and deserialization mechanisms do not require hard coding. The serialization information can be incorporated into a library associated with the data container. Thus, the use of such a BOM natively provides a serialization mechanism that can be supported for any kind of structure defined by non-standard data container keys without the need for specific coding. . In certain exemplary embodiments, the non-standard data container representation format used to convert the state of the non-standard data container by the serialization / deserialization mechanism is, for example, in FIG. As shown, it may be based on XML, ASCII, JSON, binary format.

  Non-standard data container value validation may only be required when creating and modifying data elements represented by non-standard data container objects. Thus, no reading process is required to revalidate the data element associated with the key.

  By using a non-standard data container, information related to the type of content (eg, air, taxi, sports show, parking, city traffic, etc.) can be brought into the non-standard data container itself. The non-standard data container type can be stored directly as a key in the non-standard data container.

  In some embodiments, the validation mechanism in creating or modifying a given non-standard data container is a functional type stored as a key in a non-standard data element, rather than a C ++ type as usual May be based on (functional type).

  In certain embodiments, each type of non-standard data container has a structure description file (e.g., attribute layout, attribute dependency, attribute format, etc.) that describes the attribute structure of the data element. XSD).

  A structure description file (eg, XSD) further represents the interrelationship between the attributes and elements of a non-standard data container represented as a technical object (eg, an XML object). Within the XSD schema associated with a non-standard data container, the different keys / values of the non-standard data container and the supplemental constraints that apply to that non-standard data container form a set of XML tags. Can be described using. Structure description files can be used in the creation and modification of non-standard data containers. In addition, supplemental constraints can be applied to non-standard data containers using structure description files (eg, XSD).

  The structure description file associated with each non-standard data container can be used to validate the attributes of the non-standard data container in the creation or modification of the non-standard data container. The verification mechanism may include verifying whether the non-standard data element represented by the non-standard data container complies with the description of the data element that the content will be placed on. In certain embodiments, the verification mechanism may verify by using a structure description file associated with the non-standard data container that the data stored in the non-standard data container matches the target format. Can be implemented.

  The travel management system 100 may have a table for storing the data types of the non-standard data container corresponding to the structure description file associated with the non-standard data container. The table can be updated as the process runs.

  The content management engine 3 can be configured to add new data to the non-standard data container by updating a structure description file (eg, XSD) that describes the non-standard data container structure such as new attributes .

  A structure description file (eg, XSD) that defines a non-standard data container can be modified without the need to hard code changes and recompile the code. Thus, non-standard data container modifications are dynamic and are updated at runtime.

  FIG. 11 shows those exemplary non-standard data containers of FIG. 9 showing the respective types of exemplary non-standard data containers: phone type (PhoneType), address type (AddressType), GPS type (GPSType). It is the schematic of a simple data container. The type of information can be stored as an attribute in a non-standard data container. Such information can be used to obtain a structure description file associated with a non-standard data container.

  FIG. 12 shows an XSD description file for the example non-standard data container of FIG. 11 having different types (“PhoneType”, “AddressType”, “GPSType”).

  According to a particular embodiment, the content management engine 3 further publishes to the client device 7 by the travel management system 100 whatever the type of content that is returned to the client device 7 and the application held by the content management engine 3 A set of internal service interfaces 2 can be generated on a unique platform.

  The extended travel record 9 can be used by numerous applications. For example, the content management engine 3 can provide external content received from a standard travel provider system 4 (e.g., airline products) and external content received from any other travel provider system 5 (whatever the type of content, For example, it may include a set of applications (eg, travel applications) for delivering different types of travel services to the client device 7 based on non-air products. Such services may include, for example, shopping, reservations, pricing, insurance, refund services.

  Such service applications are systems connected to the travel management system 100 through the client device 7 (e.g., travel agencies) without having to adapt each application to the N types of data added to ETR 9 by hard coding. It can be executed in response to a service request from system 70).

  The result can be returned through the data exchange unit 11 using a response message in a given format, such as an XML message. Therefore, the internal service interface 2 generated by the travel management system (100) may be of the XML type.

  Generic elements with a unique kind (generic element type) are used to eliminate the need to recode and recompile each application to support any number of new kinds of non-standard data containers Can be done. A generic element is a mega data container configured to contain any kind of non-standard data container. A generic element can include an unlimited number of N non-standard data types, but can be considered a container of a unique type (hereinafter referred to as a “generic element type”) by all service applications.

  Thus, each application can instantiate generic elements so that a non-standard container can be manipulated seamlessly independent of the type of data elements contained in the data container. Thus, each application need not instantiate as many non-standard data containers as new data types.

  As a result, the addition of new content types to non-standard PNR 91 will not affect applications handled by Content Management Engine 3 to ensure backward compatibility (eg, by hard coding) Or no adaptation to applications handled by the content management engine 3 is required.

FIG. 13 is a flow diagram illustrating access by an application to a record in ETR 9 with a given record identifier I. For example, the record identifier I may include:
-Standard data element SD1 of type T1
-Standard data element SD2 of type T2
-T3 type non-standard data element NSD3 contained in non-standard data container
-T4 type non-standard data element NSD4 contained in non-standard data container

  At block 600, the record associated with record identifier I is obtained from ETR 9. Records can be associated with standard data elements (SD1, SD2) and non-standard data elements NSD3, NSD4 (non-standard data containers) with their respective types T1, T2, T3, T4 .

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

  In particular, for example, for each data element such as NSD3, if the data element is a non-standard data element (block 601), the non-standard data element of type T3 is converted to a non-standard type of T3 in block 602. Is converted to a generic element of a unique generic element type that contains a unique data element. A generic element as a mega data container may itself include a non-standard data container having a particular type. A generic element may be implemented as a technical object such as a BOM and may be based on the same technology as a non-standard data container.

  If the data element is a standard data element such as, for example, SD1 (block 603), the standard data element of type T1 may be converted to a nonstandard data container of the same type T1 at block 604. .

  In block 602, the non-standard data element so retrieved is then a generic element of a unique generic element type that includes a non-standard data element of type T1 that corresponds to the standard data element NSD1. Is converted to

  A generic element is a temporary state of a non-standard data element that allows an application to seamlessly manipulate standard and non-standard data elements regardless of their data element type. Form. Thus, an application can manipulate the data elements of ETR 9 as if they had a unique type without having to know the types of non-standard content.

  In block 605, if the application requires that one or more data elements be sent to the interface of the client device 7 that generates the service request, the application examines the contents of the generic element (introspect ), Access the data element type.

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

  Therefore, generic elements extract non-standard data element types, that is, every time a new type of content needs to be handled by the application (new content is added to ETR 9), Instead of defining types, each application can therefore instantiate a unique generic element that can support any new content type and attributes.

  Turning again to FIG. 3, the travel management system 100 allows any kind of content (standard and non-standard content) to be sent to any external device such as the travel agency system 70, the non-standard travel provider system 5, etc. It can be adapted to interact with client devices or with any other backend server in the same GDS through the internal interface 2.

  In a normal manner, the travel management system 100 converts data from a standard PNR into a PNR content format by implementing a hard-coded conversion to a standard format supported by the target client device interface. Can interact with other target client devices (eg, travel provider systems, travel agency systems) that have their own standards (target PNR content format). This requires an encoding mechanism in the travel management system 100 and a decoding / verification mechanism in the target device. Furthermore, each travel management system may have its own standard for the format of the PNR content (original PNR content format), and therefore the target device interface only supports such a format. Such transformation (encoding / decoding / verification) currently involves hard coding and recompilation in a costly static manner.

  The data exchange unit 11 enables reception or transmission of data exchange messages from external client devices in accordance with the second data exchange format 15 for exchanging any kind 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 has a structure description file that defines the attributes (attribute layout and format) of the data element such as XSD for the XML message, and a set of attributes corresponding to the attribute value. Value.

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

Data exchange unit 11 may be used to exchange data elements with external client devices such as non-standard travel providers 5, travel agency systems, or other non-GDS systems. In particular, the data exchange unit 11
-Receive non-standard data elements from client devices, or
-Can be used to send data elements from ETR 9 to client devices.

  The data exchange unit 11 is defined by a structure conversion engine 111 such as an XSLT engine for converting a structure description file such as XSD to the target structure description file XSD2 and a description language such as XML. And a data exchange message generator 112 for transmitting data in the form of messages. The XSLT engine uses a predefined local mapping rule 113 (for example, XSLT stylesheet) that defines transformation rules for transforming the original structure description file XSD1 in the receive mode, or the original structure description file XSD1 in the send mode. A pre-defined client mapping rule 117 (eg, an XSLT stylesheet) that defines a transformation rule for transformation may be used.

  The travel management system 100 has one or more predefined local structure description files 115 associated with different content types and corresponding to the structure description files that are to be applied locally by the travel management system 100. Or it can be dynamically loaded at runtime.

  In the reception mode, the data exchange unit 11 may receive a data exchange message XML1 that arrives from an external client device 7 that conforms to the original structure description file XSD1 defined by the external client device 7. The incoming message XML1 contains non-standard data elements of a given kind Ti.

  Each time such an incoming data exchange message XML1 containing a non-standard data element is received by the travel management system 100, the transformation engine 111 performs a local mapping associated with the type of data element contained in the data exchange message XML1. Rule 113 may be used to convert the incoming message structure description file XSD1 to the target structure description file XSD2. The target structure description file XSD2 is then added to the set of local structure description files 115.

  In addition, the data exchange unit 11 applies a validation mechanism to the incoming message XML1 before converting the original structure description file XSD1 to the target structure description file XSD2, and performs some related operations on the attributes of the structure description file XSD1. A condition (eg, the presence of a mandatory attribute) can be verified.

  Then, a Ti-type non-standard data container can be generated by mapping the fields of the data exchange message XML1 to the non-standard data container primitive. The non-standard data container is then added to ETR 9 in conjunction with the target structure description file (XSD2) stored in 115 for the Ti type, as described in connection with FIG. Any updates or additions of new content in ETR 9 can be made at runtime.

  Thus, the use of the data exchange unit 11 represents an element that will be added / modified to any incoming data exchange message received from the content provider system 4, 5 without requiring any code changes. Allows dynamic conversion to some non-standard data container object.

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

  In transmission mode, the data exchange unit 11 receives as input non-standard data containers (including Ti-type non-standard data elements or standard data elements already converted to non-standard data containers) To do.

  Ti-type non-standard data containers are structure description files (original structure, including descriptions of non-standard data container attributes (keys), attribute layouts, and attribute formats, such as XSD files (115). Associated with a description file). Non-standard data containers are also associated with key values that correspond to attribute values.

  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 ETR 9, the conversion engine 111 is associated with the non-standard data element type. By using the client mapping rules 117, the structure description file XSD3 associated with the non-standard data container of the local structure description file 115 may be converted to the target structure description file XSD4. The client mapping rule 117 defines a conversion rule to the target client device 7 interface format for display on the target client device 7 graphical user interface (GUI), for example.

  If the data element to be sent to the client device 7 is a Ti-type standard data element (e.g., a GDS element), the standard data element is the same type of non-standard using the data container converter 12 May have already been converted to a typical data container. The standard data element can then be transmitted to the data conversion unit 11 in the form of a non-standard data container for transmission to the target client device 7.

  FIG. 15 shows a flow chart for sending a Ti-type data element to a target interface (graphical user interface GUI) of a client device 7 according to a specific embodiment.

  If the data element is a standard data element (block 700), the Ti standard data element is the same as the non-standard data container of Ti type in block 701 (similar to block 604 in FIG. 13). Can be converted to The standard data elements are then processed in block 703 in the form of a Ti type non-standard data container 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 Ti-type non-standard data container associated with the structure description file XSD1 and the key value Vi (block 700), at block 703, a Ti-type non-standard Data elements are processed directly.

  At block 703, the original structure description file XSD1 associated with the non-standard data container is obtained.

  In block 704, the original structure description file XSD1 is analyzed by using the mapping engine 110 (for example, XSLT engine) to parse the original structure description file XSD1 using the mapping rule 113 (for example, XSLT stylesheet). The converted field is converted into the target structure description file XSD2 and converted into the target structure description file XSD2. The mapping rule 113 is defined according to the target interface format of the client device 7.

  At block 705, an XML message containing data elements 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 sent over the network 13 to the target interface of the client device 7. The target interface can be dynamically and transparently adapted in response to an XML message response.

  In addition, the external client device 7 extracts the data element contained in the XML message and extracts that data element without the need to apply decryption and complex validation mechanisms to the data, whatever the data type and target interface format. The external client device 7 can store it according to its own standard.

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

  In one embodiment, the data exchange unit 11 is software that is manually coded as little as possible, whatever the content type (standard, non-standard, mixed content) client device 7 (e.g., travel agency It can be used by the content management engine 3 to dynamically generate a consistent representation of the results of requests to the system) interface.

  The service application can directly use the same kind of data structure to store data at the interface 2. This eliminates the need to exchange additional format data structures between the interface layer and the BOM layer. In addition, this reduces the overhead between the data stored in the extended travel record and the data representation of the service interface exposed to the client device 7 (e.g. the travel agency system) through a unique platform. Enable.

  In particular, the method of FIG. 13 ensures that the representation from the client device 7 (e.g., the travel agency system 70) is whatever the content type (standard content or non-standard content) while ensuring that the representation is homogeneous. It can be applied to generate a representation of the result in response to a service request and to generate a representation of such a representation on a user graphical interface associated with the service at the client device interface.

  When non-standard content and / or record identifiers related to standard content are added to the extended record data structure9, the service application can dynamically represent the record regardless of the new type. Adapted to produce.

  The application of the content management engine 3 corresponding to the service request can access a record corresponding to the result obtained from the ETR according to the access method of FIG. 12 using a general-purpose element.

  Implementation of access to a non-standard data container (50) based on a unique generic element whatever the type of content that will be returned to the client device 7 is a non-standard content provider system 5 Allows to support any kind of content from. Therefore, the application of the content management engine 3 is independent of the content type.

  To return the results to the travel agency system 70 interface, the application may examine the contents of the generic element and access a non-standard data container (block 605 of FIG. 6). Non-standard data containers so accessed can be returned according to the method of FIG.

  Therefore, the content management engine 3 has a unique response independent of the type of product that has to be manipulated (e.g. traditional GDS aviation product (flight) / GDS car rental / non-GDS taxi / non-GDS restaurant ...) Is adapted to provide all client devices 7 with a unique platform that includes a set of interfaces for each service (eg, travel service) that represents.

  In order to facilitate the integration of new content into the application, the internal service interface 2 associated with the application may have a set of common attributes for each content lineage. This allows new elements of the existing content lineage to benefit from all the display functions available for the lineage.

  In particular, the data structure underlying the non-standard data container 50 may share a common format within a particular element category. For example, the format description file XSDi used to represent an airline segment type data element is whether the data element was reserved through the travel management system (100) or through another external reservation system. It can be the same regardless. The data element may also share a set of common data with elements from another category (eg, a mailing category).

  In particular, the conversion engine 111 is ETR 9 for both a non-standard data element and a standard data element for a given record identifier I1, and the non-standard data element and the standard data element are If the same general type (for example, “Hotel”), the structure description file XSD1 related to the non-standard data element and the structure description file XSD2 related to the standard data element are commonly used to conform to the target interface. Can be defined such that the same representation can be generated for both data elements at the target interface of the external client device 7 (eg, a travel agency system) by mapping to the same type of structure description file.

  For example, as shown in FIG. 16, standard data elements of type C are first converted to non-standard containers associated with the same type C (block 701 in FIG. 15), and then represented (XSD2) Is generated at the client device for the C type using the conversion engine 111 and the mapping rules 117 (style sheets) defined for the C type at the client device. As shown in the example of FIG. 17, the same representation (XSD2) is used for non-standard containers of type C.

  Also, the transformation rule 117 maps the same type attribute of any data element to the same sub-representation including the attribute (in the target description file) whatever the content type (non-standard or standard) Can be defined as

  In the example shown in Figure 18, a standard container of type D containing a set of attributes A1, A2, A3, A4 (defined in the original structure description file XSD1) is first associated with the same D type. Is converted to a non-standard container (block 701 in FIG. 15), and then the representation XSD2 (target structure description file) is generated on the client device for type D using the transformation engine 111, and the representation XSD2 is The expression attributes {E1, E2, E3, E4} corresponding to the attributes {A1, A2, A3, A4} are included. As shown in the example of FIG. 19, the same representation {E2, E3} applies a set of attributes {C1, A2, A3 by applying the same mapping rules 117 for similar attributes in the original structure description file XSD. , C4} can be generated for the attributes A2, A3 of another C-type non-standard container. Accordingly, the mapping engine 11 generates the expression XSD3 = {F1, E2, E3, F4, F5} having the same expressions E2 and E3 for the attributes A2 and A3, respectively.

  Therefore, the content management engine 3 can generate a unique response for each application that can be generated independently of the type of content that must be manipulated (e.g., GDS flight products, GDS car rentals, non-GDS taxis, non-GDS restaurants, etc.). A unique platform including a set of interfaces is provided to all client devices 7 (eg, associated with a travel agency system).

  Accordingly, service applications can directly use disparate data structures to store data at the interface. This eliminates the need to exchange additional format data structures between the interface layer and the BOM layer. In addition, this reduces the overhead between the data stored in the extended trip record 9 and the data representation of the service interface 2 exposed to the client device 7 (e.g. a travel agency system) through a unique platform. Make it possible to do.

  Therefore, the data exchange unit 11 is dynamically coded software with as little manual coding as possible, regardless of the type of content (standard, non-standard, mixed content). Make it possible.

  In particular, the data exchange message used to return the result to the client device 7 has a format close to the internal structure (e.g. XML), which is a generic element used to define the element itself Inherited from a structured description file (eg, XSD).

  Thus, the content management system 100 has a unique response independent of the type of product that must be manipulated (e.g., traditional GDS aviation products (flights) / GDS car rental / non-GDS taxis / non-GDS restaurants ...) Provides a set of interfaces for each travel service that represents

  FIG. 20 shows a flow diagram of a content organization method according to a specific embodiment. The content associated with the ETR 9 common record identifier includes a set of data elements associated with the same trip. Depending on the application that requires a specific record identifier in ETR 9, the application is organized according to predefined reorganization criteria when the different data elements associated with a given record locator are accessed by the application. (E.g., ordered).

  Content reorganization methods can be implemented to reorganize data elements according to reorganization criteria predefined by the application, such as chronological order, ranking criteria, and the like. The reorganization method may merge standard and non-standard data elements into an excerpt ranking model based on excerpt elements. The excerpt elements can be used to reorder the data elements according to the reorganization criteria. Thus, the application can return merged data elements ordered according to the target interface constraints. This may, for example, result in an aggregated itinerary document where PNR segments and expanded elements (non-standard content) can be merged in the same view.

  In particular, for each data element, if the data element is a non-standard data element (block 801), the Ti-type non-standard data element is an attribute of the Ti-type non-standard data element in block 802. Is converted to a unique type of excerpt element containing a subset of. Non-standard data container attributes are filtered according to filtering criteria generated based on the reorganization criteria (eg, in chronological order, the filtering criteria selects the date attribute). An excerpt element may be implemented as a technical object such as a BOM and may be based on the same technology as a non-standard data container and / or generic element. Note that both generic and excerpt elements allow excerpts of data element types.

  If the data element is a Ti-type standard data element (block 803), the data element is converted to the same Ti-type non-standard data container in block 804 (similar to step 604 in FIG. 13). Can be done.

  At block 805, the attributes of the non-standard data element so obtained are filtered according to the filtering criteria.

  In block 806, the non-standard data element obtained in step 804 is an excerpt that includes a filtered set of attributes of a Ti-type non-standard data element that corresponds to a Ti-type standard data element. Converted to an element.

  Similar to generic elements, the resulting excerpt elements form a temporary state for non-standard data elements that allow excerpts of data container types. In addition, the excerpt elements allow the application to globally manipulate the attributes of the filtered data elements, especially for those filtered elements, by examining the contents of the excerpt model, whatever the data element type. Organize data element attributes according to reorganization criteria.

  In the field of travel, a standard PNR 90 can be stored in a storage area shared among multiple systems. The standard data elements held in standard PNR 90 can be of different types, and each element can have its own serialization format. Standard data elements may share the same record identifier if the data elements are related (eg, common to the same passenger or itinerary).

  Similarly, a non-standard PNR 91 data element may share the same record identifier as a non-standard PNR 91 or another data element of a standard PNR when the data element is related. The non-standard PNR 91 can be stored in the same storage area as the standard PNR. Alternatively, standard PNR 90 and non-standard PNR 91 can be stored in different storage areas. The two areas may be managed by a global management mechanism to allow common data synchronization. A global management mechanism links non-standard PNR 91 dedicated storage to standard PNR 90 dedicated other storage for each query that needs to manipulate the entire extended travel record 9 Can be implemented.

  Even though ETR 9 is split into two record data structures 90 and 91, ETR 9 is globally based on common record identifiers, supplemental container data, and / or record data structure information that identifies related data elements. Can be managed.

  The supplemental data container data can include control information (eg, creation date, last modification date, etc.) for each data container. In the usual approach, such information is stored directly in the respective standard data container in association with record identifier 0 and is used for managing the standard PNR (e.g., periodically changing the standard PNR). To be removed). However, such an approach does not allow optimized management of the two record data structures 90 and 91.

  FIG. 21 represents the structure of ETR 9 according to certain embodiments. 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 includes the creation date and time of the data container, the last of the data container Further includes supplemental data structures 92 (also called `` centralized management data structures '' or `` centralized management areas '') for managing supplemental container data associated with each data container generated by ETR 9, such as modification date and time obtain. Information held in the supplemental data structure 92 can be used to manage both areas in a synchronized manner. Each entry in the supplemental data structure 92 may share the same record identifier as the data container generated in ETR 9. Further, each record in the supplemental data structure 92 may be associated with a set of supplemental container data associated with a data container held in the ETR 9 (having the same record identifier). The supplemental data structure 92 can be filled with data container information contained in the standard record data structure 90 and the non-standard record data structure 91.

  In some embodiments, each entry in the supplemental data structure 92 may include a set of supplemental attributes associated with data containers that share the same record identifier in the extended record data structure (9). Each entry may include a supplemental data container for storing a set of supplemental container data associated with ETR 9 records that share the same record identifier. The set of supplemental container data may include control attributes that represent control information related to ETR 9 records that share the same record identifier, such as a date prior to the removal of the record.

  In some embodiments, data container information associated with all records in a given record data structure 90 or 91 is also referred to as a dedicated record (also referred to as a “container information record”) in this record data structure (90 or 91). ) And can be assigned a specific record identifier (eg, record identifier 0). The container information record of the standard record data structure 90 and / or the container information record of the non-standard record data structure 91 may be ETR at different time intervals, for example, periodically, in response to an inquiry, or alternatively Each time 9 is stored in one or more databases 8, it can be copied to the supplemental data structure 92.

  In addition, the supplemental data structure 92 includes standard record data structures and / or non-standards, such as version information that identifies the latest version of the standard record data structure 90 and non-standard record data structure 91 in the database. Record data structure information associated with a typical record data structure.

  The travel management system 100 determines the ETR 9 based on the data contained in the supplemental data structure 92 (supplementary container data information and / or standard record data structure information 90 and / or non-standard record data structure information 91). An ETR control unit 18 may be included.

  In one embodiment, the ETR control unit 18 uses the common record identifier, the supplemental container data held in the supplemental data structure 92, and / or the record data structure information to perform standard PNR 90 and non-standard A removal module 180 configured to periodically and periodically remove records from the PNR 91 with respect to common data may be included.

  In certain embodiments, the ETR control unit 18 provides access to handle simultaneous access to the same record identifiers of standard PNR 90 and non-standard PNR 91 based on data held in the supplemental data structure 92. A manager 181 may be included. In such an embodiment, the supplemental data structure may further carry version information identifying the latest version of the standard record data structure 90 and the non-standard record data structure 91 in the database 8. For example, each time ETR 9 is saved from the context to the database, the version information is updated with the supplemental data structure 92. Access manager 181 may be configured to manage access to ETR 9 based on the version information held in supplemental data structure 92.

  Program code embodying any of the embodiments of the invention described herein may be distributed individually or collectively as various different forms of program products. In particular, the program code may be distributed using computer readable media that may include computer readable storage media and communication media. Computer-readable storage media that are non-transitory in nature are volatile and non-volatile implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Removable and non-removable tangible media. Computer-readable storage media include RAM, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, or other solid-state memory technology, portable compact disk read-only memory ( CD-ROM), or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device, or can be used to store desired information and can be read by a computer Any other medium that may be further included. Communication media may embody computer readable instructions, data structures, or other program modules. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above media may also be included within the scope of computer readable media.

  The method described herein is a computer supplied to a processor of any type of computer to produce a machine having a processor that executes instructions for performing the functions / operations defined herein. It can be implemented by program instructions. These computer program instructions may also be stored on a computer readable medium that may direct the computer to function in a particular way. To that end, computer program instructions cause the execution of a sequence of operational steps, thereby causing the executed instructions to provide a process for performing the functions / operations defined herein. It can be loaded into a computer to generate a process to be performed.

  While embodiments of the invention have been shown by way of various example descriptions and these embodiments have been described in considerable detail, the appended claims are limited to such details or limited in any way This is not what the applicant intends to do. Additional advantages and modifications will be readily 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, although excerpt elements have been described with respect to reorganizing content, excerpt elements can be more widely used by internal applications to access content for different types of operations. The filtering rules applied to filter the attributes of the data container can vary depending on the intended operation.

1 Travel management system, GDS
2 Interface
3 Content management engine
4 Standard content provider system, standard travel provider system
5 Non-standard content provider system, non-standard travel provider system
6 Traveler devices
7 User client, client device
8 Database
9 Extended record data structure, extended travel record
10 Operating environment
11 Message exchange unit, mapping engine
12 Data container converter
13 Communication network
14 First message exchange format
15 Second message exchange format
18 ETR control unit
20 network
21 Business object model
22 Network, business object model
30 Travel Content Management Engine, Computer, Application Server
32 processor
34 memory
36 Mass storage memory devices
38 Input / Output (I / O) Interface
40 GDS content provider, standard travel provider, human machine interface
42 External resources
44 Database
46 Operating System
48 applications
50 non-GDS travel providers, data structures, non-standard data containers
51 keys
52 values
See page 53.
60-terminal consumer system
70 Travel agency, travel agency system
90 Standard record data structure
91 Non-standard record data structure
92 Supplementary data structures
100 Travel management system, content management system
111 Structural transformation engine
112 Data exchange message generator
113 Local mapping rules
115 Local structure description file
117 Client mapping rules
180 removal module
181 Access Manager
900 Passenger Name Record (PNR) Data Structure

Claims (12)

A method of managing content provided by one or more content providers (4, 5) in a content management system that includes an application aggregator (3) containing a set of applications and an extended record data structure (9). The expanded record data structure includes a standard record data structure (90) for storing records associated with a standard data element of a standard type defined in advance and the predefined standard. A non-standard record data structure (91) for storing a record associated with a non-standard data element having a non-standard type different from the general type, the method comprising one or more receiving the content including the standard data element and the non-standard data elements from the content provider (4, 5) in step (102) I, the content includes a set of related data elements of each type, and the step, for each data element,
-Generating a common record identifier in relation to an associated data element of the received content;
Generating a record for the data element in the standard record data structure (90) if the data element has a standard type, the record comprising the common record identifier and the data element; Including a data value corresponding to, and
-Generating a non-standard data container for the data element if the data element has a non-standard type, and generating a record for the data element in the non-standard record data structure (91). The record includes the common record identifier and a data value corresponding to the data element, and
The method of managing content further comprises managing access to records held in the extended record data structure (9) based on the common record identifier.   The method of claim 1, wherein the non-standard data container is a technical object that includes a set of keys and values, each key corresponding to an attribute of the data element.   The method of claim 2, wherein the non-standard data container includes a key that defines a type of the non-standard data container. The non-standard data container A method according to claim 2 which is a business object model.   The non-standard data container includes a self-serialization mechanism for serializing itself to the target format of the application, and the non-standard data container serializes the non-standard data container or 5. The method of claim 4, comprising a library that embeds serialization information for deserialization.   Providing applications with access to the records of the extended record data structure associated with a given kind of non-standard data element by creating a generic container that is assigned a unique generic kind The method of claim 1, wherein the generic container comprises the given type of non-standard data container.   By converting a standard data element into a non-standard data element and generating a generic container allocated the unique generic type that includes the non-standard data container resulting from the conversion, 7. The method of claim 6, comprising providing an application with access to a record in an extended record data structure associated with a given type of standard data element.   7. A method according to claim 5 or 6, wherein each application can access a non-standard data container type contained in a generic element by examining the contents of the non-standard data element.   9. The method according to claim 1, wherein the standard record data structure and the non-standard record data structure are stored in the same storage area in the content management system.   The method according to any one of claims 1 to 9, wherein the standard record data structure and the non-standard record data structure are stored in different storage areas in the content management system. The received content may be received by one application of a series of applications of the application aggregator (3), and each non-standard of the received content data elements such, is transmitted between the application of which is in the set of a series through a message that carries the self serialization information application, the non-standard in the extended record data structure (9) 11. A method according to any one of claims 1 to 10, wherein storage of a valid data container is triggered by one of the applications of the set of stretched applications. A content management system for managing content provided by one or more content providers (4, 5), including an application aggregator (3) containing a set of applications and an extended record data structure (9) The extended record data structure includes a standard record data structure (90) for storing records associated with a standard data element of a standard type defined in advance and the predefined record data structure The content management system (100) includes a non-standard record data structure (91) for storing records associated with non-standard data elements having a non-standard type different from the standard type. ,
Receiving (102) content comprising said standard data element and said non-standard data element from one or more content providers (4, 5), said content being of each type Receiving, including a set of related data elements, and for each data element,
-Generating a common record identifier in relation to an associated data element of the received content;
-Generating a record for the data element in the standard record data structure (90) when the data element has a standard type, the record comprising the common record identifier and the data element; Generating, including data values corresponding to
-Create a non-standard data container for the data element if the data element has a non-standard type, and generate a record for the data element in the non-standard record data structure (91) Wherein the record is configured to generate, including the common record identifier and a data value corresponding to the data element;
The content management system is further configured to manage access to the records held in the extended record data structure (9) based on the common record identifier.

Images