WO2016102590A1

WO2016102590A1 - Customer servicing system and method therefor

Info

Publication number: WO2016102590A1
Application number: PCT/EP2015/081029
Authority: WO
Inventors: Stuart Alan Atkins
Original assignee: Sita Information Networking Computing Uk Limited
Priority date: 2014-12-23
Filing date: 2015-12-22
Publication date: 2016-06-30

Abstract

A customer servicing system comprising a server or means for associating a reservation for a customer journey between an origin and destination is disclosed. The reservation is associated with a customer journey profile record for the customer. The customer journey profile record comprises data defining the journey between the origin and destination, the data associated with further data defining the journey via at least one point connecting the origin and destination.

Description

CUSTOMER SERVICING SYSTEM AND METHOD THEREFOR

FIELD OF THE INVENTION This invention relates in general to a user servicing system, such as a passenger servicing system. More particularly, this invention relates to a system for booking or reserving a particular product or service selected from a number of different products or services which might be available. This invention also relates to a departure control system. More particularly, this invention relates to a departure control system or/and booking or/and reservations system which may be used by an airline or other transport services provider. The invention also relates to a database for use by a booking, reservations system or/and a departure control system, and to an associated data structure of the database. Even more particularly, the invention relates to a reservation or/and departure control system for seats on aeroplanes and the like.

BACKGROUND OF THE INVENTION

In the past, computerised reservations systems and departure control systems used by airlines have developed as completely different systems. Usually, there is no direct link between essential data which is common to both systems. Although such systems have been linked via back-end mechanisms, delays in transferring essential data between such systems means that there is currently a high probability that data common to both systems is not consistent. This is a huge issue for airlines because it can, for example lead to overbooking. Further, each system requires an enormous amount of information in order to correctly perform the departure control or reservation process. Accordingly, developers have traditionally sought to maintain separate databases for each system. In such systems data or information, such as a passenger's name, is sent from the reservations system to a departure control system, prior to a passenger starting the check- in process for a flight. However, this data may be subject to change, for example, if the reservations system for example has a misspelt passenger name. Usually, however, changes made to departure control systems data are usually not fed back to reservations systems, because of, for example, network bandwidth constraints. Other information which may subject to change may be age category (such as Adult, Child, Infant), Flight Number, Destination, Compartment, Status, Inhibit information which may relate to Government Security, Watch Lists, Payments and other more general information that could inhibit the passenger's ability to travel, the Record Locator of their Reservation and possibly Seat Number if one has already been chosen, seat information such as Seat Number, as well as information indicating whether or not the passenger actually boarded their flight.

Furthermore, Departure Control is not the only system in which data associated with a passenger may change after the passenger arrives for check-in and boarding. For example, if a passenger decides to change their flight while at the airport, then their ticket information in ticketing systems may change. This information is usually not fed back to the reservation system. Further, flight disruption may result in flight cancellations and passengers being re-accommodated on other flights. This may entail changes to

Operational Flight databases as well as Departure Control and Ticketing databases.

Consequently, different systems, such as reservations, departure control (DCS), ticketing and Flight Operations may contain different and conflicting information about the same Passenger's Flight(s) and Ticket(s).

Furthermore, many airlines analyse their data in large data warehouses. These may collect data from multiple systems into a single platform in order to enable reporting, data mining, decision support, historical analysis and future planning for managers across a wide range of IT systems that together contribute to the end-to-end management of their airline business. These data warehouses must therefore attempt to integrate data sourced from reservations, departure control, flight operations and ticketing systems, for example.

However, as outlined above, the great disparity between the data in these different systems through having multiple inconsistent copies of the same data means that it is very problematic to match and integrate data from these different systems. As such, this data is the less useful for analysis purposes.

Many Data Warehouses do not manage to fully solve the integration issues. For example, some do not link ticketing and booking systems. Thus, operational flight information that matches with DCS information tends to contradict flight information in the Reservations system because the consequences of, for example, flight disruption in the DCS and flight operations are not fed back to the reservations system. Even when reservations, DCS and ticketing information can be matched on ticket numbers or reservations record locators, the data attributes (i.e. the lower-level information such as Names, Statuses etc.) are often contradictory so the Data Warehouse must arbitrarily assume what it believes to the most accurate source of the data without accurately determining whether these assumptions are correct.

Taking management decisions based on inaccurate or inconsistent data can lead to sub- optimal revenues for airlines, to the extent potentially of millions of pounds per year.

Similarly, if particular data is always assumed to be inaccurate, then meaningful data analysis of that data is not possible. Accordingly, in this case, the whole purpose of the data warehouses for data analysis has failed for that particular data, and as such airlines fail to derive full benefit from a costly data warehouse system for that data.

Accordingly, it will be appreciate that a problem with legacy systems such as reservation and departure control systems is that common data entities become out of step with each other. Further, common data entities may contain contradictory data due to the different information lifecycles of the reservations and departure control systems, and because of a lack of data integration between the systems. Furthermore, conventional reservations systems manage bookings on a flight segment basis, whereas departure control systems are managed on a leg basis. Accordingly, conventional departure control and reservations systems are inherently incompatible with each other. SUMMARY OF THE INVENTION

The invention is defined in the appended claims to which reference should now be made.

In one aspect, embodiments of the invention aim to address these problems by associating a reservation for a customer journey between an origin and destination with a customer journey profile record for the customer wherein the customer journey profile record comprises data defining the journey between the origin and destination, the data associated with further data defining the journey via at least one point connecting the origin and destination. In other words, a link may be provided between a plurality of different legs of a journey associated with a passenger and a journey segment associated with the passenger, the segment comprising one or more of the legs. The customer journey profile record comprises data defining the journey between the origin and destination associated with further data defining services associated with the customer journey. Further, embodiments of the invention aim to address these problems by providing a user servicing system such as a reservations or/and departure control system comprising processing means configured to construct a customer reservation for a customer journey between an origin and destination; and storage means for storing the reservation wherein the reservation comprises a plurality of legs and wherein a segment is associated with the plurality of legs.

Embodiments of the invention aim to address the above problem by instantiating common data entities only once so that data managed by the reservations system remains synchronised with the data managed by the departure control service using a customer journey database.

In one aspect of the present invention, a single system for providing both reservation and departure control is provided. Usually, the system comprises a single database. Embodiments of the invention provide a data structure for a database wherein a single database for both systems may be provided.

Embodiments of the invention have the advantage that modifications to the system may be easily implemented. This may be in part due to the relational nature of the database embodying the invention. This may allow the system to be adaptable to changing business needs.

Embodiments of the invention bypass the issues that Data Warehouses and similar information systems (such as Operational Data Stores and Data Marts) face in traditional airlines by avoiding creating data discrepancy issues. By avoiding creating multiple copies of data that could become sequence with each other data integration issues that have to be solved in back-end systems such as Data Warehouses are avoided.

Embodiments of the invention may comprise a relational database structure for storing data associated with a particular user, customer, customer journey, or passenger. This may include the following benefits: It may allow relational normalisation techniques to be used. This may minimise the opportunity for there to be data anomalies resulting from multiple copies of the same data in different entities e.g. of the Customer Name information were copied to entities other than CUST then that would be a denormalization that would open the door to data anomalies caused by one copy being updated without updating the other copy.

Relational Normalisation minimises the amount of work to be done in the database to update existing data. For example, if the Customer Name needs to be altered then only a CUST record needs to be updated in the database - all of the other information does not need to be touched, nor are there any other copies of the customer data that also need to be updated to avoid the aforementioned data anomalies. This minimises the disk I/O needed to execute the update in the DB and therefore maximises the performance. · Relational databases are easy to alter - as many attributes as needed may be added to or removed from entities over time as requirements change. Further, as many entities as needed may be added to or removed from the database.

The structure of Relational Databases is inherently extensible and easy to update.

This contrasts with the PNR record maintained in legacy reservations systems in which fixed length record formats make it difficult to alter thereby increasing time-to-market for new or altered business requirements. Sometimes as business requirements change over time, old attributes (database fields) fall into disuse and are re-used to fulfil new requirements so what a database user might think is contained in a field based on the name of the field may not be what is actually in it. This increases the complexity of maintaining and updating such systems and makes them more prone to failure.

In the legacy PNR structure a large amount of different kinds of business data tends to be poured into 'bucket' structures in the PNR called SSRs (Special Service Requests) and OSIs (Other Service Information). Since different type of data participate in different business process, this reduces the ability to implement such differences and nuances in business process as the underlying data structures may not support everything that the business would ideally like to do, thereby reducing the ability to automate the management of the data and the ability to automate the business process. It also increases the complexity and cost of coding for such systems because data that is critical for the business process may be encoded in free-text fields according to a multitude of complex rules published by AIRIMP and which require parsing and interpretation. Relational Databases address this problem by avoiding such encoding and holding business-critical data in atomic-level structured fields that do not require additional parsing or contextual interpretation.

Embodiments of the invention may comprise a service-oriented architecture and relational database which are which are integrated or communicatively coupled at a service level. For example, a service may be defined as an autonomous and independently deployable stack of data entities in a database and the business logic that manages the data content of the database and the business processes of the service.

The key benefits of Service-Orientation are autonomy and independence of deployment of the Service. A relational database architecture may include a large number of data entities in a single database. This may allow them to be normalised and a single accurate version of the data can be assured. Further, data anomalies can be avoided that usually result from copying the same data to multiple entities or multiple databases which may become out of step with each other due to having different information lifecycles.

Embodiments of the invention may integrate Service-Oriented architecture with Relational Database architecture by defining services with a large enough degree of granularity so that all of the business logic and data entities required to manage a single business process are present in the same service. This allows the key Service-Oriented benefits of autonomy and independence of deployment to be realised at the level of the Business

Process while retaining the benefits associated with normalisation and single version of the truth that are derived from Relational Database Architecture. In addition, any dependencies between Services are managed at the level of the Business Logic by way of Service calls to retrieve data from other services.

Embodiments of the invention provide a customer journey system in which two different processes, such as reservations and departure control, are supported by a single database tier, referred to as Customer Journey database. The database comprises data entities common to both the reservations and departure control system. This avoids common entities being duplicated between the Reservations and Departure Control services which leads to a high degree of mismatching between the two Services since their business processes operate with different information lifecycles and data from entities managed in Departure Control systems often is not fed back to the duplicate data entities in the Reservations system.

This creates problems in back-office reporting systems and data warehouses that attempt to merge and match data from Reservations systems and Departure Control systems and it therefore reduces the quality of data available for Business Reporting, Data Mining and other back-office or non-operational requirements. Customer Journey prevents such data mismatches from occurring in the first place by providing a common database for the common entities that are managed by both the Reservations and the Departure Control business processes while at the same time containing entities that are only managed by Reservations as well as entities that are only managed by Departure Control.

Embodiments of the invention may use the latest programming languages and

technologies available such as Java, HTML, XML and all the latest Web Service technology which may be cheaper and easier to develop and maintain, compared to older programming languages such as TPF or FORTRAN, as there are many more developers available for such modern languages compared to the older and more specialist mainframe languages.

Embodiments of the invention may comprise an integrated reservations and departure control system which are integrated at the database level. However, inventory systems may still be managed in a separate database even though all three may be integrated at the Service level. The customer journey system and departure control system may share the same database. Services supporting these systems may call the inventory service to reserve the inventory that is held for particular airlines in the inventory database. Thus, embodiments of the invention find application in the travel industry in general, for example, rail, air, coach and the like. Embodiments of the invention may also be integrated with external flight ticketing systems.

Embodiments of the invention may be built on, or incorporate, a SOA suite Oracle BPEL platform. However, other platforms known to the skilled person may be used. For example, other platforms or programming languages may be used such as C++, JAVA, and .xml may be used as well as other programming languages which will be known to the skilled person. Further, embodiments of the invention may use one of these programming languages to provide a web-based service.

BRIEF DESCRIPTION OF THE DRAWINGS

An embodiment of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram of the main functional components embodying the invention;

Figure 2 is a schematic diagram of an embodiment of the invention showing a logical level architecture of a customer journey system which has been simplified for clarity;

Figure 3 shows a number of different attributes and their associated definition of the customer journey logical entity of figure 2; and

Figure 4 is a flow diagram showing the main steps performed by an embodiment of the invention.

The following description is of a system, such as a reservations or/and departure control system for use in the aviation industry, but this is exemplary and other applications of the invention will also be discussed. For example, the system may be used in any environment where a product or service is provided to a user, customer, or passenger or indeed in any environment where customer journey analysis is performed. For example, embodiments of the invention may also be applicable to the travel industry in general, and in a further particular example, in the rail industry, where a journey may be between an origin and destination. A number of connecting services may be required to link the origin and destination.

It will also be appreciated that a system embodying the invention may relate to a passenger or user servicing system which may comprise a suite of systems including reservations, inventory management and departure control systems.

Further, a system embodying the invention may comprise a hosted system (for example hosted by an airline or travel agent) which may use API communications protocols to communicate with external systems. The system may also be hosted by a multi-airline provider of passenger reservations and servicing such as system described in detail below or any CRS (Computer Reservations System) or GDS (Global Distribution system).

Figure 1 is a schematic diagram showing the service architecture of a system embodying the invention. This shows how multiple systems, multiple products, or multiple User Interfaces, such as DCS and reservations access the same customer journey service system, usually, via sales & servicing services, which in turn has links to services for seats, inventory and customer profiles. The services may be provided as a part of a customer journey or/and sales & servicing or/and departure control product within a SITA Reservations Desktop Graphical User Interface, GUI or/and a Departure Control System GUI. However, the system is not limited to these particular user interfaces. Thus, for embodiments hosted by airlines, it may be used with a user interface developed by the hosting airline.

In figure 1 , the seats service system 103 is shown twice in the diagram for clarity purposes, but as these relate to the same system for providing a seats service, the same reference numeral 103 has been assigned to the two boxes shown in figure 1 . The system 100 may comprise a reservations or bookings system or server 101 such as a SITA reservations or bookings system or server. The reservations server 101 may be communicatively coupled to an inventory system, not shown in figure 1 . The inventory system controls the availability of seats on a flight or leg/segment of a journey, and will not be described in further detail as such reservations systems are known to the skilled person. However, it will be appreciated that the reservations server or system 101 may interact with the inventory system (not shown in figure 1 ) to retrieve and display availability and to allow an available flight to be reserved, which in turn decrements the available inventory in the inventory server or system. Referring once again to figure 1 of the accompanying drawings, the system, 100, may comprise any one or more of the following components: an electronic data interchange for administration, commerce and transport (EDIFACT) messaging system, 105, a teletype Messaging System, (TTY), 107, a departure control system (DCS), 109, a SITA web services system (SWS), 1 1 1 , a reservations desktop (RDT), 1 13, which may provide a user-interface for the reservations system 101 , a messaging application system (MA), 1 15, a host access layer (HAL), 1 17 for ticketing, an inventory availability and schedules for an airline's inventory (IAS), 1 19, and a fares proxy service system (AXI) 121 .

Some of these systems may use CRUD transactions which may refer to a set of possible transactions supported by (and that can be submitted to) a database. In this acronym, C=Create (Data), R=Read (data), U=Update (Data) and D=Delete (Data). This allows one or more of the service to interface with a database by performing one or more of these CRUD transactions. In figure 1 , the sales & servicing system 123 interfaces with the customer journey service to access the customer journey database. In this way, the customer journey service system 127 may perform CRUD transactions on behalf of the sales and servicing service system 123.

In the specific embodiment shown in figure 1 , the services provided by the systems shown in figure 1 do not need to use messaging to exchange information. Rather, for example, the step of retrieving a customer profile from the customer profile system or database 129, may be performed by a service call. For example, the customer journey service system 127 may call the customer profile service using a service interface. Data about the customer may be sent in XML format, and this data may identify a particular customer profile record stored in the database and allow it to be retrieved from the database. The retrieved customer profile may also be returned to the Customer Journey service in XML format using a service call. Further, each service formats the XML that it sends. Of course, in other examples, other ways to exchange information known to the skilled person may be used, such as messaging. The systems shown in figure 1 may perform various different services as outlined below by making a call to a specific service using a published service interface, which will be known to the skilled person. Similarly, data may be sent in XML format, and data may be returned to the calling service in an XML format using a service call. Each service formats the XML that it sends. Web Services Description Language is defined in an international standard accessible at http ://www.w3. o rq/TR/wsd I and is the standard used to publish service interfaces.

Further, each system, such as a customer journey service system 127, may generate an object-oriented database update statement which is then converted by Object-Relational Mapping (Hibernate) to SQL which may be the native language of the database. The SQL may be sent to the database via an Oracle Weblogic Database session (i.e. a permanently logged on connection between the customer journey service and the customer journey database).

One specific example will now be described with reference to a customer contacting a travel agent to reserve a flight.

The agent may use a RDT user interface running on the RDT system 1 13 to interact with the sales & servicing services system 123 as outlined above. The sales and servicing services system 123 in turn interacts with a product, fares & pricing system 125 to provide a range of different flight options and fares for the customer to choose from. The customer chooses one of the different flight options and fares, and the agent then uses the RDT user interface to interact with the sales & servicing service system to construct a reservation. Usually, the reservation is associated with a journey segment comprising a plurality of legs. The reservation may be uniquely identified by a booking reference, which is usually an alpha-numeric string. However, the reservation may also be associated with a plurality of segments. Accordingly, a journey may be defined by a plurality of different legs or segments linking an origin to a destination. In some examples, a segment may correspond to a leg of a journey, however, legs may be relevant to defining the movement of an aircraft or other vehicle between an origin and destination while segments may be relevant to defining the movement of passengers or customers between, what may be in some examples, a different origin and destination. Accordingly a segment may comprise one or more legs.

Further, a single journey may be reserved by multiple different customers. In particular, if there is more than one customer in a single customer journey record and if the rule of homogenous itineraries is applied, then all customers associated with the single customer journey record must all fly the same journey. Moreover, the same journey may be reserved by a different customer or group of customers in a different reservation. Finally, a customer may reserve multiple journeys in multiple different customer journey records.

A CJ may represent a particular Journey Reserved at a point in time by one or more customers.

For example, a first customer travelling alone in business class on a return journey from LHR to JFK in one month's time may have a reservation for that journey in one customer journey record. The same individual, this time travelling with a spouse and 2 children in economy class on a return journey from LHR to PAR in 6 month's time may have a reservation for that journey in a completely different customer journey record.

Further, there may not be a connection between the two customer journey records stored in the database. This may be the case if the journeys were with different airlines. However if the journeys are with the same airline then they may be connected by virtue of the fact that both customer journeys contain references to the same customer profile record for the first customer. Also the Customer Profile record for the first customer for the Airline he is flying with may also contain references to both customer journeys. This is because individuals may have multiple customer profiles, one for each airline that they fly with.

Optionally, the customer may also provide the agent with enough information to identify a customer profile associated with the customer, for the airline the customer wishes to fly on. For example, a customer profile may be uniquely identified using one or more of customer name, date of birth, address, passport number, and frequent flyer number.

This information may be a customer profile identifier, such as an alphanumeric string. A customer profile associated with the passenger is optionally retrieved from the customer profile database by a customer journey service system 127, via the customer profile service and is returned to the sales & servicing service system 123.

The step of retrieving the customer profile may be performed by a service call, as outlined above. The customer journey service may call the customer profile service using its published service interface. Data about the customer is sent in XML format, enough data to identify the customer profile record. The retrieved customer profile is also returned to the customer journey service system 127 in XML format using a service call. Each service formats the XML that it sends. In this way, a customer's preferences for meal type, form of payment, hotels, seat type, class of travel, contact and emergency contact information and so on may be honoured in constructing the reservation. Furthermore, it should be noted that the customer may override or change any of their preferences.

After optionally identifying a customer profile, the sales & servicing services system 123 then interacts with the IAS Inventory service system 1 19 to display availability of multiple flights and to reserve airline inventory for the flight chosen by the customer and decrement the remaining inventory for the flight. The sales & servicing system 123 then passes the completed reservation details to the customer journey service system 127 which saves it in the customer journey database. Preferably the customer profile identifier (ID) such as an alphanumeric string, any Frequent Flyer details (so that miles or points can be accrued) and a time limit governing the length of time allowed for the customer to pay for the customer journey before it is automatically cancelled and the inventory is released, are also saved in the customer journey database.

The reservation may comprise data or information that identifies one or more customers and the reserved journey plus a record locator (booking number) that uniquely identifies the customer journey. Further, additional information or data may be added either upon first creation of the customer journey or at a later part of the process (including check-In). This information may include information such as any one or more of Seat Requests Special Services or Meal Types required, Medical Assistance, Forms of Identification, additional (or auxiliary travel services such as Bus or Rail travel, Hotel reservations, Ticketing Details and boarding details although these are not essential for the initial creation of the customer journey.

The reservation details or/and customer journey database may be stored in a storage means such as a hard drive or Random Access Memory, although this is not shown in figure 1 .

In this way, embodiments of the invention may create a reservation, which may optionally be saved in a customer journey database, in a work area in the sales & servicing service system 123. Usually, however, it is not until the reservation is complete that it is written into the customer journey database as outlined above. The reservation may be completed when a minimum amount of data mentioned above has been provided but any of the optional data also mentioned may also be provided at this stage (apart from boarding details). If optional information is included then the reservation is considered complete once the optional information has also been entered. In this example, as a new customer journey has been created, there is no need for interaction with the customer journey database until the completed reservation is saved.

The customer journey may comprise data defining the reservation from origin to destination. Usually, all customers in a customer journey travel the same journey if a homogenous itineraries rule (described in further detail below) is used, but embodiments of the invention may advantageously employ divergent itineraries (described in further detail below). However, other details in the customer journey may vary for each customer and/or by segment e.g. additional services required, meal requests, seat requests, medical assistance, and so on. In some embodiments, a customer journey associated with a particular passenger or customer profile may be defined. The customer journey may comprise reservation data which may be used by ticketing and departure control systems. Thus, the customer journey may comprise data defining a reservation. The customer journey may comprise a many-to-many association between a plurality of flight segments associated with the passenger and a plurality of different customer profiles. This is described in further detail with reference to the data model of figure 2 and the associated description below. The association may be stored in the database. In this way, a plurality of different flight segments are associated with a plurality of different customers within, or associated with a customer journey record. In embodiments where the homogenous itineraries rule is used, there may be no need to create an association between the plurality of different flight segments and the plurality of different customers, because the customer journey record itself may be the association because the customer journey record may comprise data defining the customers. For example, each customer in a customer journey is reserved on each of the flight segments in the customer journey by virtue of the fact that they are in the same customer journey. However, one reason why embodiments of the invention may create association tables within the customer journey record is to record attributes that may vary by customer for each flight segment or leg, for example Form of ID, additional Services, and so on and also to support a divergent itineraries rule outlined below. The many-to-many relationship may be between the customers and the flight segments. Each Customer may also be associated with one and one only customer profile for the airline they are flying with, although if a customer has flown with multiple airlines then each customer may have multiple customer profiles, one for each airline. Only one customer profile per customer is recorded in the customer journey record. This may be the profile that is associated with the airline they have made the reservation with. Thus, the customer journey logical entity may include a key to uniquely identify a customer journey as well as an optional foreign key to the parent customer journey store which may be used to group together more than one customer journey. The customer profile reference may be an attribute of the passenger or customer record. Thus, there may be a many-to-many association between a plurality of flight segments and each of a plurality of passengers, where the customer profile reference is one of many attributes of the passenger record.

Referring now to the flow diagram of figure 4 of the drawings, once the customer journey has been saved, stored or updated, at step 301 , the customer journey service system 127 may optionally send a booking event to a customer profile service system 129 to record in the customer profile database a reference to the booking that has been made for future use in re-calculating the value of the customer, once the flight has flown.

Subsequently, the customer may ask the travel agent to pay for the flight. The agent may use the RDT user interface running on the RDT system 113 to send the reservation identifier (referred to as the record locator, which the customer may refer to as their booking number) to the sales & servicing service system 123 which retrieves, at step 303, the customer journey record from the customer journey database via the Customer Journey service, including details of the customer profile. Thus, a customer may quote their booking number to the travel or check-in agent allowing the agent to directly retrieve the customer journey from the customer journey database.

The sales & servicing system 123 then retrieves a Payment Vault ID corresponding to the customer's preferred credit card or other payment means from the customer profile and uses this to retrieve encrypted credit card details from a Payment Vault (not shown in the schematic diagram). The sales & servicing system 123 then passes the encrypted credit card details to the ticketing system, 1 17 which may be supported on a mainframe via the HAL Host Access Layer.

The ticketing system 1 17 interacts with an external payments provider to verify the credit card, accept payment and assign a ticket number and one or more ticket coupons which are passed back to the sales & servicing system, for example via HAL. The sales & servicing system 123 then stores one or more of a ticket number and a status attribute in the Customer Journey database. This may be via the Customer Journey service so that the reservation does not become auto-cancelled when the ticketing time limit is reached. This is usually a predetermined period of time before a flight is scheduled to depart such as 1 week prior to departure. At any point the in the reservation or ticketing processes, or subsequently in the check-In process, the customer may ask an agent to reserve a particular seat number on the flight. If this happens prior to check-in, a travel agent, for example, may use the RDT user interface supported by the RDT system 1 13 to retrieve a particular customer journey from the customer journey database via the Customer Journey service. If this happens during Check-in, a check-in agent, for example, may use the DCS user interface to retrieve the customer journey, as previously described referring to the example of retrieving a customer journey record for payment of the flight. Accordingly, a customer journey associated with a particular passenger or customer profile may be retrieved from a database, at step 303. In both cases, this may be achieved by using a many-to-many association between a plurality of flight segments associated with the passenger or customer profile and a plurality different passengers or customer profiles. This is described in further detail with reference to the data model of figure 2 and the associated description below. This may be necessary, for example, if the customer has forgotten or mislaid their booking number. Furthermore, the customer may have forgotten their flight number and so the customer instead may provide the travel/Check-in Agent with enough personal information (such one of more of full name, address, and date or birth) to allow their customer profile to be identified and retrieved. The customer profile contains a reference to their customer journey which in turn allows a unique customer journey to be retrieved from the database. The customer journey may comprise references to a plurality of different customer journeys associated with a plurality of different customers. A customer journey may be identified from journey details supplied by the customer for example, date of travel and Origin/Destination.

Thus, this customer journey contains references to a plurality of different customer journeys. Each customer journey may include a number of different legs or indeed segments if the divergent itineraries rules is applied. Therefore, the many to many association may be between : a) multiple different customer journeys and multiple different legs and b) multiple different customer journeys and multiple different segments

The customer journey service system 127 then interacts with the seat service system 129 to retrieve and display a seat map for the flight to allow the customer to choose and reserve an available seat. Usually, the different service systems shown in figure 1 interact with service calls. However, many of the services are also capable of interacting

asynchronously with external service and applications, (such as other computer reservation systems (CRS), Global Distribution systems (GDS) and Departure Control Systems (DCS). These interactions may be performed by way of industry-standard messaging rather than service calls. The assigned seat number is then stored in the customer journey database by the customer journey service system 127 and is marked as unavailable in the seat map database so that it cannot be assigned to a different customer. In this way, data associated with a particular customer journey is updated in the customer journey database, at step 305. Also a reference to the customer is stored in the seats database (by the seats service) against the reserved seat so that the seat maps service may retrieve (from Customer

Journey) the details of the customers assigned to seats, when such information is needed as part of seating business processes. In other words, there may be a cross-reference. The customer has a reference to the seat allocated for each leg in their journey and the seat map for each Leg in the journey has a reference to the customers that are assigned to seats.

Each of the many flight segments associated with each customer may have one or more flight legs associated with it (more than one for multi-leg Segments). Seats are assigned to flight legs rather than flight segments which allows each customer to choose a different seat for every leg in their Journey, even when there is more than one leg in a Segment. The seats table therefore represents a many-to-many association between customers and flight legs. Each Customer may choose a different seat for each flight leg within each flight segment. Each flight leg may have many seats reserved, one for each customer in the customer journey database. Because of the database structure, it is possible for customers to reserve extra seats for any flight leg if for example they need more space or if they are carrying a large musical instrument such as a cello that needs its own seat.

In this way, the assigned seat number is stored in the customer journey database by providing a one-to-many association or relationship between a flight segment (i.e. journey) associated with the passenger or customer profile or customer journey. Accordingly, at step 305 the customer journey data is updated with customer journey or reservation data. At step 307, the updated customer journey data is stored in the database as outlined above.

As shown by the feedback loop in figure 3 of the drawings, updating of the data associated with a customer journey may be performed any number of times. Alternatively, if the customer does not want to choose their seat until they check in, then a check-in agent, for example, may use the DCS user interface to access the customer journey service in the same way as described above, to retrieve and display a seat map for the flight and allow the customer to select and reserve an available seat. Data defining the selected seat may be stored the assigned seat number in the customer journey database, as previously described.

On the day of the flight the customer arrives at the departure airport, goes to a check-in desk and gives the check-in agent their booking number. The check-in agent, for example, uses the DCS user interface running on the RDT system 1 13 to enter the booking number and retrieve the corresponding customer journey associated with the booking number which is stored in the customer journey database, along with the customer profile identifier (ID) from the customer journey database via the customer journey service system 127. In this way, the booking reference may be used, at step 303, to retrieve a particular customer journey from a database, but as previously described, embodiments of the invention may advantageously retrieve a particular customer journey from the database using data other than the booking reference, such as data uniquely identifying a particular customer. Furthermore, the booking reference may also be used to retrieve a particular customer profile identifier, ID, from the database.

A customer journey stored in the database may comprise data or links or associations with data defining all customers in the booking and all of the flight segments they have reserved. If a Homogenous Itineraries rule is enforced, every customer in a customer journey has exactly the same journey. Therefore, retrieving a customer journey from the database retrieves all of the flight segment records (i.e. the complete journey) plus all of the customers that are booked on it.

However, some embodiments may comprise a database which stores one or more different journeys in a customer journey record for each of the customers. In this case,

embodiments of the invention use a many-to-many association or foreign key between customers and flight segments in order to retrieve one or more different journeys for each customer. It should be noted that each customer may have many flight segments. Each flight segment may be reserved by one or more customers depending on whether they have some parts of their Journeys in common. . As previously described, the step 303 of retrieving a particular customer journey from the customer journey database may be achieved by using a one-to-many or many-to-many association tables or relationship between different data structures. For example a plurality of different flight segments may be associated with the passenger or customer profile or customer journey.

The sales & servicing system 123 may then use the retrieved customer profile identifier ID to retrieve the customer profile from the customer profile database via the customer profile service system 129.

At this point in the check-in process the customer profile service system 129 may optionally return one or more recommendations matched to the customer's interests and

differentiated by a determined value of the customer to the airline. Value may be determined based on flight frequency, and a numerical value may be assigned to each customer based on the determined flight frequency. The recommendations may be made to all customers of a similar value or they may be specifically designed to recover from previous disservice done to the customer e.g. a previous cancelled or delayed flight.

Recommendations may include upgrades, business class lounge access, tickets to sporting or cultural events matched to the Customer interests as recorded in their Profile or a large number of other possibilities. Since the customer's birthdate may also be stored in their customer profile, a recommendation may also be to wish the customer a happy birthday.

Having made any relevant recommendations, the check-in agent then accepts the customer's passport or other form of identification (ID) that may be relevant for the customer's travel, checks the customer's bags and takes any bag charges due. The DCS system 109 interacts with any systems supporting relevant government watch lists, sending them the passport details and the relevant security systems will return any information that could inhibit the customer from travelling. Usually, the DCS 109 indirectly interacts with watch list service systems which may then perform CRUD transactions on their databases on behalf of the DCS and return any data retrieved to DCS via one or more industry- standard messages. The DCS system may also interact with its own airline blacklists to determine whether a passenger is allowed to travel with a particular airline. Assuming the passenger is not inhibited from travelling, the form of ID along with the bags and charges are stored in the customer journey database by the DCS user interface via the customer journey service system 127, at step 307. Furthermore, the form of ID, baggage information (e.g. number of bags, charges and so on) may be stored in the database with reference to the one-to-many association between a segment (passenger journey) and a plurality of legs

Each of these items in itself represents a many-to-many relationship between customers and flight segments. A customer may use a different Form of ID for each flight segment. They may also have one or more Bags per Flight Segment and different bags for each flight segment. Each flight segment may have multiple forms of ID and bags associated, each related to different customers or the same customer. In one example, existing details stored in the customer journey database may be changed by DCS via the customer journey service system. For example, the customer may have changed their name or their name may originally have been misspelt by their travel agent, they may have changed their mind about their meal or any other preferences, they may now require medical assistance such as a wheelchair or they may even decide to change their Flight Itinerary. In such circumstances, the DCS user interface interacts with the customer journey service system 127 to store changes to details of the customer or their journey in the customer journey database and this may include changes to the reserved inventory, payments taken, tickets issued or seats reserved. Once all necessary changes have been made to the customer journey, DCS system 109 then issues a boarding pass to the customer. Once again, this is an example of how data in the customer journey database may be updated.

Then, the customer may take the boarding pass to the departure gate to gain access to the aircraft for the flight.

Once the flight has departed, the sales & servicing system 123 may send a 'Flown Event' to the customer profile service system 129. The system 129 may store data defining the flown event against the customer's profile in the customer profile database. The customer's value to the airline may then be recalculated taking into account the value of their current flight. Any Disservice such as delay or cancellation of the flight may also be recorded as an event in the customer profile database to enable the airline to recover from disservice by making recommendations for the customer in the future. In a further example, more interaction may be performed with the database, by reading from, or writing to, the database. For example, when an existing customer journey is updated, for example, the flight details changed, then the agent searches for a particular customer journey and then retrieves it into their work area in order to start editing it in the work area.

Once the edits are complete, the updated customer journey is then saved in the customer journey database as a new version of the existing customer journey. The customer journey data may comprise data defining non-flight based travel, such as bus or rail travel, tours, air taxi, ground taxi, car hire. The customer journey may also comprise details of hotel rooms booked by customers. In a similar manner, for departure control data, an existing customer journey may be retrieved from the database in order to update seat or baggage details such as seat number and number of bags, weight of bags. Figure 2 is a schematic diagram of an embodiment of the invention showing a logical level architecture of a customer journey system embodying the invention. This may be referred to as a drillable data dictionary comprising various different entities, attributes as well as relationships or associations between the different entities and different attributes.

Examples of entities are: FLIGHT LEG, FLIGHT SEG, CUST JRNY,

CUSTOMER SEGMENT, CUSTOMER LEG and CUST (Customer) flight entity,. CUST (Customer) is an important entity because it contains details of the Customer including their name and a reference to their Customer Profile.

Most of the relationships around the customer journey entity, CUST JRNY, are hidden, for clarity only, but in reality the CUST JRNY entity is the parent of most of the other entities shown in Figure 2. Further, many-to-many relationships are physically implemented with association tables, not shown in this diagram. History entities are also not shown.

CUSTOMER LOGICAL ENTITY

The customer logical entity, CUST, may be defined in relation to a customer who has booked air segments and/or other types of services in a particular customer journey

There may be more than one Customer in each Customer Journey. In some embodiments, there may be no direct Relationship with the Flight_Seg table if, for example the homogeneous itineraries rule is enforced. This rule which states that all itineraries (all of the flight_segs in a Customer Journey) must be homogenous which means that each Customer in a Customer Journey must fly on all of the Flight_Segs in the Customer Journey so it can be assumed that every Customer is related to every Flight_Seg. If one Customer in a multi-Customer Journey wants to change their itinerary relative to the others then that Customer is be split out into a different Customer Journey in order to maintain the homogenous itinerary business rule. Alternatively, a divergent itineraries rule may be enforced in which case there is a direct relationship between each customer and the Flight_Segs they want to fly. Attribute of the customer logical entity, CUST, may include a customer journey identifier attribute, CUST JRNYJD which may be a numeric datatype and which may be a key to uniquely identify a customer journey.

In addition, other attributes of the customer logical entity may be a customer identifier, CUSTJD, attribute which may be a numeric datatype and which is a surrogate primary key for the table, and a customer journey identifier attribute, CUST JRNYJD which may be a numeric datatype and which may be a key which is used to uniquely identify customer journey. Other attributes of the customer logical entity may comprise any one or more of a title attribute, TITLE which may be variable character datatype which defines the name title in local language e.g. MR, MISS, MRS, MS, DR, CHD, a given name attribute,

GIVEN NAME, which may be a variable character datatype and which defines the first name of the customer/passenger for example in the local language, a middle name attribute, MIDDLE NAME which may be a variable character datatype which defines the middle name of the customer/passenger in the local language, a surname attribute which may be a variable character datatype which defines the last name or family name for a passenger in the local language. Other attributes may include gender, birthdate, infant indicator, and last modified date which records the date when the record was modified in the database.

The customer logical entity may have one or more parent or/and child relationships with other entities. Examples of child relationships are with any one or more of the following entities: customer leg, CUSTOMER_LEG, customer segment, CUSTOMER SEG, Examples of a parent relationship may be with a customer information entity,

CUSTOMER INFORMATION CUSTOMER SEGMENT ENTITY

Referring once again to figure 2 of the drawings, this shows a CUSTOMER SEGMENT logical entity. This represents a many-to-may relationship between the CUSTOMER logical entity and the FLIGHT SEGMENT logical entity. The CUSTOMER SEGMENT logical entity may include a number of different attributes. For example, it may include any one or more of a CUSTOMER SEGMENTJD which may be a numeric data type and is a surrogate primary key, a CUSTJD which may be a numeric data type is a foreign key to the CUSTOMER table, a FLIGHT SEGJD which is a foreign key to the FLIGHT SEG table. It is part of a composite primary key for this table, a CUST JOURNEYJD key which is a key used to uniquely identify a customer journey. Other attributes, may for example, include a boarding number for a passenger and a LAST MODIFIED DATE attribute which is used to record the date the record was modified in the database.

The customer segment entity may have one or more parent or/and child relationships with other entities. Examples of parent relationships are with any one or more of the following entities: customer entity, CUSTOMER, and flight segment entity, FLIGHT SEG. CUSTOMER JOURNEY ENTITY

Figure 3 of the attached drawings provides further details of the customer journey entity, CUSTOMER JOUNEY. This represents a customer reservation of travel segments and services.

As shown in figure 3 of the drawings, the passenger or customer profile record may comprise any number of additional attributes. For example, these attributes comprise any one or more of the following attributes: CUSTOMER JOURNEYJDENTIFIER,

CUSTOMER JOURNEY_STORE_ID, CREATION DATE, RESERVATION TYPE, RECORD LOCATOR, NUMBER OF CUSTOMERS,

CUSTOMER JOURNEY LOCK DATE, AGENT DUTY CODE, STATION_CODE, CITY_CODE, COUNTRY_CODE, OFFICEJD, OFFICEJDENTIFIER,

ORGANISATION CODE, SENDER ORGANISATION CODE,

SENDER STATION CODE, DEPARTURE STATION CODE,

EXTERNAL_SENDING_SYSTEM, SITA_SENDING_SYSTEM,

SENDING_ADDRESS_REFERENCE, VERSION DATETIME, INTERNAL_PROCESSING_CODE, CJ_DELIVERED_IND, L AST M O D I F I E D_D ATE . These entities are further defined in figure 3 of the drawings.

The customer journey identifier attribute, CUST JRNYJD may be a numeric datatype and is a key used to uniquely identify a customer journey. The customer journey store identifier, CUST JRNY STORJD, may be a numeric data type and may define an optional foreign key to the parent customer journey store which is used to group more than one customer journey. The customer journey entity may have one or more parent or/and child relationships with other entities. Examples of child relationships are with any one or more of the following entities: a flight segment relationship entity which may comprise attributes defining the first flight segment identifier, a further attribute defining the second flight segment identifier, as well as the customer journey identifier.

The flight segment relationship logical entity defines relationship between two Flight Segments. This helps to find Originally booked flight segment in case of Pre-Transfer, Pre- Upgrade and Regrade scenario.

As shown in figure 2, the customer journey entity may have a number of child relationships, for example, any one or more of a BOOKING_TRANSACTION, CAR RENTAL,

FLIGHT_SEG_RELATIONSHIP, INVOICE, ITINERARY ADDRESS, ITINERARY SENT,

RESPONSIBILITY_OWNER, ROOM, TICKET REQUEST,

TRAVELLING_PARTY_MEMBERSHIP, and WORKFLOW EVENT entities.

An entity may also be referred to as a table, while an attribute may be referred to as a column or field. Entities are uniquely identified by primary keys while relationships between different entities or attributes may be determined by one or more foreign keys i.e. a key in an entity that is not the identifying Primary Key of the entity, but is rather a reference to the identifying Primary Key of a related foreign entity. The FLIGHT LEG logical entity may be associated with information about flight legs within flight segments. A flight segment can have one or more legs associated with it.

FLIGHT LEG is uniquely identified with a FLIGHT LEGJD and contains a reference to the customer journey and the version of the customer journey in which the FLIGHT LEG was created or last updated. The flight leg identifier, FLIGHT LEGJD, may be a numeric data type and may be a surrogate primary key of the table. The flight leg logical entity, FLIGHT LEG may also include a customer journey identifier attribute, CUST JRNYJD. This key is used to uniquely identify a customer journey.

The FIGHT LEG entity may include a FLIGHT LEGJD attribute which is a surrogate primary key, and may be a numeric data type. It may include a CUST JRNYJD attribute which is a key used to uniquely identify a customer journey. Other attributes of the

FLIGHT LEG logical entity may comprise any one or more of the following attributes: LEG_NUMBER attribute which may be a numeric datatype which defies the leg number within the flight segment, a DEPARTURE STATION CODE attribute which defines a Station code for Departure point of this particular leg; the station (airport) code of the location from which the aircraft will depart for the FLIGHT LEG, a

DEPARTURE CITY CODE attribute which may define a City Code of Departure Station and which references to City entity in Reference data, DEPARTURE DATETIME attribute which defines the Departure Date and Time of this particular flight leg, an

ARRIVAL STATION CODE, attribute which defines a Station code for Arrival point of this particular leg; it is CUST J the station (airport) code of the location where the aircraft will arrive for the FLIGHT LEG; an ARRIVAL CITY CODE attribute which defines the ISO City Code of Arrival Station; it references to City entity in Reference data, an

ARRIVAL DATE TIME attribute which defies the arrival Date and Time of this particular flight leg, and a L AST M O D I F I E D_D ATE attribute which records the date, the record was modified in the database.

Thus, the FLIGHT LEG entity may also contain details of the operational flight number and details of the departure and arrival city, station, terminal codes and departure/arrival date and time. Further the attributes of the FLIGHT LEG logical entity may include a last modified date entity which records the data the record was modified in the database. The customer's class of travel is also recorded and there may also an indicator to define when the Flight Leg has been locked by the Subscriber (i.e. access to the record is prevented) in the case of an Emergency event having occurred to the Flight such as a crash.

The flight leg logical entity, FLIGHT LEG may have one or more child relationships with other entities. Examples of child relationships are with any one or more of the following entities: a flight segment logical entity, FLIGHT SEG, and a customer leg logical entity, CUSTOMER LEG. This relationship is diagrammatically illustrated by the solid line linking the FLIGHT LEG and FLIGHT SEG shown in figure 2 of the drawings. The FLIGHT SEG logical entity may be associated with information which represents an air travel segment i.e. a Flight that a Passenger may make from the City of Departure to the City of Arrival. It may or may not correspond exactly to an Operational Flight_Leg but often more than one Operational Flight Leg goes to make up a Flight_Segment.

The CUST JRNY logical entity may be associated with information which represents a customer reservation of travel segments and services. Each customer journey may comprise a plurality of different reservation booking designators, RBD's. Each designator associated with a segment of a journey. In some examples, a segment may correspond to a leg of a journey. However, legs may be relevant to defining the movement of aircraft between an origin and destination, while segments may be relevant to defining the movement of passengers between what may be in some examples, a different origin and destination. Accordingly, a segment may comprise one or more legs.

For example, 3 segments may be defined as follows:

1 . London Heathrow (LHR) to Bahrain (BAH)

2. London Heathrow (LHR) to Hong Kong (HKG)

3. London Heathrow (LHR) to Singapore (SIN)

or

4. Bahrain (BAH) to Hong Kong (HKG)

5. Bahrain (BAH) to Singapore (SIN)

6. Hong Kong (HKG) to Singapore (SIN).

Therefore, an operator may sell 6 journeys or segments. Each segment may comprise a plurality of legs.

Leg1 = LHR to BAH

Leg 2 = BAH to HKG

Leg 3 = HKG to SIN.

Furthermore, we can map each of the Segments to one or more Legs :

Segment 1 maps to Leg 1

Segment 2 maps to Legs 1 and 2

Segment 3 maps to Legs 1 , 2 and 3

Segment 4 maps to Leg 2 Segment 5 maps to Legs 2 and 3

Segment 6 maps to Leg 3

Embodiments of the invention may define a relationship between a flight leg and a flight segment. The relationship may be defined by a many-to-many table linking the flight leg and the flight segment data.

The CUST JRNY logical entity ties together all information relating to a single Customer Journey. It includes an internal Identifier (CUST JRNYJD) as well as a

RECORD LOCATOR which is the Booking Number visible to Customers and which can also be interfaced to or from 3^rd party systems such as other CRS.

The CUST logical entity contains information about each Customer who has booked a Flight Segment or other service in the Customer Journey, including details such as name, gender and birthdate. Local language names may be recorded in any language including those that use non-western script characters such as Arabic or Han Chinese and other pictographic languages. Phonetic Romanised versions of non-Western names may also be stored. The FLIGHT SEG logical entity contains details of the Air Travel Segments booked by Customers in the Customer Journey. The details include the Marketing Flight Number (as the Flight may be operated by Carrier that is different to the Carrier that booked the flight for the Customers - a practice prevalent where Airlines have codesharing agreements with each other), the departure and arrival Cities and Airports and the Compartment of travel.

FLIGHT SEGMENT ENTITY

The FLIGHT SEG logical entity may comprise a number of attributes. For example, a FLIGHT SEGJD may be an attribute which uniquely identifies a flight segment with a numeric data type and may be a surrogate primary key for the table. It may also include a CUST JRNYJD which is a numeric type which uniquely identifies a customer journey. Other attributes of the FLIGHT SEG logical entity may comprise any one or more of an ORIGINAL CREATION DATE attribute which defines the original creation date for a flight segment, a DEPARTURE DATETIME attribute which defines the Date and time that the flight segment departs (in local time), an ORIGIN CITY CODE attribute, which defines the origin city code for a flight segment, a DESTINATION CITY CODE attribute which defines a destination city code for Flight Segment, a NUMBERJN PARTY attribute which specifies number in party. For Customer Journeys with a reservation type of overbooking or blocked seats, number in party stores the number of blocked seats, a NUMBER OF STOPS attribute which defines the number of stops for particular Flight Segment, e.g. If a segment has 3 legs then number of stops will be (Number of Legs - 1 ) = 2. Other attributes may comprise an ARRIVAL DATETIME attribute which defines the Date and time that the flight segment arrives at its destination (in local time), a TRAVELLING_GROUP_CODE attribute which defines Action Type Code used by Sales and Servicing system to communicate with Inventory system. This field will be used in conjunction with Booking Status, Advice_Status and Reason Type to map legacy status codes to new action code values. In this case the Action Type relates solely to changes made to the TRAVELLING_GROUP_CODE. Values are enumerated and represent e.g. ADD/UPDATE/DELETE.

The flight segment logical entity, FLIGHT SEG may have one or more parent or/and child relationships with other entities. Examples of parent relationships are with any one or more of the following entities: customer information logical entity, CUSTOMERJNFORMATION, a flight leg logical entity, FLIGHT LEG. Examples of child relationships with a customer segment logical entity, CUSTOMER SEGMENT. The solid line between FLIGHT SEG and FLIGHT LEG in figure 2 of the drawings schematically illustrates the parent relationship of FLIGHT SEG with FLIGHT LEG.

SEAT REQUEST ENTITY The seat request entity stores seat requests for group bookings. This request can be broken down further into table Seat_Req_Characteristic_Group to specify number of seats per characteristic group. A single Seat Request can be defined for a Leg or any number of Legs. A single Seat_Request can have one or many Status values. The seat request logical entity, SEAT REQUEST, may include one or more attributes. The attributes may comprise any one or more of a seat request identifier, SETA REQUESTJD which may be a numeric data type and may be a surrogate primary key of the table. It may comprise a customer group identifier which may be a foreign key to a customer group table, CUSTOMER_GROUP. It may include a customer journey identifier, CUST_JRNY_ID which is a key used to uniquely identify a customer journey. Other attributes may include a total number of seats requested attribute, TOTAL_SEATS_REQUESTED, which may be a numeric data type and defines the total seats requested as a part of a group booking. It may also include an attribute LAST MODIFIED DATE which is used to record the date the record was modified in the database. The seat request logical entity, SEAT REQUEST may have one or more parent or/and child relationships with other entities. An example of a parent relationship is with a flight leg logical entity, FLIGHT LEG. An example of a child relationship is with a customer logical entity, CUSTOMER. This relationship is diagrammatically illustrated in figure 2 of the drawings by the solid line linking the FLIGHT LEG and SEAT REQUEST as well as the solid line linking SEAT REQUEST AND CUSTOMER entity.

A seat logical entity, SEAT, may also be defined this defines the seats requested or reserved on a flight segment (FLIGHT SEG) by customers, (CUST). Attributes of the SEAT entity may comprise any one or more of a seat identifier attribute, SEATJD which may be a numeric datatype and is a surrogate primary key for the table, a flight leg identifier attribute, FLIGHT LEGJD which may be a numeric datatype and is a foreign key to the flight leg table, a customer identifier attribute, CUSTJD attribute which may be a numeric datatype and is an optional foreign key to a customer that may be associated with the SEAT.

Further attributes of the SEAT entity may include any one or more of a customer journey identifier attribute, CUST JRNYJD which may be a numeric data type and is a key used to uniquely identify a customer journey, a requested seat number attribute,

REQUSTED SEAT NUMBER attribute which defines the seat requested by the customer, and assigned seat number attribute which defines the latest assigned seat number for a customer, as well as a last modified date attribute, LAST MODIFIED DATE which is used to record the date the record was modified in the database. The seat logical entity, SEAT may have one or more parent or/and child relationships with other entities. Examples of parent relationships are with any one or more of the following entities: customer logical entity, CUST, flight leg logical entity, FLIGHT LEG, and the dashed lines connecting these entities is shown in figure 2 of the drawings. The CUSTOMER SEGMENT logical entity principally contains Passenger check-in information that may vary for each Customer by each Flight Segment. It is one of the principal entities in Customer Journey that allows the database to be used for Departure Control as well as for Reservations and it is not present in legacy systems or in other external CRS. Moreover, legacy systems and external CRS make an expedient assumption known as Homogenous Itineraries, described in further detail below, which means that every customer in the reservation is assumed to be booked to fly on every flight segment in the reservation. In this way they do not need to maintain a relationship between individual Customers and each of the Flight Segments. If one passenger in a multi-passenger Reservation changes their mind and decides to fly on a different Itinerary then in legacy systems and external CRS, they must be split into a wholly new reservation to maintain the homogenous Itineraries rule outlined above. For reasons of legacy and external compatibility, Customer Journey services also enforce the Homogenous Itineraries rule, but because CUSTOMER SEGMENT also allows many-to-many relationships to be set up between Customers and Flight Segments, it will allow the creation of Customer Journeys containing divergent itineraries where customers may fly different subsets of the flight segments in the customer journey.

This may be particularly useful for wholly hosted systems in which reservations and departure control systems are wholly hosted in a customer journey system and for whom no legacy or external compatibility is required.

The FLIGHT LEG logical entity is another entity not normally present in legacy Reservation systems or external CRS because it contains information about the route taken by the Airplane. The FLIGHT LEG logical entity may advantageously be used by a customer journey system embodying the invention because this entity is principally used by departure control systems, whose main focus is board points of flight legs as opposed to segments. Because it contains information defining aircraft movements, it contains operational flight number details (the Flight Number of the Carrier that operates the Flight, regardless of how the Flight has been marketed to Customers by any codesharing Airline). It also contains leg departure and arrival city, airport and terminal information. This information may also be mapped to a flight segment. A flight segment may be mapped to one or more flight legs.

The CUSTOMER LEG entity is another logical entity not present in legacy reservation systems or external CRS because it is designed, like FLIGHT LEG and

CUSTOMER SEGMENT, to support the functionality needed for departure control systems and a customer journey system embodying the invention advantageously define a

CUSTOM ER LEG entity for use by reservations systems.

As well as allowing many-to-many relationships to be recorded between the customers and the flight legs in the customer journey database, it also allows a different status to be recorded for each customer on each of the fight legs involved in their segments. For example, in a multi-leg segment a customer may have a different status on each of the legs within the segment, which is information that departure control systems need to manage. There are many other logical entities in a database embodying the invention which may support the reservations systems including entities that record ancillary or auxiliary services, SSRs and OSIs (Special Service Requests and Other Service Information such as meal types, medical assistance or forms of identification) and ticketing information for example. There are also many other logical entities which are designed to support departure control systems and which, for example, allow seating and baggage information to be recorded in the customer journey database.

Embodiments of the invention advantageously combine and integrate into a customer journey definition a number of logical entities designed to support reservations, including some entities that reservations has in common with departure control, with additional entities designed to support the needs that departure control systems have over-and-above the needs of reservations systems. These features may allow a customer journey system embodying the invention to be used seamlessly for both reservations and check-in or/and departure control without the need to copy data to or from an external system.

An association entity between FLIGHT SEG and FLIGHT LEG may be referred to as

FLIGHT_SEG_FLIGHT_LEG. This entity does not have any business attributes of its own because no information is managed at that level. However, the

FLIGHT_SEG_FLIGHT_LEG entity may contain the keys of the customer journey plus the key of the flight segment and the key of the flight leg that are related to each other.

In common with all other association tables in a database embodying the invention that have no business attributes of their own, this may be represented in a simplified manner as a many-to-many relationship line. This may be visualised as a line with "crow's feet" at both ends or in other words a plurality of lines which intersect at a common intersection point. The simplification in this case may also be understood as the different between a logical and a physical relationship. Logically the relationship is many-to-many but this may be physically implemented by converting it to two one-to-many relationships by way of an association table. This makes the physical database easier to query.

In the detailed model, because the FLIGHT_SEG_FLIGHT_LEG association entity contains the keys for both flight segments and flight legs it may allow those keys to be associated with each other so a flight segment may be associated with many flight legs and a flight leg may be associated with many flight segments.

In some embodiments, it may be preferable for a flight segment to be associated with many flight legs but note that a flight leg is also associated with many flight segments.

Homogeneous Itineraries rule

For example, an airline system may require the use of a homogenous itineraries rule in which each customer in a customer journey must fly every segment in the customer journey. This rule limits the associations so that a single customer journey flight leg can only be associated with a single fight segment. Further, sequential segments in a journey may be defined so that they do not overlap with each other. In this way segments may be defined so that they do not have legs in common, because each leg may be uniquely associated with a particular point in time, and therefore, such a defined leg may be only associated with one segment of a journey. Accordingly, it will be appreciated that the many-to-many relationship may be

asymmetrical. For example, the particular number of different flight segments associated with the FLIGHT SEG attribute and the particular number of flight legs associated with the FLIGHT LEG attribute may be different. Divergent itineraries rule

Embodiments of the invention may advantageously associate a flight leg with multiple flight segments. This may allow for support of a divergent itineraries rule in which each customer in a customer journey may fly different segments, some of which may overlap with each other and which therefore may have legs in common. So in other words, a plurality of different customer journeys associated with different customers may have a common leg. The two different customer journeys may be visualised as a u-shape and inverted u-shape which are joined for the common leg. Thus, a plurality of different customer journeys may, but do not necessarily have to comprise common legs or even common segments

For example, the different customer journeys do not need to have common legs or common segments if they relate to entirely separate itineraries. In the above example, if one Customer was flying Segment 2 LON to HKG and another was flying Segment 5 BAH to SIN then they would have Leg 2 BAH to HKG as a common Leg between the two Journeys. If one Customer was flying Segment 1 LHR to BAH followed by another Segment 5 BAH to SIN while another Customer was only flying Segment 5 BAH to SIN then they would have Segment 5 in common. Equally, if one Customer was flying Segment 1 LHR to BAH and another was flying Segment 5 BAH to SIN then they would have no Segment or Leg common between their Journeys, although it is possible they could briefly spot each other in BAH as they'd be in the same Airport at the same time, one arriving and the other departing. Final example - one Customer flies Segment 1 LHR to BAH and another Customer flies Segment 6 HKG to SIN - not only would they have no part of their Journey in common they would not even be in the same airport at the same time so they would not be able to spot each other either.

The following description illustrates how indexes in a physical database enable fast access to records.

Based on the Logical Model, Physical Models and Physical Databases may be produced for multiple RDBMS platforms (Relational Databases) such as Oracle, DB2, Teradata &etc. Physical Models may include physical storage parameters particular and unique to each RDBMS platform such as Space Allocation, Partitioning and Sub-Partitioning, degree of Disk Cylinder packing and amount of Free Space for inserting new data.

Indexes and Constraints defined by the physical database designer (based on the Logical Model) and managed by the RDBMS software may be created to enforce Relational aspects of the Logical Model such as unique identifiers for Tables (which correspond to Primary Keys in the Logical model) and Relationships between tables (which correspond to Foreign Keys in the Logical model). For example, Customer Journey records must be uniquely identifiable by way of the CUST JRNYJD which is the unique Primary Key of the CUST JRNY table and its uniqueness is enforced in Physical Databases by a unique Index and unique Constraint. Customer records must refer to the Customer Journey they belong to by way of the CUST table containing a reference to the CUST JRNYJD. A Foreign Key constraint in the physical databases ensures that the CUST JRNYJD reference in the CUST table must exist in the CUST JRNY table. In this way the uniqueness of individual records and the 'referential integrity' of the relationships between tables is maintained and ensured in the physical data Looking up these Primary and Foreign Key Indexes provides fast access to individual records or sets of records in tables. Indexes may also be created on other columns in a table to provide a quick reference to records, for example Indexes can be created on the Name columns in the CUST table to provide quick access to Customer records whose name matches the searched-for Name. Further refinement is possible by the creation of phonetic indexes to allow fast access to records where the Name sounds like the searched-for Name.

Indexes in Physical Databases work very much like Indexes in a book where the occurrences of particular words on the pages they appear on are listed. To search for a particular word or phrase in a book, one searches the index to find the pages it occurs on and which enables a fast lookup of each page. This is much quicker than searching through the entire book for the word or phrase. Similarly in a database, one can search an Index for occurrences of a particular data item - the indexes contain the unique references of each record that the data item occurs on enabling fast access to the searched-for records, much faster than searching through entire tables which may contain many millions of records. Internally in the RDBMS the unique indexed reference of each record is associated with the physical location of the record on a disk or other electronic storage media, enabling the RDBMS to access the record directly via the disk file-system rather than having to read the entire disk to find the searched-for records.

Embodiments of the invention may use software tools may to create a physical model from the Logical Model (such as ERStudio Data Architect by Embarcadero) and such tools may also be capable of automatically generating the code needed to create a physical database. The code may be written in a particular sub-category of industry-standard SQL (Structured Query Language) called DDL (Data Definition Language). Although SQL and DDL are standard and most RDBMS platforms support the ANSI standard, each platform may also have its own variations and extensions of the standard in order to support the physical storage and instantiation features that are unique to each RDBMS platform.

Therefore the exact code needed to define Tables, Indexes and Constraints has many common features between RDBMS platforms but will usually vary in some details between platforms when Physical Database Designers want to take advantages of features that are unique to a platform.

The following description illustrates how interdependencies between the plurality of different domains or systems is achieved to ensure data consistency.

In Service-Relational architecture, each Service along with its database schema may be independently deployed. This means the database could be deployed on different computers or even on different RDBMS platforms. Referential Integrity of any

interdependencies between Services therefore cannot be maintained at the Database level; instead they are managed by the Business Logic layer of the Service. For example, Customer Journey depends on Locations data such as City Codes and Airport Codes which are managed by an independent Locations service. Customer Journey must ensure that the Journeys it creates use correct City and Airport Codes so the Customer Journey Service calls the Location Manager Service to retrieve Locations data. The Location Manager business logic layer retrieves the Locations data from its own Locations database and sends the data back to the business logic layer of the Customer Journey service which then uses the data to create Journeys (which of consist of a set of Flight Segments and Flight Legs) that are stored in the Customer Journey database. Locations data may be cached locally by the Customer Journey Service to facilitate high performance by reducing the frequency with which it has to communicate with the Location Manager service.

Embodiments of the invention may comprise a plurality of different systems such as reservations and departure control systems which share the customer journey database. Thus, the reservations system may be communicatively coupled to the customer journey database. Further, the departure control system may be communicatively coupled to the customer journey database.

This may be achieved by having one instance of data entities that Reservations and DCS systems have in common which enables the Single Customer Journey shared between reservations and DCS for Subscribers who's Reservations and DCS capabilities are both Hosted by SITA. Further, embodiments of the invention may also be compatible with airlines who want to use the reservations system as previously described in conjunction with an external DCS.

From the foregoing, it will be appreciated that the mobile communication or client device may include a computing device, such as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a mobile telephone, a smartphone, a kiosk, an internet enabled television, an internet enabled television receiver, an internet enabled games console or portable games device. The server may comprise a computer processor running one or more server processes for communicating with client devices. The server processes comprise computer readable program instructions for carrying out the operations of the present invention. The computer readable program instructions may be or source code or object code written in or in any combination of suitable programming languages including procedural programming languages such as C, object orientated programming languages such as C#, C++, Java, scripting languages, assembly languages, machine code instructions, instruction-set- architecture (ISA) instructions, and state-setting data.

The wired or wireless communication s networks described above may be public, private, wired or wireless network. The communications network may include one or more of a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephony communication system, or a satellite communication system. The communications network may comprise any suitable infrastructure, including copper cables, optical cables or fibres, routers, firewalls, switches, gateway computers and edge servers.

The system described above may comprise a Graphical User Interface.

Embodiments of the invention may include an on-screen graphical user interface. The user interface may be provided, for example, in the form of a widget embedded in a web site, as an application for a device, or on a dedicated landing web page. Computer readable program instructions for implementing the graphical user interface may be downloaded to the client device from a computer readable storage medium via a network, for example, the Internet, a local area network (LAN), a wide area network (WAN) and/or a wireless network. The instructions may be stored in a computer readable storage medium within the client device. As will be appreciated by one of skill in the art, the invention described herein may be embodied in whole or in part as a method, a data processing system, or a computer program product including computer readable instructions. Accordingly, the invention may take the form of an entirely hardware embodiment or an embodiment combining software, hardware and any other suitable approach or apparatus.

The computer readable program instructions may be stored on a non-transitory, tangible computer readable medium. The computer readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk.

Exemplary embodiments of the invention may be implemented as circuit board which may include a CPU, a bus, RAM, flash memory, one or more ports for operation of connected I/O apparatus such as printers, display, keypads, sensors and cameras, ROM, a communications sub-system such as a modem, and communications media.

The flowchart of Figure 4 illustrates the operation of an example implementation of systems, methods, and computer program products according to various embodiments of the present invention. Each block in the flowchart or block diagrams may represent a module comprising one or more executable computer instructions, or a portion of an instruction, for implementing the logical function specified in the block. The order of blocks in the diagram is only intended to be illustrative of an example. In alternative

implementations, the logical functions illustrated in particular blocks may occur out of the order noted in the figures. For example, two blocks shown as adjacent one another may be carried out simultaneously or, depending on the functionality, in the reverse order. Each block in the flowchart may be implemented in software, hardware or a combination of software and hardware.

Furthermore, from the foregoing it will be appreciated that embodiments of the invention may also be used by airport infrastructure operators who may wish to use a customer journey system. The following numbered clauses are hereby included to further illustrate aspects of the invention:

1 . A computer-implemented customer servicing method comprising a processor configured to:

a. construct a customer reservation for a customer journey between an origin and destination;

store the reservation in a memory;

wherein the reservation comprises a plurality of legs and wherein a segment is associated with the plurality of legs.

The computer-implemented customer servicing method according to clause 1 further comprising storing a plurality of different customer journeys in the memory.

The computer-implemented customer servicing method according to any preceding clause further comprising storing a plurality of different customer journeys in the memory and wherein at least some of the journeys are associated with different customers.

The computer-implemented customer servicing method according to any preceding clause further comprising storing a plurality of different customer journeys in the memory, wherein at least some of the journeys are associated with different customers and wherein a plurality of segments associated with the or a customer are associated with a plurality of legs associated with the or a further customer.

The computer-implemented customer servicing method according to any preceding clause further comprising determining a customer profile associated with the customer.

A user servicing system, and in particular a reservations or/and departure control system comprising:

a. processing means configured to construct a customer reservation for a customer journey between an origin and destination;

b. storage means for storing the reservation;

wherein the reservation comprises a plurality of legs and wherein a segment is associated with the plurality of legs. A computer readable medium which when executed undertakes the method of preceding method clause.

Claims

1 . A customer servicing system comprising:

a. a server or means for associating a reservation for a customer journey between an origin and destination with a customer journey profile record for the customer;

wherein the customer journey profile record comprises data defining the journey between the origin and destination, the data associated with further data defining the journey via at least one point connecting the origin and destination.

The system of claim 1 wherein wherein the customer journey comprises a journey segment comprising a plurality of legs.

The system of any preceding claim wherein a plurality of different customers are associated with the journey.

The system of any preceding claim wherein the customer journey profile record comprises any one or more of data defining: the origin, destination, number of legs, number of segments, and data defining the customer and preferably wherein a customer journey service system (127) is configured to retrieve a customer journey profile record from a database comprising a plurality of differenet customer profile records based on matching one or more of the data defining the customer journey profile record.

The system of any preceding claim wherein the reservation comprises any one or more of information which identifies one or more customers, a record locator that uniquely identifies the customer journey, seat requests, special services, meal type required, medical assistance, forms of identification, additional or auxiliary travel services such as bus or rail travel, hotel reservations, ticketing details, and boarding details.

The system of any preceding claim further comprising storage means for storing a plurality of different customer journeys.

7. The system of any preceding claim wherein at least some of the journey(s) are associated with different customers.

8. The system of any preceding claim wherein the or a plurality of different customer journeys are associated with a different origin or/and destination.

The system of any preceding claim wherein the or a plurality of different customer journeys are associated with the same origin or/and destination.

10. The system of any preceding claim wherein a plurality of segments associated with the customer are associated with a one or more legs associated with a further customer.

1 1. The system according to any preceding claim further comprising a customer profile service system (129) configured to identify a customer profile associated with the customer using any one or more of customer name, date of birth, address, passport number, and frequent flyer number and preferably wherein the customer profile service system is configured to retrieve a customer profile from a database comprising a plurality of different customer profiles based on matching one or more of the data defining the customer profile.

The system according to any preceding claim further comprising a customer journey service system (127) configured to call a customer profile service system (129) using a service call.

The system according to any preceding claim further comprising generating an object-oriented database update statement and mapping the statement to the the or a database to update the database.

14. The system according to claim 1 1 wherein the customer profile service system

(129) is configured to retrieve a unique customer profile from the database by performing a service call.

15. The system according to any preceding claim wherein the or a customer journey service system (129) is configured to retrieve a plurality of different customer profiles associated with the customer journey from the database by performing a service call.

16. The system of any preceding claim wherein the customer journey record comprises a key associated with data defining one or more services.

17. The system of claim 16 wherein the key comprises a foreign key defining a many- to-many association between any one or more of:

a. a plurality of flight segments or a plurality of flight legs and a plurality of different customer profiles or passengers:

b. a plurality of flight segments or a plurality of flight legs and a plurality of different customer journeys.

18. The system of any preceding claim wherein the customer journey profile record further comprises any one or more of data defining a customer name, data of birth, address, passport number and frequent flyer number.

19. The system of any preceding claim further comprising means for uniquely

identifying a customer profile record for the customer from a plurality of different customer profile records based on any one or more one or more of data defining a customer name, data of birth, address, passport number and frequent flyer number.

20. The system of any preceding claim further comprising a plurality of different

reservations and further comprising means for uniquely identifying one reservation based on a booking reference.

21 . The system of any preceding claim wherein the customer journey profiled record further comprises data defining the customer's journey and in particular any one or more of the origin, destination, data defining the legs and segments comprising departure time and date, arrival time and date, departure or arrival location or airport or terminal.

22. The system of claim 1 further comprising means for defining a plurality of different services associated with the or a further customer.

23. The customer servicing system according to any preceding claim further comprising means for sending data to or receiving data from a reservations system.

24. The customer servicing system according to any preceding claim further comprising means for sending data to or receiving data from a departure control system.

25. The customer servicing system according to any preceding claim wherein, in response to a customer interacting with any one or more of a reservations system, a departure control system, a ticketing system and a flight operations system, the receiving means receives updated data associated with the customer journey.

26. The customer servicing system according to any preceding claim wherein, in

response to a customer interacting with an airport or transportation hub, the receiving means receives updated data associated with the customer journey and in particular in which the data comprises any one or more of a passenger name, age category information, flight number, destination, compartment, status, inhibit information watch lists, payments, a record locator associated with their reservation and seat number and information indicating whether a passenger has boarded a flight.

27. The customer servicing system according to any preceding claim further comprising means for performing a service call to the or a database or storage means for storing the data.

28. The customer servicing system according to any preceding claim further comprising a server or means for proving one or more services communicatively coupled to a relational database at a service level.

29. The system of any preceding claim further comprising a reservations system and a departure control system.

30. The system of claim 1 further comprising communications means for receiving the reservation from a reservations system.

31 . The system of any preceding claim further comprising a sales and servicing system (123) coupled to the or a customer journey service system (127) and preferably wherein the sales and servicing system (123) is coupled to a product, fare and pricing system (125) configured to provide a plualiy of different flight options and fares.

32. The system of claim 31 wherin the sales and servicing system (123) is coupled to the products fares and prising sytem via the or a reservations desktop (1 13).

33. The system of claim 31 whrein the customer journey service system (127) is configured to access the or a customer journey database to retrieve one or more customer journey records.

34. The system of claim 30 in which the products fares and pricing system (125) is coupled to an inventory servicing system (1 19) for determinig the availability of a plurality of flight options.

35. The system of any preceding claim in which the or a sales and servicing system (123) is further configured to:

a. reserve airline inventory for a selected one of the plurality of flights;

b. decrement the remaining inventory for the flight; and

c. communicate, the completed reservation to the or a customer journey

service system (127) for saving in the database.

36. The system of any preceding claim further comprising a reservations or/and

departure control system comprising:

b. storage means for storing the reservation;

37. A customer servicing system comprising:

a. a server or means for storing a reservation for a customer journey between an origin and destination, the reservation associated with a customer journey profile record for the customer;

b. a departure control system coupled to the storage means or server via the customer servicing system;

wherein the customer servicing system is configured to receive updated data defining the customer journey in response to the customer interacting with one or more services associated with a travel hub.

38. A customer servicing method comprising:

a. associating a reservation for a customer journey between an origin and destination with a customer journey profile record for the customer; wherein the customer journey profile record comprises data defining the journey between the origin and destination, the data associated with further data defining the journey via at least one point connecting the origin and destination.

39. A customer servicing method comprising:

a. storing a reservation for a customer journey between an origin and destination, the reservation associated with a customer journey profile record for the customer;

b. receiving updated data defining the customer journey in response to the customer interacting with one or more services associated with a travel hub.

40. A computer program product or computer readable medium which when executed undertakes the system of any preceding claim.