U.S. patent application number 16/724577 was filed with the patent office on 2020-12-03 for system and method of generating aggregated functional data.
The applicant listed for this patent is AMADEUS S.A.S.. Invention is credited to Tony BISEGNA, Pierre BRUN, Thomas CARPENTIER, Nicolas CLERC-RENAUD, Floriane FAUDET, Jean-Chafic HAYS, Fabien LE METAYER, Federica SPIRITI.
Application Number | 20200380425 16/724577 |
Document ID | / |
Family ID | 1000004593511 |
Filed Date | 2020-12-03 |
![](/patent/app/20200380425/US20200380425A1-20201203-D00000.png)
![](/patent/app/20200380425/US20200380425A1-20201203-D00001.png)
![](/patent/app/20200380425/US20200380425A1-20201203-D00002.png)
![](/patent/app/20200380425/US20200380425A1-20201203-D00003.png)
![](/patent/app/20200380425/US20200380425A1-20201203-D00004.png)
![](/patent/app/20200380425/US20200380425A1-20201203-D00005.png)
![](/patent/app/20200380425/US20200380425A1-20201203-D00006.png)
United States Patent
Application |
20200380425 |
Kind Code |
A1 |
BRUN; Pierre ; et
al. |
December 3, 2020 |
SYSTEM AND METHOD OF GENERATING AGGREGATED FUNCTIONAL DATA
Abstract
A method of aggregating and updating heterogeneous data objects
for a client subsystem includes: storing a set of data object
definitions, each defining a mapping between an aggregated data
object format and a plurality of supplier data object formats;
storing a set of update definitions, each defining a mapping
between an aggregated update operation and a plurality of supplier
update mechanisms; receiving a data object in a supplier data
object formats; selecting, based on the supplier data object format
of the received data object, a data object definitions and
generating an aggregated data object according to the selected
definition; presenting the generated aggregated data object to the
client subsystem; receiving an aggregated update operation from the
client subsystem for updating the aggregated data object; and
selecting, based on the received aggregated update operation, one
of the update definitions and initiating a supplier update
mechanism according to the selected update definition.
Inventors: |
BRUN; Pierre; (Valbonne,
FR) ; HAYS; Jean-Chafic; (Nice, FR) ; FAUDET;
Floriane; (La Colle sur Loup, FR) ; BISEGNA;
Tony; (Vallauris, FR) ; CARPENTIER; Thomas;
(Biot, FR) ; CLERC-RENAUD; Nicolas; (Biot, FR)
; LE METAYER; Fabien; (Cannes, FR) ; SPIRITI;
Federica; (Biot, FR) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
AMADEUS S.A.S. |
Biot |
|
FR |
|
|
Family ID: |
1000004593511 |
Appl. No.: |
16/724577 |
Filed: |
December 23, 2019 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 10/02 20130101;
G06F 16/22 20190101; G06F 16/252 20190101; G06Q 50/12 20130101;
G06F 16/2379 20190101 |
International
Class: |
G06Q 10/02 20060101
G06Q010/02; G06F 16/22 20060101 G06F016/22; G06F 16/23 20060101
G06F016/23; G06F 16/25 20060101 G06F016/25; G06Q 50/12 20060101
G06Q050/12 |
Foreign Application Data
Date |
Code |
Application Number |
May 29, 2019 |
FR |
1905718 |
Claims
1. A method of generating an aggregated functional data object for
a client subsystem from a set of supplier data objects having
different data object formats, comprising: storing the set of
supplier data objects according to their respective data object
formats, each supplier data object including a plurality of
elements; creating a further data object for linking selected
supplier data objects based on common ones of said elements shared
between the selected supplier data objects; and creating the
aggregated functional data object by merging and combining said
common ones of said elements with remaining ones of the plurality
of elements from the selected supplier data objects according to
said linking, for presentation to the client subsystem.
2. The method of claim 1, further comprising: receiving a request
from the client subsystem to modify one of the selected supplier
data objects and in response one of either creating, deleting or
modifying elements of said one of the supplier data objects;
updating the linking to reflect any modification of said common
ones of said elements; and creating a further aggregated functional
data object by merging and combining said common ones of said
elements with said remaining ones of the plurality of elements from
the selected supplier data objects, including the modified one of
the selected supplier data objects, according to the updated
linking, for presentation to the client subsystem.
3. The method of claim 1, wherein each of said supplier data
objects includes a distribution channel indicator indicative of its
data object format.
4. The method of claim 1, wherein each of said supplier data
objects includes a record identifier.
5. The method of claim 4, wherein each said record identifier is
maintained in said further data object upon creating the aggregated
functional data object.
6. The method of claim 1, wherein the data object formats
correspond to data acquired through at least one of either New
Distribution Capability (NDC) messaging and Global Distribution
System (GDS) messaging.
7. The method of claim 2, wherein creating elements of said one of
the supplier data objects comprises copying one or more common
elements from another one of the supplier data objects.
8. The method of claim 1, wherein the set of supplier data objects
and further data object use identical serialization.
9. The method of claim 6, wherein the aggregated functional object
is presented to the client subsystem using an Application
Programming Interface (API) according to a context defined by said
one of the data object formats.
10. A transaction processor server, comprising: a memory storing: a
set of supplier data objects stored according to respective data
object formats, each supplier data object including a plurality of
elements; and a processor interconnected with the memory, the
processor configured to: create a further data object for linking
selected supplier data objects based on common ones of said
elements shared between the selected supplier data objects; create
an aggregated functional data object by merging and combining said
common ones of said elements with remaining ones of the plurality
of elements from the selected supplier data objects according to
said linking; and present the aggregated functional data object to
a client subsystem.
11. The transaction processor server of claim 10, wherein the
processor is further configured to: receive a request from the
client subsystem to modify one of the selected supplier data
objects and in response one of either create, delete or modify
elements of said one of the supplier data objects; update the
linking to reflect any modification of said common ones of said
elements; create a further aggregated functional data object by
merging and combining said common ones of said elements with said
remaining ones of the plurality of elements from the selected
supplier data objects, including the modified one of the selected
supplier data objects, according to said linking; and present the
further aggregated functional data object to the client
subsystem.
12. The transaction processor server of claim 10, wherein each of
said supplier data objects includes a distribution channel
indicator indicative of its data object format.
13. The transaction processor server of claim 10, wherein each of
said supplier data objects includes a record identifier.
14. The transaction processor server of claim 13, wherein the
processor is further configured to maintain each said record
identifier in said further data object upon creating the aggregated
functional data object.
15. The transaction processor server of claim 10, wherein the data
object formats correspond to data acquired through at least one of
either New Distribution Capability (NDC) messaging and Global
Distribution System (GDS) messaging.
16. The transaction processor server of claim 11, wherein the
processor is further configured to create elements of said one of
the supplier data objects by copying one or more common elements
from another one of the supplier data objects.
17. The transaction processor server of claim 10, wherein the set
of supplier data objects and further data object use identical
serialization.
18. The transaction processor server of claim 15, wherein the
aggregated functional object is presented to the client subsystem
using an Application Programming Interface (API) according to a
context defined by said one of the data object formats.
19. A computer program product comprising program instructions
stored on a computer readable medium, for generation of an
aggregated functional data object for a client subsystem from a set
of supplier data objects having different data object formats,
wherein execution of the instructions by a transaction processor
server configures the transaction processor server to: store the
set of supplier data objects according to their respective data
object formats, each supplier data object including a plurality of
elements; create a further data object for linking selected
supplier data objects based on common ones of said elements shared
between the selected supplier data objects; and create the
aggregated functional data object by merging and combining said
common ones of said elements with remaining ones of the plurality
of elements from the selected supplier data objects according to
said linking, for presentation to the client subsystem.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] This application claims priority from French Patent
Application No. 19 05718, filed May 29, 2019, the contents of which
is incorporated herein by reference.
FIELD
[0002] This specification relates generally to generating data
objects, and more particularly to a system and method for
generating an aggregated functional data object for a client
subsystem from a set of supplier data objects having different data
object formats.
BACKGROUND
[0003] Certain classes of products, including for example
travel-related goods and services, may include a number of
different types of products. For example, the general class of
travel-related goods and services includes products such as
flights, hotel reservations, automobile rentals, and the like.
Multiple products within a class may be purchased in association
with each other by a given user, such as one or more flights and a
hotel reservation for a given trip. The individual products,
however, may be provided by discrete supplier entities (e.g.
airlines, hotels and the like) that employ different data object
formats to store and communicate supplier data objects defining the
above-mentioned products. Therefore, viewing and interacting with
such supplier data objects using a client subsystem, such as a
reservation system, typically requires the user (or an entity
acting on behalf of the user, such as a travel agency) to
accommodate multiple distinct communication protocols, data formats
and update mechanisms, which is costly and error-prone.
SUMMARY
[0004] An aspect of this specification provides a method of
generating an aggregated functional data object for a client
subsystem from a set of supplier data objects having different data
object formats, comprising storing the set of supplier data objects
according to their respective data object formats, each supplier
data object including a plurality of elements; creating a further
data object for linking selected supplier data objects based on
common ones of the elements shared between the selected supplier
data objects; and creating the aggregated functional data object by
merging and combining the common elements with remaining ones of
the plurality of elements from the selected supplier data objects
according to the linking, for presentation to the client
subsystem.
[0005] Another aspect provides a transaction processor server,
comprising a memory storing a set of supplier data objects
according to respective data object formats, each supplier data
object including a plurality of elements; and a processor
interconnected with the memory, the processor configured to create
a further data object for linking selected supplier data objects
based on common ones of the elements shared between the selected
supplier data objects, create an aggregated functional data object
by merging and combining the common elements with remaining ones of
the plurality of elements from the selected supplier data objects
according to the linking and present the aggregated functional data
object to a client subsystem.
BRIEF DESCRIPTIONS OF THE DRAWINGS
[0006] Embodiments are described with reference to the following
figures, in which:
[0007] FIG. 1 depicts a system for generating an aggregated
functional data object according to an aspect of this
specification;
[0008] FIG. 2 depicts certain internal components of a transaction
processor of the system shown in FIG. 1;
[0009] FIG. 3 depicts a method of generating an aggregated
functional data object according to the system of FIG. 1;
[0010] FIG. 4 depicts the receipt of a request from a client
subsystem to retrieve one or more supplier data objects and
generation of an aggregated data object during the performance of
the method of FIG. 3.
[0011] FIG. 5 illustrates a method of updating an element of an
aggregated functional data object.
[0012] FIG. 6 depicts receipt of a request from a client subsystem
to update an element of an aggregated functional data object and
generation of an aggregated data object during the performance of
the method of FIG. 5.
DETAILED DESCRIPTION
[0013] FIG. 1 depicts a system 100 for generating an aggregated
functional data object for a client subsystem from a set of
supplier data objects having different data object formats. The
data objects, in the embodiments discussed herein, define products
such as travel-related goods and services such as flights, hotel
reservations, vehicle rentals, and related services (e.g. baggage
check services for flights, lounge access at airports, WiFi access
on flights or at hotels, and so on). For example, in the travel
industry, one such data object is known as a Passenger Name Record
(PNR), which is a record in the database of a Computer Reservation
System (CRS) that contains the itinerary for a passenger, or a
group of passengers traveling together.
[0014] There is no general industry standard for the layout and
content of a PNR. In practice, each CRS or hosting system has its
own proprietary standards, although common industry needs including
the need to map PNR data easily to ATA/IATA Reservations Interline
Message Procedures (AIRIMP) messages has resulted in many general
similarities in data content and format between the major
systems.
[0015] In terms of content, a PNR may include the name of the
passenger, contact details for the travel agent or airline office
(e.g. an 8-digit IATA code of the travel agency or airline office;
ticketing details (e.g. a ticket number); the itinerary of at least
one segment and the name of the person providing the information.
Once the booking has been completed with the foregoing information,
the CRS will issue a unique alphanumeric record locator.
[0016] Delivery of the above-mentioned products to customers is
typically implemented by a provider entity, such as an airline for
flights, a rental agency for vehicle rentals, and the like. Prior
to delivery of the products to customers (e.g. passengers on a
flight), the products must be purchased or otherwise secured on
behalf of the customers, via a series of data exchanges. To that
end, the system 100 includes one or more supplier subsystems, of
which two examples 104-1 and 104-2 are shown (collectively referred
to as supplier subsystems 104, or simply suppliers 104). Data
objects maintained by or on behalf of each supplier define the
products available for purchase, or already purchased, from the
supplier. The above-mentioned data objects are also referred to as
supplier data objects in the discussion below.
[0017] The supplier subsystems 104 can be, but are not required to
be, operated by the above-mentioned providers. For example, the
supplier 104-1 may, in the present example, be operated by an
airline (i.e. a provider). For instance, the supplier 104-1 may
exchange data with other components of the system 100 to enable the
provision of products according to the eXtensible Markup Language
(XML)-based New Distribution Capability (NDC) standard. The NDC
standard was developed in 2012 by IATA to enable airlines to take
control of products proposed to end users or travel agents. The
supplier 104-1 maintains a repository 108-1 defining product
inventory, such as an Order Management System (OMS) containing
flights operated by the airline that are available for booking, or
have been booked.
[0018] Other supplier subsystems 104 can be provided. For example,
the supplier 104-2, in the present example, is an airline passenger
service system (PSS) that stores product inventory and/or bookings
in repository 108-2. The supplier 104-2 exposes IATA PSS
applications (based on TTY or Edifact messaging) to allow other
components of the system 100 to create, update and display
bookings.
[0019] The system 100 can include a wide variety of additional
supplier subsystems 104, including additional GDS subsystems,
and/or additional provider-operated subsystems. For example, the
system 100 can include a further GDS-based supplier for low-cost
carrier airlines.
[0020] The system 100 also includes a client subsystem 120, for
example operated by a travel agency or the like, configured to
interact with the supplier subsystems 104 via a network 128
including any suitable combination of local- and wide-area networks
(including the Internet). The client subsystem 120, as will be
discussed in greater detail below, is configured to obtain supplier
data objects from the supplier subsystems 104, and to request
updates to the supplier data objects in order to book the
above-mentioned products on behalf of customers (e.g. individual
persons). Additional client subsystems (not shown) may also be
included in the system 100.
[0021] As will now be apparent, the client subsystem 120 may
interact with a number of different supplier subsystems 104 on
behalf of any given customer. Each supplier subsystem 104 may store
and exchange supplier data objects in divergent formats (e.g.
according to different communication standards or protocols, and
employing different combinations and hierarchies of fields within
the data objects). Further, each supplier subsystem 104 may
implement different update mechanisms for purchasing (which may
also be referred to as booking) the above-mentioned products, and
for making changes to existing purchases.
[0022] The heterogeneous nature of the supplier data objects and
the update mechanisms provided by the supplier subsystems 104 may
impose a substantial technical burden on the client subsystem 120
(and any other client subsystems in the system 100), by requiring
that each client subsystem implement communication mechanisms to
interact with each supplier subsystem 104. Further, the variable
nature of the supplier data objects maintained by the supplier
subsystems 104 may lead to inconsistent presentation of information
at the client subsystem 120, which in turn may cause erroneous or
malformed purchase requests to be transmitted to the supplier
subsystems 104.
[0023] The system 100 therefore also includes a transaction
processor 132 configured to intermediate between the supplier
subsystems 104 and the client subsystem 120 (and, more generally,
any client subsystem of the system 100), as well as coordinate
transactions between different back-end systems 144, as discussed
below. The transaction processor 132, as will be discussed below in
greater detail, is configured to obtain supplier data objects from
one or more supplier subsystems 104 (e.g. in response to a request
from the client subsystem 120). The transaction processor 132 is
further configured to generate an aggregated functional data object
from a set of supplier data objects acquired through different
messaging standards, such as NDC for supplier data objects received
from supplier 104-1, Edifact or TTY for air content supplier data
objects received from supplier 104-2 via GDS messaging, or other
protocols such as XML, JSON, for other content received from
supplier 104-2 via GDS messaging. To that end, the transaction
processor 132 includes a travel platform module 136 and a virtual
record handler 140. Travel platform module 136 is the entry point
to the transaction processor 132 for the client subsystem 120 and
supplier subsystems 104. The travel platform module 136 is
responsible for keeping the user (e.g. agent) context whereby a
user may open a session to retrieve a PNR or other data object,
perform one or more entries on the data object during the session
and then commit the session (from memory to long-term storage),
although it is also contemplated that that interaction with the
travel platform module 136 can be stateless, in which case any
action is instantly committed. For a given session, its purpose is
to attach the latest version of the context and forward functional
queries to related application servers. The context is stored in
memory and retrieved using a session identifier. However, in
accordance with an aspect of this specification the functionality
of the travel platform module 136 is extended to store multiple
data objects in memory (i.e. multi-record context), such as
differently formatted NDC and GDS records 137 and 138, as well as a
further data object 141, referred to herein as a `folder`, which
uses the same technical structure the other data objects. It will
be appreciated that although only PNR records 137 and 138 are
illustrated, any number of data objects may be stored. Furthermore,
the principles set forth herein may be applied to data objects
other than PNR records, which are merely exemplary.
[0024] The folder data object 141 stores links between the various
data objects 137, 138, etc. For example, folder data object 141 may
store a link to establish that the passenger data element in one
data object identifies the same person (e.g. Mr. Toto in FIG. 1) as
the passenger data element in another data object.
[0025] Virtual record handler 140 is configured to build an
aggregated data object from the multi-record context of the travel
platform module 136 by taking elements from multiple data objects
137, 138, etc., and aggregating them using the links stored in the
folder data object 141. Thus, the folder data object 141 is used to
determine if common elements in disparate data objects need to be
merged (e.g. same passenger, etc.) to generate an aggregated data
object. That is, folder data object 141 keeps track of the
association of elementIDs in each data object.
[0026] The transaction processor 132 is also configured to provide
aggregated update operations to the client subsystem 120, e.g. in
the form of an application programming interface (API). The client
subsystem 120 can therefore request any of a variety of updates to
the supplier data objects (regardless of the particular format of a
given supplier data object) by transmitting an aggregated update
request to the transaction processor 132. The transaction processor
132 is configured to generate one or more supplier-specific update
operations in response to receiving an aggregated update request
from the client subsystem 120, as discussed below.
[0027] Turning to FIG. 2, before discussing the functionality of
the system 100 in greater detail, certain components of the
transaction processor 132 will be discussed in greater detail.
[0028] As shown in FIG. 2, the transaction processor 132 includes
at least one processor 200, such as a central processing unit (CPU)
or the like. The processor 200 is interconnected with a memory 204,
implemented as a suitable non-transitory computer-readable medium
(e.g. a suitable combination of non-volatile and volatile memory
subsystems including any one or more of Random Access Memory (RAM),
read only memory (ROM), Electrically Erasable Programmable Read
Only Memory (EEPROM), flash memory, magnetic computer storage, and
the like). The processor 200 and the memory 204 are generally
comprised of one or more integrated circuits (ICs).
[0029] The processor 200 is also interconnected with a
communication interface 208, which enables the transaction
processor 132 to communicate with the other computing devices of
the system 100 (i.e. the supplier subsystem 104 and the client
subsystem 120) via the network 128. The communication interface 208
therefore includes any necessary components (e.g. network interface
controllers (NICs), radio units, and the like) to communicate via
the network 128. The specific components of the communication
interface 208 are selected based on the nature of the network 128.
The transaction processor 132 can also include input and output
devices connected to the processor 200, such as keyboards, mice,
displays, and the like (not shown).
[0030] The components of the transaction processor 132 mentioned
above can be deployed in a single enclosure, or in a distributed
format. In some examples, therefore, the transaction processor 132
includes a plurality of processors, either sharing the memory 204
and communication interface 208, or each having distinct associated
memories and communication interfaces.
[0031] The memory 204 stores the data objects 137, 138 etc., as
well as the folder data object 141 mentioned above in connection
with FIG. 1. The memory 204 also stores a plurality of
computer-readable programming instructions, executable by the
processor 200, in the form of various applications, including an
aggregation application 212. As will be understood by those skilled
in the art, the processor 200 executes the instructions of the
application 212 (and any other suitable applications) in order to
perform various actions defined by the instructions contained
therein. In the description below, the processor 200, and more
generally the transaction processor 132, are said to be configured
to perform those actions. It will be understood that they are so
configured via the execution (by the processor 200) of the
instructions of the applications stored in memory 204. Execution of
the application 212, as will be discussed below, configures the
transaction processor 132 to generate an aggregated functional data
object from a set of supplier data objects having different data
object formats, for presentation to the client subsystem 120.
Execution of the application 212 also configures the transaction
processor 132 to receive aggregated update operations from the
client subsystem 120, which can be handled either at the virtual
record level, or split down to the physical record level, as
discussed in greater detail below, for updating the supplier data
objects at one or more of the supplier subsystems 104.
[0032] Turning now to FIG. 3, certain aspects of the operation of
the system 100 will be described in greater detail. Specifically,
FIG. 3 illustrates a method 300 of generating an aggregated
functional data object, according to an embodiment. The method 300
will be described in conjunction with its performance within the
system 100, as illustrated in FIG. 4. In particular, the blocks of
the method 300 are performed by transaction processor 132 via the
execution of the application 212 by the processor 200.
[0033] At block 305, the transaction processor 132 is configured to
receive a request from client subsystem 120 to retrieve one or more
supplier data objects, which need not be received from the same
supplier 104. For example, the client subsystem 120 may request an
itinerary booking for a passenger, Mr. Toto, where one supplier
104-1 provides one flight while another supplier 104-2 provides a
second flight, where both flights form part of the itinerary of the
passenger.
[0034] At block 310, the travel platform module 136 passes the
request to a back-end system 144, such as an order view builder.
The order view builder, at block 315, formulates a request to the
virtual record handler 140 for generating an aggregated functional
data object. In response, at block 320, virtual record handler 140
retrieves data objects 137, 138 and 141 and returns a virtual
aggregated data object.
[0035] In the illustrated example, data objects 137 and 138
comprise technical records acquired through different messaging
standards, NDC and Edifact, respectively. NDC PNR (137) contains
the following elements: a record identifier: ABCDEF for identifying
the PNR record, an element ID for identifying passenger Mr. Toto,
and an element ID containing a flight element FE 001 from one
supplier (e.g. 104-1), where the descriptor `NDC` is a distribution
channel indicator for indicating that the technical record is
acquired through NDC messaging. Similarly, a technical GDS PNR
(138) contains the following elements: a record identifier GHIJKL
for identifying the GDS record, an element ID for identifying
passenger Mr. Toto, and an element ID containing a flight element
FE 002 from another supplier (e.g. 104-2), where the descriptor
`GDS` is a distribution channel indicator for indicating that the
technical record is acquired through GDS messaging. Although the
technical records 137 and 138 are similar in that they pertain to
air content communicated through independent messaging channels,
the principles set forth herein apply to other types of technical
records pertaining to other content (e.g. hotel, car rental,
etc.).
[0036] In the example, folder data object 141 contains a link
defining an association of the element IDs in each of the supplier
data objects 137 and 138 for identifying passenger Mr. Toto as a
common element shared between the data objects. The generated
virtual aggregated data object includes data elements for
identifying the passenger, Mr. Toto, and the two flight elements:
FE 001 and FE 002.
[0037] At block 325, the aggregated data object is returned to the
back-end system 144 (order view builder) which, at block 330,
transmits the aggregated data object back to client subsystem 120
for viewing, updating, etc.
[0038] With respect to updating, FIG. 5 illustrates a method 500 of
updating an element of an aggregated functional data object,
according to an embodiment. The method 500 will be described in
conjunction with its performance within the system 600, as
illustrated in FIG. 6. In particular, the blocks of the method 500
are performed by transaction processor 132 via the execution of the
application 212 by the processor 200. At block 505, the transaction
processor 132 is configured to receive a request from client
subsystem 120 to modify one or more supplier data objects. For
example, client subsystem 120 may request that a remark linked to
FE 001 NDC content be added to a PNR.
[0039] At block 510, travel platform module 136 passes the request
to the virtual record handler 140 which, at block 515, retrieves
data objects 137, 138 and 141 and exchanges messages with back-end
system 144 which, in the illustrated example comprises a back-end
remarks handling system. The virtual record handler 140 analyzes
the request and determines that the remark only needs to be added
to the NDC content (e.g. by distributing a query only to the NDC
record). The virtual record handler 140 thereby splits the update
actions at the physical level and then regenerates the aggregated
view to add the updated remark to the NDC content, at block 520,
and returns the updated data object for record ABCDEF to travel
platform module 136 which, at block 525, transmits the aggregated
data object back to client subsystem 120 for viewing, updating,
etc.
[0040] A person of skill in the art will understand that additional
functionality may be provided by the virtual record handler 140 set
forth herein. For example, supplier 104-1 or 104-2 may "split" a
PNR to add an additional passenger, in which case a conventional
system would present to the user two records having two locators
(e.g. ABCDEF and GHIJKL). According to the method and system set
forth herein, the virtual record handler 140 will aggregate the
user view showing both passengers with a single locator.
[0041] Those skilled in the art will appreciate that in some
embodiments, the functionality of the application 212 at the
transaction processor 132 may be implemented using pre-programmed
hardware or firmware elements (e.g., application specific
integrated circuits (ASICs), electrically erasable programmable
read-only memories (EEPROMs), etc.), or other related components.
Also, as will be apparent to those skilled in the art, the systems
and methods discussed above can also be applied to various other
types of data objects (that is, data objects defining a wide
variety of other forms of products) and is not limited to travel
reservation systems and data objects associated therewith.
[0042] The scope of the claims should not be limited by the
embodiments set forth in the above examples, but should be given
the broadest interpretation consistent with the description as a
whole.
* * * * *