The invention relates to a system architecture for calculating flight data for an end user and providing output of the flight data to the end user.

End users looking up flight data typically do so via a website or terminal of an airline. This website or terminal comprises a user interface into which the user can enter parameters. A user can thus typically enter a destination and a desired moment of departure and/or arrival. The interfaces and/or terminals of the airlines are configured to calculate flight data such as available flights, time of the available flights, prices of the available flights, and so on and to provide them to an end user as output.

When an end user wishes to obtain more specific data, for instance in respect of luggage or in respect of availability of seats for small children or for people with physical limitations, the end user must first get in touch with an employee of the airline. The airline employee has to gather the relevant information and on the basis thereof communicate the specific flight data to the end user.

Many of such specific flight data depend on a plurality of factors, which are determined by multiple companies and organisations and regulations. The availability of seats for pets can thus depend on both the type of aircraft and on airline policy, as well as on the regulations in the countries of destination and departure, as well as on the number of pets already booked on the flight, and so on. It has been found difficult in practice to give an end user an up-to-date, correct answer regarding such specific flight data.

Because of this, a drawback of the existing systems is that specific flight data are only up- to-date the moment that they are sent to the end user by the airline employee. This leaves the end user little time to make a choice and/or to find and/or consider alternative solutions. A further drawback relates to the complexity of the website or terminal. The website or terminal is configured to retrieve up-to-date data in respect of the flights. For this purpose one or more external databases and the website or terminal are coupled. The complexity of the website makes it difficult for the airline to adjust up-to-date flight data, for instance prices, quickly on the basis of trends. Even when no specific flight data can be calculated via the website or terminal, the system remains complex.

It is an object of the invention to provide a system architecture with which an end user can obtain up-to-date flight data quickly and efficiently, and wherein maintenance of and modifications to the flight data by the operator are simpler.

The invention provides for this purpose a system architecture for calculating flight data for an end user and supplying the flight data as output to the end user, wherein the system architecture compnses: - a user module configured to be executed by a processor of a user device, which user module comprises a user interface configured to allow entry of a plurality of user parameters by the end user and to supply the flight data as output on the basis thereof;

- an operator module configured to be executed by a server and comprising a rules engine in which at least one algorithm is stored, which server is operatively coupled to at least two external databases, and wherein the at least one algorithm has factors which are related to the plurality of user parameters and has further factors which are related to predetermined data from several of the at least two external databases;

wherein the user module is operatively connected to the rules engine of the operator module in order to send the plurality of user parameters and to receive an outcome of the at least one algorithm and determine the flight data on the basis thereof.

In the system architecture according to the invention a user module and an operator module are separated. The operator module comprises a rules engine in which the algorithms for calculating flight-related data are stored. The operator module is coupled to a plurality of external databases, and the algorithms comprise factors from these databases. This simplifies the user module, i.e. the user module need not comprise the algorithms itself and need not comprise the coupling to the external databases itself. When a user enters user parameters via the user module, the user module will execute the algorithm via the operator module and will be able to supply up- to-date flight data to the user. A user will hereby be able to request relevant up-to-date information in respect of flights. The system architecture further allows other applications to make use of algorithms in the rules engine. Applications such as booking engines or virtual marketplaces can hereby request information via the rules engine. This opens up further possibilities for

commercializing flight data.

The setting up and maintenance of the user module become considerably simpler for an operator. Because the user module makes use of algorithms in the rules engine, it becomes possible to influence the outcome of a plurality of separate calculations in the user module by modifying one algorithm in the rules engine. This is because the plurality of separate calculations can retrieve the one algorithm from the rules engine for the purpose of calculating the flight data. The skilled person will appreciate that in a traditional website or terminal the calculation would have to be modified separately for each aspect.

The system architecture preferably comprises an operator interface configured to be executed by a processor of an operator device, which operator interface is configured to create, modify and remove algorithms in the rules engine. The operator interface will here preferably be configured to show user parameters as output and to show the predetermined data from several of the at least two external databases as output, and a selection module is provided for selecting user parameters and/or predetermined data as factor in an algorithm. The operator module provides a simple and user-friendly mechanism for composing and modifying algorithms. For this purpose the operator interface is provided to show the possible factors of the algorithm to the operator. The possible factors comprise user data. User data are the data which can be entered into the user module by a user. Factors also comprise the predetermined data from external databases. The skilled person will appreciate that not all of the user parameters and/or predetermined data need to be shown simultaneously, but that they can be shown in different windows or menus. An operator can compose or modify an algorithm in simple manner, without having considerable knowledge of programming, via the operator interface. Maintenance of the system is hereby greatly simplified. It also becomes easier to respond to trends, because an operator can modify an algorithm in simple manner.

The user module is preferably provided for the purpose of calculating a plurality of different flight data, and the user module is configured for each of the plurality of different flight data to allow entry of related user parameters by the user and to select a predetermined algorithm from the rules engine. A user may be interested in different types of information related to a flight. As already elucidated above, a user may be interested in luggage-related aspects or be interested in the availability of seats for small children or people with physical limitations. A user may also be interested in the availability of seats for pets. For each of these aspects the user module is provided to allow the user to enter related user parameters. The module is also configured to select the algorithm from the rules engine of the operator module, on the basis of which the flight data can be calculated.

The operator module is preferably provided to execute the algorithm and send the outcome to the user module. This simplifies the user module further, because it receives outcomes from the operator module. The user module itself need not perform any calculations of note.

The operative coupling of the server to at least two external databases preferably further comprises an intermediary module for translating at least the predetermined data from several of the at least two external databases into a predetermined format. Airlines work with different suppliers for data provision. The external databases are typically databases of external suppliers. These databases are built with a supplier-specific structure. Providing an intermediary module which translates the data of the supplier into a predetermined format makes it considerably easier to switch suppliers. This is because the algorithms in the rules engine can make use of data in the predetermined format. Owing to the intermediary module, the predetermined format is independent of the supplier-specific structure. Because the data are translated into the predetermined format, no or no notable modifications need be made to algorithms when a different external database is coupled. This simplifies the maintenance of the system considerably. Airlines hereby gain more freedom to switch suppliers, because the impact on their systems for the end user is minimal. The operator module preferably further comprises an operator database, and the algorithm comprises a factor from the operator database. Airline-specific data can be stored in the operator database. By including these data in the algorithm it becomes possible in simple manner to make airline-specific modifications. When calculating an additional luggage charge, an airline can thus for instance decide to grant a temporary discount. This discount is entered into the operator database. The algorithm which calculates the price will also apply this discount. Without making any modification to the user module and without making any modification to the algorithm, the user can be provided with up-to-date information which is airline-specific. This example illustrates how the system architecture according to a preferred embodiment of the invention provides a flexible, dynamic and simple mechanism for the operator to provide a user with highly specific flight data.

The invention further relates to a method for calculating flight data for an end user, and supplying the flight data as output to the end user, wherein the method comprises of:

the end user entering a plurality of user parameters via a user interface of a user module, configured to be executed by a processor of a user device;

the user module sending the plurality of user parameters to an operator module, configured to be executed by a server and comprising a rules engine in which at least one algorithm is stored, which server is operatively coupled to at least two external databases, and wherein the at least one algorithm has factors which are related to the plurality of user parameters and has further factors which are related to predetermined data from several of the at least two external databases, wherein the user module is operatively connected to the rules engine of the operator module;

receiving an outcome of the at least one algorithm and determining the flight data on the basis thereof;

supplying the flight data as output to the end user.

The effects and advantages of the method for the invention are similar to the effects and advantages described above in respect of the system architecture.

The method preferably further comprises of retrieving a factor of the algorithm from an operator database of the operator module.

The method preferably further comprises of translating data from several of the at least two external databases into a predetermined format.

The method preferably further comprises of creating, modifying and/or removing algorithms in the rules engine via an operator interface, configured to be executed by a processor of an operator device.

The invention will now be further described on the basis of an exemplary embodiment shown in the drawing. In the drawing: figure 1 shows a system architecture according to a preferred embodiment of the invention; and

figure 2 shows an embodiment of an operator interface.

The same or similar elements are designated in the drawing with the same reference numerals.

In this description the term end user should primarily be broadly interpreted. More specifically, a person can be deemed the end user, but so can an application. It is understood here that both an end user and an application can request information via a so-called web service callback. Even when the end user is interpreted narrowly as a person, an application will still be able to request information via the same mechanism.

Figure 1 shows a system architecture 1 according to a preferred embodiment of the invention. Figure 1 shows the user module 2 on the right. The user module can be embodied as terminal or as web application or as smartphone app. The skilled person will appreciate that user module 2 can be developed in different ways and can be executed on different devices. User module 2 is preferably a software application configured to be executed on a processor of a user device. The user device preferably further comprises a screen for output of information to the user. The skilled person will appreciate that other means and mechanisms for exporting information can also be applied, for instance a loudspeaker with which a spoken message to the user can be played.

User module 2 comprises a user interface 5 with which a user can enter user parameters, this is illustrated with arrow 6. User interface 5 is also configured to supply an output 7. Output 7 is related to flight data which are requested by the user. More specifically, a user will typically enter user parameters 6 which are related to a flight and with which the user requests

predetermined flight data. Flight data can relate to departure and arrival times of flights, relevant airports, availability on a flight, price of a ticket, a service related to a flight or ticket, or other flight-related matters. User module 2 further has a coupling 8 whereby user module 2 is operatively coupled to an operator module 3 for the purpose of exchanging data. The exchange of data is illustrated with arrows 9.

Operator module 3 typically runs on a server of the airline. Alternatively, operator module 3 runs in a so-called cloud. Operator module 3 is coupled to a plurality of external databases 4. The external databases 4 contain data which an airline purchases or which are supplied to the airline by external parties. These data can relate to luggage handling, the weather, flight data of competing airlines, regulations, aircraft characteristics, and so on.

An intermediary module is preferably provided between each external database 4 and the operator module 3. The intermediary module is provided for translating the data of external database 4 into a predetermined format. The intermediary module can be provided as an intermediary database which is synchronized with the external database 4 and wherein the structure and the format of the intermediary database is predetermined. Alternatively, the intermediary module can be provided as a translation software which facilitates an exchange of data between operator module 3 and external database 4. Both options allow operator module 3 to receive data according to a predetermined format.

Operator module 3 comprises a rules engine 10. Operator module 3 preferably also comprises a core engine (not shown). The core engine and the rules engine 10 can be on the same or on different servers. A plurality of algorithms 11 are stored in rules engine 10. The algorithms 11 of rules engine 10 can be created, removed and modified via an operator interface 12. The operator interface 12 allows input of an operator as shown with arrow 13, and supplies output parameters 14 to an operator.

Operator module 3 further comprises an operator database 15. Data can be stored in this operator database with the objective of influencing an outcome of an algorithm 11. A price elasticity can for instance be implemented in very simple manner with this operator database 15. Price elasticity relates to an operator adjusting a predetermined price quickly, temporarily and under determined conditions. By providing a price elasticity mechanism which is easily implemented, an airline can achieve considerable commercial advantages. Several examples of an algorithm 11 are given hereinbelow. Herein:

DB relates to data which are requested from an external database 4;

GP relates to user parameters 6 which are sent on 9 via the user module;

OD relates to data coming from operator database 15.

First example: algorithm for calculating an availability of a seat on a predetermined flight for several persons with physical limitations:

DBl(DB2(GPl)) - DB3 - GP2 =/> 0

DB 1 is the total number of seats for persons with physical limitations for a specific type of aircraft;

DB2 is the type of aircraft deployed for the predetermined flight;

GP1 indicates the predetermined flight;

DB3 is the number of seats for persons with physical limitations already booked; and

GP2 relates to the number of seats for which the user is checking availability.

On the basis of the above explanation the skilled person will appreciate that when an outcome of the algorithm is 0 or greater than 0, there are still enough seats and the user can obtain a positive output. More specifically, the user can be informed that the requested number of seats for persons with physical limitations is still available on the flight.

Second example: algorithm for calculating a price for additional luggage on a

predetermined flight.

DB4(DB5(GPl) + DB6(DB7(GPl) + DB8(GPl) - OD DB4 relates to the cost for luggage handling at the destination airport;

DB5 is the destination airport;

GP1 is the predetermined flight;

DB6 relates to the cost for luggage handling at the departure airport;

DB7 is the departure airport;

DB8 is the cost for the luggage on the flight; and

OD is the discount registered in the operator database by the operator.

On the basis of the above explanation the skilled person will appreciate that a cost price is calculated on the basis of costs of multiple parties. The skilled person will further appreciate that a discount is applied on the basis of what is registered in the operator database. For the sake of simplicity of this explanation conditions in respect of the discount have been omitted. These may be included in the algorithm. The skilled person will also appreciate that modifying the data in operator database 15 will have a direct effect on the outcome of the algorithm, without a modification of the algorithm having to be implemented for this purpose. This is because, if OD is set to zero, this term will no longer have an effect in the algorithm.

Figure 2 shows an embodiment of an operator interface. Figure 2 shows that an operator interface 12 shows different types of information to the operator. Operator interface 12 thus shows items from databases 4. This is illustrated schematically in the figure with blocks. Each block will typically display one or more information items to the operator. Examples of such information items start with DB above. More specifically, these information items relate to dynamic information which can be retrieved from external databases 4.

In addition to data from databases 4, operator interface 12 preferably also shows functions 16 to the operator, which functions 16 can be used by the operator to build the algorithms.

Examples of functions are if-then, or greater or smaller, or plus or minus. The skilled person will appreciate that this is only a very small selection from the total number of known functions. The invention is not limited to the examples given here.

Operator interface 12 further also shows user parameters 6 to the operator. As elucidated above, the user parameters can also be used in the algorithm. Examples of such user parameters start with GP above. More specifically, these user parameters relate to dynamic information which is entered by a user.

Items from the operator database 15 are also shown to the operator. It will be apparent to the skilled person that not all items are necessarily shown to the operator simultaneously, and that the operator has access to the different information blocks via a menu or structure in the user interface. Algorithm 11 is further show to the operator. It will be apparent that in a determined menu the operator also has the option of seeing the different algorithms, selecting an algorithm for the purpose of modifying it, or removing algorithms. A function is also provided for creating new algorithms.

When calculating flight data, user module 2 can be configured to select a predetermined algorithm from rules engine 10. The selection is communicated via coupling 8. Operator module 3 is preferably provided for executing the selected algorithm using the exchanged data 9 and the data from databases 4 and 15. The outcome of the algorithm is once again exchanged 9 to user module 2. This result can be sent on in a manner such that it can be showed directly to a user by user interface 5. Alternatively, flight data are calculated on the basis of the outcome.

The specific structure of the system architecture as shown in figure 1 provides significant advantages because the calculation of the flight data is controlled centrally by the rules engine. Building of user module 2, and more specifically the user interface 5, will be considerably simpler because an algorithm can be selected for determining the flight data. It is hereby no longer necessary to create couplings in user module 2 to external databases. The implementation of price elasticity is also simplified significantly. When algorithms 11 are built with a price elasticity component, more specifically a component which refers to operator database 15, the operator can modify the outcome of the algorithm by adding or removing data in database 15. This means that no modifications need be made to user module 2 in order to apply price elasticity. Because user module 2 requires no couplings to external databases in order to calculate flight data, it becomes possible to make up-to-date calculations of considerably more complex flight data, and to supply them as output to a user.

The present invention can be executed in other specific devices and/or methods. The described embodiments should be deemed purely illustrative and non-limitative in all respects. In particular, the scope of protection of the invention is defined by the appended claims rather than by the description and figures. All modifications falling within the meaning and the scope of equivalence of the claims must be deemed as lying within the scope of the claims.

It will be readily apparent to the skilled person that steps of different above described methods can be executed by programmed computers. Some embodiments are here also intended to comprise program storage devices, for instance digital data storage media which are readable by a machine or by a computer and comprise machine-executable or computer-executable programs of instructions, wherein the instructions execute some or all of the steps of the above described methods. The program storage devices can for instance be digital memories, magnetic storage media such as magnetic disks and magnetic tapes, hard drives or optically readable digital data storage media. The embodiments are also intended to comprise computers programmed to execute the steps of the above stated methods.

The description and the drawings only illustrate the principles of the invention. It will thus be apparent that the skilled person will be able to envisage different setups which, although they are not explicitly described or shown here, embody the principles of the invention and are encompassed within its scope. All examples mentioned herein are furthermore intended substantially solely for educational purposes, to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) in order to improve the technique, and must be understood as being without limitation to such specifically mentioned examples and conditions. All statements herein describing principles, aspects and embodiments of the invention and specific examples thereof are furthermore intended to comprise equivalents thereof.

The functions of the different elements shown in the figures, including possible functional blocks labelled“processors”, can be provided by the use of application-specific hardware and hardware which is able to execute software in combination with suitable software. When provided by a processor, the functions can be provided by a single dedicated processor, by one single shared processor, or by a plurality of individual processors, some of which can be shared. Explicit use of the term“processor” or“controller” must furthermore not be understood as relating only to hardware which is able to execute software, and can implicitly, without limitation, comprise hardware for digital signal processor (DSP), network processor, application-specific integrated circuit (ASIC), field programmable gate array (FPGA), read-only memory (ROM) for storing software, random access memory (RAM) and non-volatile storage. Other hardware, conventional and/or custom, can also be included. Similarly, all switches shown in the figures are merely conceptual. Their function can be executed by the action of program logic, by dedicated logic, by the interaction of program control and dedicated logic, or even manually, wherein the specific technique can be selected by the implementer, as understood from the context.

It will be apparent to the skilled person that all block diagrams herein represent conceptual diagrams of illustrative circuits which embody the principles of the invention. Likewise, it will be apparent that all flow diagrams, state transition diagrams, pseudocode and the like represent different processes which can be represented substantially in a computer-readable medium and are thus executed by a computer or processor, irrespective of whether or not such a computer or processor is shown explicitly.

The skilled person will appreciate on the basis of the above description that the invention can be embodied in different ways and on the basis of different principles. The invention is not limited here to the above described embodiments. The above described embodiments and the figures are purely illustrative and serve only to increase understanding of the invention. The invention is not therefore limited to the embodiments described herein, but is defined in the claims.