ES2773654T3 - Airplane to ground communication - Google Patents

Abstract

A method for data communication from an on-board server (2) that is installed in an aircraft (1) and that is coupled through a wireless interface (4) to a server on the ground (3) that is located remotely with respect to the aircraft (1), the method comprising: - receiving, by the on-board server (2) from the ground server (3), executable application code and user data prior to take-off of the aircraft (1), in which at least a first part of the executable application code refers to an on-board server operating system (2) and at least a second part of the executable application code refers to at least one seat entertainment terminal (5) mounted inside of the aircraft (1) and / or refers to at least one personal mobile terminal (6) of a user on board the aircraft (1); - storing by the on-board server (2), prior to take-off from the plane (1), the user data; - install and execute by the on-board server (2), prior to the aircraft take-off (1), the first received part of the executable application code, thereby updating the operating system of the on-board server (2); - distribute the second part of the executable application code received for the installation and execution of at least one terminal via the on-board server (2), prior to take-off of the plane (1) and / or after take-off of the plane (1) seat entertainment (5) and / or the at least one personal mobile terminal (6); - receive, from the on-board server (2) from the ground server (3), delta user data and delta executable application code after take-off and before landing of the aircraft (1), updating the delta user data the user data received prior to take-off by forming updated user data and updating the executable application code delta the first part of the executable application code and / or updating the second part of the executable application code received prior to the aircraft take-off (1) ; - transmit, by the on-board server (2), after take-off and before landing of the aircraft (1), at least a part of the updated user data for the at least one seat entertainment terminal (5) mounted inside of the aircraft (1) and / or the at least one personal mobile terminal (6) of a user on board the aircraft (1) for the presentation of the updated user data transmitted to the user; - install and run by the on-board server (2), after take-off and before landing of the aircraft (1), the first updated part of the received executable application code, thereby updating the operating system of the on-board server (2 ); - distribute by the on-board server (2), after take-off and before landing of the aircraft (1), the second updated part of the executable application code received for the installation and execution of at least one seat entertainment terminal (5 ) and / or the at least one personal mobile terminal (6), in which the reception of the delta user data is activated by an update request (45) sent by the on-board server (2) to the ground server ( 3) periodically, and in which the method further comprises setting, by the on-board server (2), an update period (57) for sending the update request (45) periodically depending on a number and content requested from content collection requests from the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6) or depending on the amount of delta user data previously received from the ground server (3).

Description

DESCRIPTION

Airplane to ground communication

The present invention is directed to communication technologies that include server, clients, and data exchange over a wireless interface. More specifically, it addresses a method, a server, and a computer program for airplane-to-ground communication during a flight.

Background

Due to the wide expansion of the use of mobile communication devices such as smartphones and tablets for business and personal communication as well as the increasing coverage of 3G and 4G networks as well as Wi-Fi, information technology has become omnipresent in today's world. People are used to, and expect, the possibility of permanent and continuous use of mobile communication devices, regardless of their location and current situation.

However, there are still technical restrictions and limitations and others that are an impediment to a widespread use of mobile communication devices, including lack of coverage or insufficient bandwidth in remote areas or special locations, large data volumes for example for cloud applications in circumstances of low bandwidth or unstable connections and legal requirements that prohibit the activation of wireless connections. Therefore, there is a need for technical solutions that address these restrictions and limitations to increase the use of mobile communication devices also in such particular situations.

Summary of the invention

The present application is directed to facilitate an improved use of communication devices during flights, in particular to allow the collection of information with communication devices of the passengers while the passengers are located in an airplane.

This problem is solved by the subject matter of the independent claims.

US 2009/0187640 A1 describes a system for implementing an in-flight passenger information system. The in-flight passenger information system includes one or more ground-based servers in network communication with an aircraft-based server. The one or more ground-based servers are configured to run a computer application to access a database containing airport infrastructure information (for example, airport terminal layout, default flight schedules, etc.) and information. passenger transactional information (for example, passenger information, flight derivations for travel continuation for current passengers, gate information for connecting flights, baggage claim information for the current flight, local weather information, flight plan changes flight, cancellations and delays, security notices, overbooked premium opportunities, and baggage claim and tracking information). The aircraft-based server is preloaded with both the infrastructure information and the latest version of the available transactional information that affects only those passengers currently on that particular aircraft. Additionally, the aircraft-based server is in network communication with one or more passenger-accessible input / output devices (such as personal communication devices, for example, a passenger cell phone or PDA, aircraft display screens or aircraft personal seating displays), in which, during the flight, the one or more passenger-accessible input / output devices are configured to communicate to a passenger, passenger-selected portions of airport infrastructure information and to the passenger the transactional information specific to the passenger and in which the updates of the transactional information are disseminated from the ground-based server located at the destination airport (or other ground-based servers located "off" from the flight path ) through an on-the-fly network on a regular basis, making this information available to passengers through the one or more entry / exit devices accessible to the passenger.

According to one aspect, there is provided a method for an inflight server data communication that is installed in an aircraft according to claim 1.

In accordance with another aspect, an on-board server is provided that implements corresponding functionality.

In accordance with some other aspect, a computer program is provided that is configured for execution by an on-board server and for causing the on-board server to implement corresponding functionality.

Additional optional aspects are set forth by the dependent claims.

Brief description of the figures

The subsequent description of embodiments is based on the accompanying set of figures in which similar reference numerals refer to similar elements and messages and in which:

FIG. 1 shows a high-level schematic overview of the system architecture as described herein;

FIG. 2 shows a sequence of messages to provide codes and data from the server on the ground through the on-board server to the on-board devices before and after take-off;

FIG. 3 shows a sequence of messages to provide delta data from the server on the ground via the on-board server to the on-board devices after take-off;

FIG. 4 refers to a regular update during the flight;

FIG. 5 refers to updates that take into account the phases of flight;

FIG. 6 refers to updates that depend on the geographical location of the aircraft during the flight; FIG. 7 refers to updates in response to determining the new availability of the onboard server wireless interface;

FIG. 8 displays on-board server update requests and terminal update requests; FIG. 9 shows the continued distribution of current data by the onboard server despite the unavailability of the wireless interface with the server on the ground;

FIG. 10 shows data update based on versions and corresponding version identifiers;

FIG. 11A and 11B refer to a particular example of user data that is PNR data;

FIG. 12 presents the modification of user data made by an on-board terminal;

FIG. 13 displays delta user data embedded in a response to a user data modification; FIG. 14 and FIG. 15 show an example graphical user interface of onboard applications; and FIG. 16 represents the main components of an onboard server implementation.

Detailed description

Before proceeding to the description of the embodiments based on FIGS. 4-16, a few more general aspects are elaborated first with reference to FIGS. 1 to 3.

The main elements that implement and participate in the methodologies described herein are represented by FIG. 1. To begin with, an on-board server 2 is installed on an aircraft 1. The on-board server 2 is mounted within a suitable location on the aircraft 1. It is further given below with reference to FIG. 16 an example implementation of the on-board server 2. The aircraft 1 can be in general any kind of aircraft for the purpose of transporting passengers including civil aircraft such as the Airbus A300 series (including the widely used models A319, A320, A321, A330 and the newer types such as the A350 and 480) and the Boeing 7X7 series (including the widely used models such as the 737, 767 and 777 and the newer types such as the 787), as well as models from other manufacturers of aircraft such as Bombardier and Embraer. In general, the on-board server 2 functions as an interrelated or intermediate station that manages the communication between terminals located in the aircraft 1 and the ground.

The terminals located in the aircraft 1 are referred to hereinafter as on-board devices. There may be different types of devices on board, including fixed 5 seat entertainment terminals mounted within aircraft seats and 6 personal mobile terminals that are carried either by passengers or aircraft crew or are operated by the line that operates the aircraft flight prior to or during the flight. Personal mobile terminals 6 include devices such as smartphones, tablets, PDAs, and portable computers on board the aircraft. The on-board devices 5, 6 are in communication with the on-board server 2. Communication between the on-board server and the on-board devices 5, 6 is carried out either by cable connections 7, for example in the case of terminals seat-mounted entertainment 5 or by a provision of network connectors in the seat for the connection of personal mobile communication devices 6 to an on-board local area network by cable and / or by wireless connections 6, for example via a GSM / 3G / 4G cellular network such as a pico-cell or femto-cell network using one or more base stations on board, Wi-Fi using one or more Wi-Fi access points installed inside the aircraft and / or via Bluetooth. Thus, the on-board server 2 and the on-board devices 5, 6 form a local network on board the aircraft 1.

The on-board server 2 further communicatively connects with a ground server 3 which is located for example in a computing center at an arbitrary ground location. Communication between the on-board server 2 and the ground server 3 uses a wireless interface 4. For example, a satellite communication module and / or a 3G / 4G / 5G transceiver module 9 is mounted inside the aircraft to which it is connected. to the on-board server 2. The connection of the on-board server with this communication module 9 is made via a wired line or, alternatively, via a wireless connection, for example via Wi-Fi. The communication module 9 can also be attached to, or integrated into, the on-board server 2. In the example of a satellite communication module, the communication module 9 communicates via satellite (using a SatCom antenna installed in the aircraft 1) through one or more land line based networks (WAN, Internet) with the server on the ground 3. In the example of a 3G / 4G / 5G transceiver module, the communication module 9 communicates with a mobile communication network Ground 3G / 4G / 5G which, in turn, connects to onboard server 2 via potentially additional landline-based networks (WAN, Internet) with the ground server 3. The ground server 2 can be either a single server or be composed of a plurality of interconnected servers. The main functions of the ground server 2 are to provide the onboard server 2 with up-to-date basic user data and executable code (as will be explained in detail below), or to be the source of user data and / or code executable and / or by functioning as an interface with other servers and networks that host user data and / or executable code.

The communication protocols used to transmit data between the onboard server 2 and the server on the ground 3 include the respective series of protocols of the 3G / 4G / 5G network used on the ground (for example MAC, LLC, RLC, PDPC and other protocols in the various lower layers), TCP / IP in the network layer and the transport layer as well as web service protocols such as SOAP that use HTTP / HTTPS, SMTP, J Ms as well as other protocols located in the application layer . The data exchanged at the application layer is, for example, formatted according to XML and / or JSON (= JavaScript Object Notation).

By using these basic components arranged in the architecture schematically represented by FIG. 1, the following basic communication scheme is carried out (FIGS. 2 and 3). In general, two phases or situations of the communication of the aircraft with the ground server 3 can be distinguished, a phase on the ground and a phase in flight. During the ground phase, that is when the aircraft 1 is located above the ground, for example at a gate at the airport of origin before departure, the architecture is used to initialize the on-board server 2 with basic software and data to provide to the on-board devices 5, 6 the requested information. During the flight phase, that is, when aircraft 1 is in the air, for example after take-off from the origin airport and before landing at the destination, the on-board server 2 is provided with updates to update the basic data available on onboard server 2 from initialization during the ground phase.

During the ground phase (FIG. 2, displayed by the segment indicated with "airplane at airport / gate"), the on-board server 2 receives both the executable application and the user data from the ground server 3 ( message 30 in FIG. 2 which is meant to indicate that it represents any kind of message exchange during the ground phase to transmit executable application code and user data from the ground server 3 to the on-board server 2).

The term "executable application code" as used in this document refers to two aspects, namely

- application code to be installed and run on onboard server 2, such as

o new server applications or server application updates for example implementing the communication functions of the on-board server 2 with the ground server 3 and the on-board devices 5, 6 and the provision of information services to the on-board devices 5, 6 described herein (see below); and

or other on-board server 2 code implementation functions that include code in relation to the on-board server operating system (for example allowing OS updates) or security functions (such as virus scanner updates); and

- executable code to be sent by the on-board server 2 to the requesting on-board devices 5, 6 and has to be installed and run on these on-board devices 5, 6, for example seat entertainment client software (or updates of said client software, applications (or updates of said applications) to be installed on requesting personal communication devices such as email clients, browsers, news applications, games, etc. Therefore, in this sense, the on-board server 2 functions as an on-board application store for on-board terminals 5, 6.

Note that executable application code as used herein also includes static files used to run applications such as configuration files.

The term "user data" as used herein refers to any type of electronic data (other than executable code) that is intended to be distributed and made available to on-board devices 5, 6 during flight (and of course also already before take-off and after landing, if requested). User data includes, for example, entertainment data including movies, images, news, personal data of the passenger, for example information regarding the current flight, connecting flights, accommodations etc., personal data such as data kept in a cloud private, business-related data such as trade news and stock change data, data related to current flight status such as weather forecasts and current weather information, data from relevant / frequently used web pages and so on. Therefore, in this sense, the on-board server 2 functions as an on-board data server for the on-board terminals 5, 6.

Therefore, during the ground phase, the above architecture (FIG. 1), particularly the connection with the ground server 3 through the wireless interface 4, allows to provide update of the on-board server 2 remotely with the executable code basic and basic user data while aircraft 1 is still on the ground 1. This is a significant upgrade from the inflight entertainment servers previously implemented on aircraft that were in a position to be updated only in a proprietary way by IT service personnel who were physically on board the plane. Through the current connection of the on-board server 2 with the on-board server 3, the installations of new server applications, updates of the server applications, changes to the configuration of the server applications and the provision to the on-board server 2 of new data of User is done more flexibly and can be done more regularly with less manual effort. For example, a software update / reconfiguration and a data update on the on-board server 2 is made possible in considerably shorter time intervals in which the aircraft 1 is located on the ground between two subsequent flights.

Furthermore, the transmission of user data from the ground server 3 to the on-board server 2 prior to take-off makes it possible to provide the on-board server 2 with the basic user data set (particularly current user data that is up to date at the time before plane 1 leaves the airport gate). This minimizes the need to update user data during the flight, while still allowing the on-board devices 5, 6 to be provided with the most current user data during the flight. In other words, the main amount of user data can be transmitted to the on-board server 2 before take-off of the aircraft when the bandwidth of the wireless interface 4 between the on-board server 2 and the ground server 3 is generally of good quality. for example due to relatively constant mobile connection conditions, short distance to 3G / 4G / 5G infrastructure (eliminating the need for expensive and low-bandwidth satellite connections), all of which makes it possible to provide a Guaranteed and relatively high band (higher than in flight) to the connection of the on-board server 2 with the server on the ground 3.

Since the executable application code is made available to the on-board server 2 during the ground phase, the on-board server 2 executes at least a part of the executable application code (table 31 in FIG. 2). For example, application code that implements the communication functions of the on-board server 2, the code that controls the operation of the on-board server 2 (including the operating system of the on-board server), and code that implements server applications such as a entertainment server, a passenger information server and an application store server and / or updates of these programs can be transmitted to the inflight server 2 from the ground server 3 while the aircraft 1 is located on the ground and these server applications and updates are installed accordingly on the on-board server 2 (the installation can also be remotely observed or performed using prepared scripts). In some embodiments, the on-board server 2 executes this application code in the form of executed server applications 19 represented by FIG. 16. Furthermore, the on-board server 2 stores the user data and the parts of the executable application code aimed to be executed on the on-board devices (such as software and client applications) received from the ground server 3 during the phase in land, for example in a repository that is implemented, for example, by a database (also represented by table 31 of FIG. 2). In some embodiments, the on-board server 2 stores user data related to particular server applications together with the executed server applications 19 (for example the content of frequently used web pages can be saved in the module 19 to be made available to devices on board 5, 6 via a web server hosted by the on board server 2), entertainment content such as movies, pictures and music in an entertainment content database 18 and executable application code indicated to be run on the devices on board 5, 6 in an application storage base 21 (see FIG. 16).

Still during the ground phase, user data and / or executable application code intended to be installed and executed on on-board devices 5, 6 can be made available to on-board server 2 for on-board devices 5, 6 ( message 32 in FIG. 2 which is indicated to represent any type of message exchange during the ground phase to distribute executable application code and / or user data from on-board server 2 to any number of on-board devices 5, 6 requesting such information, including requests for content collection by on-board devices that collect executable application code and / or user data from the on-board server 2). Therefore, the on-board devices can already collect executable application code and / or user data from the on-board server 2 while the plane 1 is still on the ground and for example the passengers wait for the departure of the plane 1. Therefore Therefore, the application code collected from the on-board server 2 can already be executed by the on-board devices 5, 6 and the user data collected from the on-board server 2 can already be presented to the users while the aircraft 1 is still on the ground (represented by table 33 in FIG. 2). To distribute the executable application code and / or updated user data, the on-board server 2 uses at least a part of the executed application code such as a server application that continuously streams entertainment programs to the seat entertainment terminals 5 or to a passenger information server that provides current passenger information to personal communication devices 6, for example the user data update management module 22 (FIG. 16).

The ground phase ends, at the latest, with the take-off of the aircraft (indicated by the cross in FIG. 2). With this, aircraft 1 leaves the "safe harbor" (in terms of communication connectivity with the ground) at the airport and begins the in-flight phase.

As displayed by message 34 and table 35 of FIG. 2, the same activities of distributing executable application code and / or user data received by the on-board server 2 during the ground phase to on-board devices 5, 6 and the execution of application code and display of the data from user on the on-board devices 5, 6 can also be performed during the in-flight phase (again, message 34 in FIG. 2 is directed to represent any type of message exchange during the flight phase to distribute the executable application code and / or user data received by the on-board server 2 during the ground phase from the on-board server 2 to any number of on-board devices 5 , 6 that request such information).

During the flight, the user data maintained by the on-board server 2 is updated. To this end, the on-board server 2 receives delta user data from the ground server 3 after take-off and before the landing of aircraft 1 (message 40 in FIG 3 which is aimed at representing any type of message exchange during the in-flight phase to transmit delta user data from the ground server 3 to the on-board server 2). The expression "delta user data" used herein is intended to express the fact that the data already available on the on-board server 2, in particular due to the supply to the on-board server 2 of executable application code and data from Basic user during the ground phase, they are not relayed back from the ground server 3 to the onboard server 2 during the in-flight phase. Therefore, the delta user data updates the user data already present on the on-board server 2, in particular the basic user data received during the ground phase (i.e. prior to take-off formation) and thus forms the user data updated on the on-board server 2. For example, the delta user data may include changed, more current and / or updated user data that was not yet available during the ground phase such as current weather information, stock exchange data, updated information regarding the connecting flight or passenger accommodations, new emails, updated news, and so on.

In some embodiments, the on-board server 2 also receives delta executable application code from the ground server 3 during the in-flight phase which forms an updated application code on the on-board server and adds / changes the functionalities implemented by the flight code. application run on the on-board server 2 and / or the on-board devices 5, 6. For example, the ground server 3 can transmit a patch to the on-board server 2 during the in-flight phase, the installation of which on the on-board server 2 and / or the on-board devices 5, 6 eliminate an error or add a certain functionality to a server application and / or a client program.

In the same way that the on-board server 2 distributes executable application code and user data received in the ground phase before take-off, the on-board server 2 distributes the updated user data (and also potentially updated executable application code) to onboard devices. Therefore, as shown by message 42 in FIG. 3 (which is again aimed at representing any kind of message exchange during the in-flight phase to distribute the executable (updated) application code and / or the updated user data from the on-board server 2 to any number of devices to board 5, 6 requesting said information), the on-board server 2 transmits at least a part of the updated user data to the on-board devices, more specifically to at least one of the seat entertainment terminals 5 mounted inside the aircraft and / or at least one of the personal mobile terminals 6 of a user / passenger / crew member on board the aircraft for the presentation of the updated user data transmitted to the user / passenger / crew member. Similar to as it has already done during the ground phase, to distribute the executable application code and / or the updated user data, the on-board server 2 uses at least a part of the application code executed also during the flight phase ( i.e. after take-off and before landing), such as a server application that streams entertainment programs to the seat entertainment terminals 5 or a passenger information server that provides current passenger information to communication devices personal 6.

Similarly to the activities represented by Tables 33 and 35 in FIG. 2 and already described above, the on-board devices 5, 6 install and execute potentially updated application code received from the on-board server 2 during the flight phase and present potentially updated user data received from the on-board server during the on-board phase. flight to the user (table 43 in FIG. 3). The in-flight phase then ends with the landing of aircraft 1 at the destination airport and its arrival at the assigned gate.

Therefore, in general, the basic communication scheme described above is based on the on-board server 2 as the central entity. The on-board devices 5, 6 do not communicate directly with the ground to collect current user data, but always collect the current user data from the on-board server 2. The on-board server 2 manages communication with ground on the part of all on-board devices 5, 6 and is therefore able to make efficient use of the limited bandwidth available for communication with the ground during the in-flight phase. In this way, the amount of data exchanged during the in-flight phase of the aircraft 1 is minimized, while the most current user data can still be supplied to the on-board devices 5, 6. Furthermore, as will also be further explained below , the on-board server 2 is able to provide user data as well as executable application code to the on-board devices 5, 6 even during times when no connection to ground is available at all or connection to ground is prohibited by some reason.

Additional options and refinements will now be described with reference to FIGS. 4 to FIG. 16.

In some embodiments, the transmission of the delta user data by the ground server 3 and its reception by the on-board server 2 is done in a pulse fashion, for example without any solicitation from the on-board server 2. For example, when the ground server 3 determines a change of a user data record maintained by the ground server 3 and which is known by the ground server 3 to be present in the on-board server 2, the server ground 3 transmits the changed user data record to on-board server 2 without a prior request to transmit the user data record from on-board server 2. For example, ground server 3 may receive an indication from a system Departure Control that indicates that a particular flight is delayed. The ground server 3 checks if the delayed flight is listed in the Passenger Name Records of the passengers on board aircraft 1 as a connecting flight. If yes, the ground server 3 transmits the delayed connection flight user data record to the on-board server 2 as delta user data. The on-board server 2 saves the user data record in its respective repository and sends the user data record relating to the delayed flight to the on-board device 5, 6 of the respective passenger (s) . This communication scheme corresponds to the message sequence graph displayed by FIG. 3, with the addition of an event / notification next to the ground server 3 that triggers this pulse of delta user data from the ground server 3 to the onboard server 2.

In some embodiments, the transmission of the delta user data by the ground server 3 and its reception by the on-board server 2 is - in addition to or as an alternative to the transmission pulse just described - triggered by an update request 45 sent by the on-board server 2 to on-board server 3 (FIGS. 4 to 7 displaying the update process between on-board server 2 and on-ground server 3 — note that communication between on-board server 2 and on-board devices 5 , 6 to distribute user data taking place in parallel is not shown for clarity—). In general, the on-board server 2 sends an update request 45 to collect delta user data (and in some embodiments also updated executable application code) from the ground server 3, i.e. the data is transmitted in a form extraction. Ground server 3 responds to an update request 45 with at least one delta user data message 40 (message 40 as shown by FIG. 4 represents one or more messages responding to update request 45 and transmits all delta user data collected by update query 45). The update request 45 can be either a general update request of the user data present on the on-board server 2 or it can indicate particular data records or parts of which an update is sought. Thus, the on-board server 2 is able to control the extent of updates by means of update requests 45 and, for example, limit the delta data collected from the ground server 3 to particular types of data (for example passenger or flight related information only, but not any multimedia content).

The update request 45 sent by the on-board server 2 can be activated or prohibited by different criteria and conditions including a periodic update (FIG. 4), an update dependent on a phase of the flight of the aircraft (FIG. 5), an update dependent of a geographic location of the aircraft (FIG. 6), an update in response to determining an availability of the wireless interface after a period of unavailability of the wireless interface (FIG. 7), an update request of the terminal by one of the seat entertainment terminals 5 or by one of the personal mobile terminals 6 (FIG. 8) or any combination thereof.

In some embodiments, the on-board server 2 periodically transmits an update request 45 to the ground server 3 and the ground server responds with respective delta user data messages 40 (FIG. 4). This scheme is, for example, sensitive in situations where the wireless interface 4 offers adequate and constantly available bandwidth for general updates of the user data available on the on-board server 2 and thus update requests. 45 perform an update of all types of user data available on the onboard server 2 or at least specific types of data such as travel related and passenger related data. The update period 57 used by the on-board server may be constant over a longer period of time, but the on-board server 2 is also arranged to adjust the update period 57 in some embodiments depending on various factors such as the number and requested content of content collection requests from the on-board devices 5, 6 or the amount of delta user data previously received from the ground server 3. For example, during a 30 minute period at the start of the flight , the on-board server 2 sends an update request 45 once per minute due to a significant number of content collection requests in relation to email traffic from some of the on-board devices 5, 6 throughout this period of time. Then, the number of these email collection requests decreases and the onboard server 2 extends the update period 57 to only one update request 45 every five minutes.

In some embodiments, the onboard server 2 sends update requests 45 depending on the phase of the flight of the aircraft 1 (FIG. 5). For example, legal or governmental regulations may prohibit communication with the ground by on-board server 2 (and on-board devices 5, 6) during an initial phase of flight 51 after take-off of plane 2 and / or during a final phase of flight 52 while the plane descends to the destination airport. These flight phases can be defined depending on the altitude of the aircraft. For example, the initial flight phase 51 may last until the aircraft reaches an altitude of, for example, 3,000 meters (= 9,842 feet) or, alternatively, reaches its cruising altitude. Accordingly, the final phase of flight 52 can be entered when aircraft 1 drops below an altitude of eg 3,000 meters (= 9,842 feet) or, alternatively, leaves its cruising altitude. A phase of the flight during which the on-board server 2 does not send any update request 45 to the server on the ground may also take place during the flight, for example during a turbulence phase. The definitions and conditions of phases of flight are generally predetermined. The entry of a new flight phase can be determined either remotely from aircraft 1 by a ground operation / flight control and signaled to the aircraft 1 and the on-board server 2. Alternatively, in some embodiments, the entry of a new phase flight can be determined also on board due to the plane's conditions. Accordingly, in some embodiments, the on-board server 2 is arranged such that its communication functions with the ground via the wireless interface 4 can be temporarily disabled by a remote signal received from the ground operation / flight control and / or Onboard by Aircraft Crew 1. As shown in FIG. 5, the conditions of sending an update request 45 periodically and prohibiting the sending of update requests 45 can be combined so that the onboard server 2 does not transmit any update request 45 during the initial phase of flight 51 and the final phase flight 52, but periodically broadcast update requests during the main flight phase in between.

In some embodiments, the on-board server 2 sends update requests 45 depending on the geographic location of the aircraft (FIG. 6). For example, as shown in FIG. 6, the flight of the plane originates from Munich, Germany and is headed to Tokyo, Japan with a route through the Arctic Ocean and / or the north of the Asian continent. The on-board server 2 can transmit update requests 45 as long as aircraft 1 is located over continental Europe (phase 53 in FIG. 6), but can be programmed to cease transmitting update requests while aircraft 1 is located over the Arctic Ocean or northern Siberia (phase 54 in FIG. 6), due to a previously known lack of SatCom coverage and mobile communication or the availability of only expensive SatCom connections. The on-board server 2 can then resume transmitting the update requests 45 once it enters the Far East area (step 55 in FIG. 6). Again, the update request condition is combinable with other conditions such as periodic update requests and flight phase dependent update requests as briefly described with reference to FIGS. 4 and 5.

In some embodiments, the on-board server 2 sends an update request 45 in response to a determination that the wireless interface 4 has become available after being unavailable for a certain period of time (FIG. 7). As will be further explained below with reference to FIG. 9, the on-board server 2 can detect the unavailability of the wireless interface 4 in the attempt (failed) to transmit an update request 45 to the ground server 3 (the failed attempt indicated as 45A in FIG. 7), after that a previous attempt to transmit an update request 45 to the ground server 3 was successful. In this case, the onboard server 2 records the point in time of the unavailability detection. From this point on, the onboard server 2 can monitor the in / availability of the wireless interface 4, for example by sending short polling messages. Alternatively, in some embodiments, the availability status of the wireless interface 4 is monitored by the communication module 9 for example by using lower layer protocol monitoring (for example directly at the SatCom or 3G / 4G / 5G) and the communication module 9 transmits, for example periodically, the availability status of the wireless interface to the on-board server 2. When the monitoring of the wireless interface 4 shows a new availability of the wireless interface 4, the server on board 2 transmits an update request 45 to the server on the ground 3. This update request 45 sent with the newly detected availability of the wireless interface 4 can be either a general update request 45 that performs an update of all kinds of data maintained by the onboard server 2 or, for example, a retransmission of the previous update request 45 that was not transmitted successfully due to the detected unavailability of the wireless interface 4. The on-board server 2 may be arranged to only send said update request 45 if the wireless interface 4 was unavailable for a certain minimum amount of time (phase 56 in the FIG. 7) such as 5 minutes.

In some embodiments, the on-board server 2 sends an update request 45 to the ground server 3 in response to a terminal 44 update request by one of the seat entertainment terminals 5 or by one of the terminals. personal mobiles 6 (FIG. 8). By using the update request from the terminal 44, the on-board device 5, 6 is able to request an update from a ground server via the on-board server 2. For example, a personal communication device 6 can pick up new messages email from the user's POP3 or IMAP mailbox. To this end, the personal communication device 6 transmits a signal (for example a log message and a "RETR x" by means of which a client picks up the e-mail x according to the POP3 protocol) that is interpreted by the server to board as an update request from terminal 44. In turn, the on-board server 2 can contact the corresponding POP3 server on the ground through the ground server 3 which is considered to be an update request 45 from the on-board server 2 to ground server 3. POP3 server then responds with email x via ground server 3 to onboard server 2 (= delta user data message 40) which relays this via message 32 to personal communication device 6 petitioner presenting this to the user (Table 33).

FIG. 9 represents a situation that highlights the ability of the on-board server to serve the available user data to the on-board devices 5, 6 despite an unavailability of the wireless interface 4 during the flight phase. The first part of FIG. 9 displays the normal operation during the flight phase in which the on-board server 2 transmits an update request 45 to the ground server 3, the ground server 3 returns the respective delta user data 40 to the on-board server 2 forming data User data updated on the on-board server 2 and the on-board server 2 distributes the updated user data to the on-board devices 5, 6 (via message 32) which presents the updated user data to the user (Table 33). The update request 45 can be triggered by any of the conditions as described above with reference to FIGS. 4-8. Subsequently, one of the on-board devices 5, 6 transmits an update request from terminal 44 to on-board server 2 requesting user data that may or may not be available on the on-board server 2. The on-board server 2 processes the update request from the terminal 44 and determines whether or not the requested user data is already available on the on-board server 2. In the event that the requested user data is available, the on-board server 2 returns the user data to the requesting on-board device. Otherwise, the on-board server 2 initiates the transmission of an update request 45 to the ground server 3. In the attempt to transmit the update request 45 to the ground server 3, the on-board server 2 determines the unavailability of the wireless interface 4 with ground server 3, for example due to lack of coverage of the 3G / 4G / 5G SatCom connection. In response to detecting this unavailability of the wireless interface 4, the on-board server 2 responds to the on-board device 5, 6 which sent the update request from terminal 44 with default user data or substitute user data already available on the server. on-board 2 serving the request from the on-board device in the best possible way (message 32 in FIG. 9). These default user data or substitute user data are formed by at least one element of the basic user data received by the onboard server 2 already during the ground phase (prior to take-off) and / or at least one element of updated user data consisting of delta user data previously received during the flight phase (after take-off). For example, if the update request 44 of the terminal of the on-board device 5, 6 was directed to a collection of current meteorological data, the on-board server 2 responds with the latest available version of the meteorological data, although this latest version of the Weather data may already be old in 30 minutes, that is, it was received by onboard server 2 from ground server 3 30 minutes ago. The on-board server 2 may add an indication to the on-board device 5, 6 that the response data is not a current version, but represents only substitute user data. Together with the surrogate data, the on-board device 5, 6 can present this indication to the user (second frame 33 in FIG. 9). If there is no meaningful default data or substitute data available on the on-board server 2, the on-board server 2 may also respond to the on-board device 5, 6 with an error message indicating the unavailability of the wireless interface 4. The device to The board can then present this indication to the user.

In some embodiments, the communication between the on-board server 2 and the ground server 3 as well as between the on-board server 2 and the on-board devices 5, 6 uses a versioning scheme to implement delta user data transmission and avoid User data retransmissions already available on the onboard server (FIG. 10). To this end, the ground server 3 (and, if present, other servers connected to the ground server 3 and hosting user data) are arranged to maintain versions of the user data and a respective history, each version being associated user data with a version identifier. The delta user data transmitted from the ground server 3 to the onboard server 2 includes a respective version identifier that identifies the version of the transmitted delta user data. Through the use of the version identifiers included in the delta user data messages 40, the on-board server also maintains updated versions of the user data, each version being associated with the correct version identifier. An update request 45 transmitted from the on-board server 2 to the ground server 3 also includes the correct version identifier indicating the version of the corresponding user data currently available on the on-board server, for example the updated user data formed by previously received delta user data 40. Based on the version identifier included in the update request 45, the ground server 3 compares the version of the updated user data that is currently available on the on-board server 2 with the version of the user data that is currently available on ground server 3 and determines the difference data that represents the difference between both versions. The ground server 3 then transmits only the differences between the updated user data available on the onboard server 2 and the current version of the user data that is available on the ground server 3, again including the delta user message respective 40 the version identifier that indicates the current user data version of the ground server 3. In the event that the user data version indicated by the on-board server 3 is still valid, i.e. unchanged, in the ground server 3, the delta user data response 40 from the ground server is empty since the difference is zero.

An example is given by FIG. 10. During the flight phase, the on-board server 2 sends an update request 45 that includes a version identifier indicating version i to the ground server 3. The ground server determines the difference between the user data version i on-board server and your own version of the corresponding user data. Assuming there is a difference, the ground server 3 includes the difference user data as delta user data in the response 40, along with the corresponding version identifier i + x. The on-board server 3 updates its corresponding user data from version i to version i + x (box 41) and is capable of distributing the updated user data to the on-board devices 5, 6 (message 42) which, at their Once, they will be presented to users (Table 43). Subsequently, the onboard server transmits the next update request 46 seeking to update the user data again. The update request 46 indicates the user data version by the version identifier set to i + x. Again, the ground server 3 performs a comparison between the version of user data indicated by the on-board server (i + x) and its own current version of the user data. The determined difference data is included in the ground server delta user data response 47, along with the new version identifier set to i + x + y. Again, the on-board server 3 updates its corresponding user data from version i + x to version i + x + y (box 48) and is able to distribute the updated user data to the on-board devices 5, 6 ( message 49) which, in turn, will be presented to users (Table 50).

Likewise, the onboard server 2 may also be allowed to refrain from including a version identifier in its update requests 45. This is interpreted by the ground server 3 as a non-update request. differential, ie the ground server 3 transmits all user data requested by the on-board server 2 without performing the differential comparison as described above.

FIGS. 11A and 11B refer to an example of the communication of travel-related and passenger-related information. As mentioned by FIGS. 11A and 11B, this information includes, for example, Passenger Name Records (PNR) of passengers on board aircraft 1 which is provided by a PNR database hosted on the ground server 3 and distributed to devices at board 5, 6 by a PNR server application running on the board server 2. FIGS. 11A and 11B cover the information exchange scheme both during the ground phase and during the flight phase.

In the ground phase, while aircraft 1 is located at the gate of the origin airport (or at a point in time above while aircraft 1 is located on the ground), the on-board server 2 is initialized with the executable code that implements PNR server application (if necessary) or for example an update of the PNR server application already existing on the onboard server 3, executable code that implements a PNR client application (if necessary) or for example an update to the PNR client application already stored on the on-board server 3, any other executable application code required on the on-board server 3, as well as all currently available PNR data of the passengers who are supposed to board the aircraft. Initialization is triggered by an initialization request 60 sent from the on-board server 3 to the ground server 2. The initialization request 60 includes a flight identifier that allows the ground server 3 to compile the PNR data of all passengers with reservation for the flight performed by aircraft 1. The ground server 3 returns the respective PNR application code and PNR data to the inflight server with one or more messages 61. As shown by table 62, the server at board 2 installs or updates its PNR server application, stores the received PNR data (for example in a logical part of memory 16 called as executed server applications 19, see FIG. 16) and stores the client application code PNR (eg in application store 21, see FIG. 16). Still during the ground phase and also during the in-flight phase after take-off, the on-board server 2 sends PNR client application code to on-board devices 5, 6 requesting for the installation and execution of the PNR client application requesting data PNR data as well as PNR data to the requesting on-board devices 5, 6 (FIG. 11B, messages 63, representing any request from the on-board devices 5, 6 and PNR code and PNR data messages by the server to board 3). PNR user data distribution can be done by PNR server application running on the on-board server, while PNR client code distribution can be done by AppStore application running on on-board server. board install and run the PNR client application and, by using the PNR client application run, collect PNR data from the PNR server application running on the on-board server 2 and present the collected PNR data to the user (FIG. 11A, Tables 64).

Turning now to PNR data updates during the in-flight phase (FIG. 11B), the on-board server 2 transmits update requests 66, 71 to the ground server 3 to collect the delta PNR data from the ground server. 3 (messages 67, 72). Similar to the initialization request 60, also the update requests 66, 71 include the flight identifier that identifies the current flight operated by aircraft 1. In addition, the update requests 66, 71 include the respective version identifier that indicates the current version of the PNR data stored in the on-board server 3, based on which the ground server 3 performs a comparison of the current PNR data in its PNR database with the version of the PNR data indicated by the version identifier of the on-board server 2. According to the embodiment of FIG. 10 described above, the messages 67, 72 carrying the PNR data include the updated version identifier indicating the current version of the delta PNR data returned by the ground server 3. After the delta PNR data has been received, the on-board server updates the PNR data stored by the PNR server application (Tables 68 and 73), thereby forming updated PNR data, distributes the updated PNR data to the 5, 6 requesting on-board devices (messages 69 and 74) that will present the updated PNR data to the passenger (table 70 and 75).

In a similar or analogous way, executable application code and user data related to other server applications and client applications can be provided to on-board server 2 and on-board devices 5, 6, including social media services such as Facebook and Twitter, Internet browsing, email synchronization, business data synchronization, for example a salesperson preparing a business document with his laptop and uploading the document to his company server or to a cloud, etc.

In some embodiments, the communication scheme between the on-board server 2 and the ground server 3 as well as between the on-board server 2 and the on-board devices 5, 6 additionally allows a modification of the ground user data stored in or managed by ground server 3 during flight (FIGS. 12 and 13). More specifically, on-board devices 5, 6 (example FIGS. 12 and 13 refer to an individual seat entertainment terminal 5, but the following functionalities also apply to personal communication devices 6) are arranged to transmitting a request to modify user data from terminal 80 to on-board server 2 whereby on-board device 5, 6 requests to modify at least one element of user data stored on ground server 3 (or on another server remote from the plane connected to the server on the ground 3). For example, the passenger using the seat entertainment terminal 5 may have changed the reservation of his accommodation at the travel destination and may wish to update his itinerary in the PNR database of the ground server 3 at consequence. In response to the receipt of the user data modification request from the terminal, the on-board server 3 transmits a respective user data modification request 81 to the ground server 3. The ground server 3, after having received the request 81, effect changes to the user data on the ground and acknowledge it to the on-board server by reply 82. The on-board server 2 sends the reply by message 83 and the seat entertainment terminal 5 is able to indicate to the user the successful modification of ground user data (Table 84).

Similar to the situation of an unavailable wireless interface 4 as described above with reference to FIG. 9, the on-board server 3 may also determine an unavailability of the wireless interface 4 in the attempt to transmit the user data modification request 81 to the ground server 3. In this case, the on-board server 2, in some embodiments , it is arranged to temporarily store the user data modification request of the terminal 80 until the availability of the wireless interface 4 is again obtained and transmit the user data modification request 81 at a later time point. Thus, the on-board devices 5, 6 are relieved from taking care of the successful transmission of the user data modification request from the terminal 80 to the ground server 3.

In some embodiments, the response 82 to the user data modification request is used to return delta user data to the on-board server without an explicit update request 45 from the on-board server 2 (FIG.

13). That is, for example, it is useful in situations where the ground server 3 has available delta user data that may or may not be related to the user data modified by the user data modification request 81. Continuing with the example above of the passenger who has modified the reservation of his accommodation, in the course of modifying the passenger's accommodation data in the PNR database, the ground server 3 can examine whether, and positively determine that, the flight of connection of the same passenger (and potentially other connecting flights relevant to other passengers) has changed since the last update of the user data of the on-board server and therefore includes the respective current flight information in the 82 response to the request user data modification (FIG. 13). The on-board server 2 that receives the response 82 then updates its user data in the same way as described above (Table 41 in FIG. 13), sends the response to the user data modification request including the updated connecting flight information of the passenger who has made the request for modification of user data 80 of the terminal and potentially also distributes any other user data that was updated by receiving the delta data included in the response 82 to the same and / or any other on-board device 5, 6 (message 32) that presents its updated user data to the user (box 33). In this way, the response messages 82 are efficiently used to return more current user data to the onboard server without explicit update request 45.

Next, a few more specific implementation examples of the message exchanges between the on-board server 2 and the ground server 3 to realize the above-described airplane-to-ground communication scheme such as an initialization message 30 and the update request 45 transmitted from onboard server 2 to ground server 3 and respective responses 40, 62 carrying user data and / or delta executable application code. In this example, these messages are implemented as web service calls using XML and JSON syntax.

As explained above with reference to FIG. 2, the initialization message 30 represents any type of message exchange during the ground phase to transmit executable application code and user data from the ground server 3 to the on-board server 2. In the present implementation example, the message Initialization 30 includes two more specific types of messages, namely user data initialization messages and application code initialization messages. Regarding the user data initialization message, example syntax dry message examples of the delta user message described further below are called since, in this example, the user data initialization messages are, in terms their syntax, identical to delta user data messages. Similar to the delta user messages described below, also the user data initialization messages are triggered by the update request 45.

The application code initialization messages are downloaded by the on-board server 2 in two stages, In the first stage, the on-board server 2 contacts the ground server 3 by transmitting a request for an application manifest to the server Ashore 3. In this example, this request is transmitted by using an HTTP GET request to a URL stored on the onboard server. This request includes the flight number of the next flight of airplane 1 as a parameter. In response to this application manifest request, ground server 3 responds with a manifest file that includes a list of all components of the executable application code (e.g. application clients, server applications, update files, file static configuration for on-board server configuration, etc.) to be transferred from ground server 3 to on-board server 2, along with the perspective URL from which on-board server 2 can download the application code components executable. The manifest file may also indicate the target use of the executable application code components within aircraft 1 (for example: to be executed by on-board devices 5, 6, to be executed by on-board server 2, to be stored as configuration files or static resources, etc.). The onboard server 2 processes the manifest file and then collects each component of the executable application code by sending the respective HTTP GET requests that include the URL associated with the ground server 3. Note that the executable application code can be located in a web server component of the ground server 3 or another web server remote from the ground server 3.

An exemplary manifest file that lists URLs relative to executable application code, in which URLs for static files (for example, new configuration files) and URLs for executable resource files are listed in URL lists separated, it reads as:

{

model: {

URLzip List: [

"/ static files.zip"

],

URLList: [

'' / apfplus / resources? module = en_concesion & IDIOMA = CN & SITE = XDEFXDEF '',

'' / apfplus / resources? module = en_concesion & LANGUAGE = FROM & SITE = XDEFXDEF ''

]

}

}

An XML-based and JSON-based syntax of an update request is described below 45. In this example, the request message serves the purpose of collecting travel-related and flight-related data as described above and For this purpose, it can contain three parameters (beyond the outer XML element that identifies the message as a requestDataABordo). The FlightID is, in this example, a mandatory parameter that has the function of identifying the flight of the requesting on-board server 2. The Previous revision parameter indicates the latest version of the trip-related and flight-related data currently available on the on-board server 2. This parameter is also defined as mandatory, but it can have an empty value if it has not been received. a previous version of the trip-related and flight-related data by the on-board server (for example in case of an initialization collection triggered by user data initialization messages as described above or after loss of data due to onboard server failure 2 or if a full collection as opposed to a differential update has been requested for any other reasons). The third parameter called Force update is used to indicate to the ground server 3 the particular data records currently available on the on-board server 2 and / or an on-board device 5, 6 that should be updated, for example in the case that the passenger or customer is aware that the data currently available on the aircraft may be out of date. This parameter is optional and only needs to be present if one or more of said data records to be updated are to be indicated to the ground server 3. Therefore, the example syntax resulting from the update request message looks like this:

<? xml version = "1.0" encoding = "UTF-8"?>

<requestDataABordo>

<IdFlight> FLIGHT ID </IdFlight> (REQUIRED)

<revisionAnterior> NUMBER OF LAST REVISION RECEIVED (POSSIBLY

EMPTY) </revisionPrevious> (MANDATORY)

<actualizacionForzosa type = "TYPE OF ENTITY A

UPDATE "id =" ID OF THE ENTITY TO UPDATE "/> (OPTIONAL)

</requestDataABordo>

An example of a specific update request using this syntax that does not require a particular data record to be updated can be as follows:

<? xml version = "1.0" encoding = "UTF-8"?>

<requestDataABordo>

<IdFlight> PRD_BA_175_LHR_2014-09-10 </IdFlight>

<revisionAnterior> 1416325741.624919 </revisionAnterior>

</requestDataABordo>

An example of a specific update request that uses this syntax requesting one or more particular data records (in this case: one particular passenger name record, two passenger data records, and one flight record) to be updated can be such as follows:

<? xml version = "1.0" encoding = "UTF-8"?>

<requestDataABordo>

<IdFlight> PRD_BA_175_LHR_2014-09-10 </IdFlight>

<revisionAnterior> 1416325741.624919 </revisionAnterior>

<forced update type = "pnr" id = "3GBFJG" />

<forced update type = "customer" id = "2416255A00005590"/>

<forced update type = "client" id = "2416255A00005647" /> <forced update type = "flight" id = "PRD_BA_175_LHR_2014-09-10" /> </orderData request>

Continuing with this example, an example syntax for the response to this generic request message carrying the trip related and flight related delta user data will be described below. Basically, the response syntax example includes - beyond the outer XML element that identifies the message as a responseDataABordo - a header section with information regarding the response to the previous update request. For this purpose, the heading section includes the parameters FlightID, Review, and PreviousReview . The latter allows the on-board server 2 to incorporate the updated delta data received with the response into its user data repository and build a new consistent version of the user data. The revision parameter identifies the version of user data currently available on the ground server 3 and is used by the onboard server 2 to identify its current version of user data in subsequent update requests. revision is an increasing float number that changes if and only if at least one section of the user data has changed compared to the version identified by the update request 45 above.

The main content of the response contains the delta user data. For example, the following syntax allows you to transmit a list of all the flights related to the passengers of airplane 1 inside XML elements <type entity = flight ">, a list of all the passengers on board the airplane inside XML elements <type entity = "tooth"> and a list of all records of passenger names within elements <entity type = "NRP"> and a list of possible relocations within elements <entity type = "realoj">. the sections within the XML elements (customer, flight, PNR and realoj) as listed below are a simplified example that is not exhaustive, the order of a content within a JSON object need not be guaranteed and therefore may vary.

The sample syntax resulting from the update response message looks like this:

<? xml version = "1.0" encoding = "UTF-8"?>

<responseDataABordo>

<IdFlight> ID OF THE FLIGHT </IdFlight>

<revision> REVISION NUMBER </revision>

<revisionPrevious> REVIEW PREVIOUS GIVEN (POSSIBLY EMPTY) </revisionPrevious>

<groupEntity type = "flights">

<entity type = "flight" id = "ID OF THE FLIGHT">

{"numberVuelo": NUMBER OF FLIGHT,

"puntoAbord": IATA CODE OF THE DEPARTURE AIRPORT,

"FechaSalida": DATE WITH THE FORMAT yyyy-mm-dd,

"horaSalida": TIME OF DEPARTURE WITH THE FORMAT hh: mm: ss,

... ADDITIONAL FLIGHT INFORMATION HERE ...} </entity>

... ADDITIONAL FLIGHTS HERE ...

</groupEntity>

<groupEntity type = "customers">

<entity type = "customer" id = "ID OF THE CUSTOMER">

{"uci": CUSTOMER'S UNIQUE ID (USED IN CM),

"numberSeat": SEAT NUMBER,

"surname": SURNAME,

"name": NAME,

"title": TITLE,

"numberViajFrec": NUMBER OF FREQUENT TRAVELER,

... ADDITIONAL PASSENGER INFORMATION HERE ...}

</entity>

... ADDITIONAL PASSENGERS HERE ...

</groupEntity>

<groupEntity type = "pnr">

<entity type = "pnr" id = "ID OF PNR">

{"locatorRegistro"; REGISTRY LOCATOR NUMBER,

"surname": SURNAME,

"NumeroTelef": TELEPHONE NUMBER AS SHOWN IN THE PNR,

... ADDITIONAL INFORMATION ON PNRAQUÍ, ...}

</entity>

... MORE PNRADITIONALS HERE ...

</groupEntity>

<groupEntity type = "realoj">

<entity type = "realoj" id = "ID OF THE REHOUSE">

{"type": TYPE OF ACTIVITY,

"prepaid": BOOLEANO,

... ADDITIONAL INFORMATION ABOUT THE RETREAT HERE ...}

</entity>

... ADDITIONAL RELOCATIONS HERE ...

</groupEntity>

</ResponseDataABordo>

To continue with the specific update request example given above (first the update example given above without any Forced update elements ), a particular update response example is now given that responds to the previous request example. Since this request example indicated a previous revision number, the ground server calculates the trip related and flight related data that differ compared to the old and the current revision number and only returns the data records ( passengers, flights, PNRs and accommodations) that have been changed or added. Likewise, if a particular data record (for example, a flight, a passenger, a p Nr or a relocation) has been deleted on the ground server since the last update indicated by the previous revision parameter , then the update response signals this by marking the corresponding entity:

<entity type = "customer" id = "2416255A00005580" delete = "true" />

Therefore, an example update response message that returns updated flight related and travel related user data from the ground server 3 to the onboard server 2 in response to the above update request example has the following appearance:

<? xml version = "1.0" encoding = "UTF-8"?>

<responseDataABordo>

<IdVuelo> PRD_BA_175_LHR_2014-09-10 </IdVuelo> <revision> 1416325941.226919 </revision> <revisionAnterior> 1416325741.624919 </revisionAnterior>

<groupEntity type = "flights">

<type entity = "flight"

id = "PRD_BA_175_LHR_2014-09-10">

{"lineaAerea": "BA",

"numberVuelo": 175,

"puntoAbord": "LHR",

"dateSalida ":" 2014-09-10 ",

"horaSalida": "09:30:00",

...}

</entity>

</groupEntity>

<groupEntity type = "customers">

<entity type = "customer" id = "2416255A00005580" delete = "true" />

<entity type = "customer" id = "2416255A00005590">

{"uci": "2416255A00005590",

"NumeroAsiento": "027B",

"surname": "Dupont",

"name": "Alice",

"title": "Miss",

"numberViajFrec": "987654321E",

...}

</entity>

</groupEntity>

<groupEntity type = "pnr" />

<groupEntity type = "realoj" />

</ResponseDataABordo>

If the previous update request 45 included one or more Force update items , the corresponding update response will be in the identical format as shown above. It is possible that even after a forceful update on a PNR, it turns out that this information remains unchanged. Therefore, in this case, this PNR should not be returned in the response. In conclusion, a forced update on an entity does not guarantee its presence in the response.

An example registration screen corresponding to the above implementation example is shown in FIG. 14. In this example, the user has the ability to register in the PNR application by filling in the input mask with the remaining digits from his cell phone. After a successful registration, the details of the current trip are presented to the user (FIG. 15) as they have been uploaded to the on-board server 2 prior to take-off and potentially updated during the in-flight phase as described in detail above. . As shown in FIG. 15, the user also has the ability to change connecting flights and / or seats during the in-flight phase (buttons "Change my flight", "Change my seat"), for example using the user data modification scheme such as described above with reference to FIGS. 12 and 13.

In addition to the functionalities described above, the on-board server 2, in some embodiments, is programmed to perform additional functionalities related to secure communication and / or efficient use of the wireless interface 4 during the flight phase, such as

- protection by means of a firewall that prohibits external infiltration,

- promote fault tolerance, for example by using a RAID (Redundant Array of Independent Disks) system,

- control and pack a plurality of update requests 44 and requests for modification of user data 80 of the terminal, for example accumulating incoming requests 44, 80 during a given period of time and transmitting an aggregated update request 45 that undertakes all requests accumulated 44, 80 (as opposed to placing a respective update request 45 individually for each simple terminal request 44, 80). This improves the utilization of the wireless interface by reducing the number of messages to be exchanged between the on-board server 2 and the ground server 3, and thereby reduces the corresponding overhead caused by each message transmission.

- favor the reliability of communication through the use of ARQ mechanisms (automatic repetition request); me

- record the network traffic within the aircraft's local network between the on-board server 2 and the on-board devices 5, 6 as well as the remote network traffic between the on-board server 2 and the ground server 3 in a file of registry. This allows future analysis of the message exchange to further improve and refine the communication scheme implemented by the onboard server 2.

Finally, FIG. 16 provides a block diagram illustrating the components of an on-board server 2. The example server 2 includes at least a processor 11, a user interface 12, a network interface 14 for connection to on-board devices 5, 6, a 3G / 4G / 5G / SatCom network interface 9 and a memory 16.

The at least one processor 11 includes at least one hardware-based microprocessor and accesses memory 16. For interface with a user during both the ground phase and the flight phase, the on-board server 2 includes a user interface 12 that incorporates one or more input / output devices such as a keyboard, a pointing device, a screen, a touch screen, etc.

In another form, the data can be communicated to and from another computer or terminal through a network interface 114 coupled to the communication network 103.

Memory 16 may include on-board server random access memory (RAM) with main operational storage (for running the operating system 17, managing user data update 22, and running server applications 19), as well as any supplemental levels of memory, for example caches, non-volatile or spare memories (for example, programmable or flash memories), read-only memory, etc. and one or more mass storage devices such as internal hard disk storage devices, external hard disk storage device, storage area network device, etc.

The memory 16 of the on-board server 2 generally stores one or more repositories or databases including, for example, an entertainment content database 18, an application store 21, a seat entertainment database 20 and a repository of user data 23. The databases 18, 20, 21, 23 can function according to given data structures and support data structures according to which the data stored in the databases 18 is stored, 20, 21, 23. In particular, databases 18, 20, 21,23 can be arranged with any organization and / or database structure including, but not limited to, a relational database, a database hierarchical, a network database and / or combinations thereof. A database management system in the form of a computer software application that runs as instructions in an on-board server processing unit 2 can be used to access information or data stored in database records in response to a query, in which a query can be dynamically determined and executed by operating system 17, user data update management 22 and / or executed server applications 19. For example, databases 18, 20 , 21, 23 can be used through the use of a structured query language (SQL) or any variation thereof.

The on-board server 2 operates under the control of the operating system 17 and runs or is otherwise based on various computer software applications (including the user data update management module 22 and the server applications 19), components, programs, objects, modules, engines, data structures, etc. In general, the user data update management module 19 and the executed server applications 19 are configured to interface with the databases / repositories 18, 20, 21, 23 to perform the functions of the on-board server 2 described in detail above.

The entertainment content database 18 includes content intended to be streamed to the seat entertainment terminals 5 (and also, if appropriate, to personal communication devices 6), such as movies, music and images. . The streaming of this multimedia content can be carried out by means of a multimedia server running on the on-board server 2. The multimedia server as well as any other server applications are running in a logical area of memory 16, named in FIG. 16 as executed server applications 19. The user data made available to the on-board devices 5, 6 by the various server applications is stored in a user data repository 23. For example, a web server may run on the memory area 19 that stores content of frequently requested websites (= user data) in the repository 23 to access these websites stored by the on-board devices 5, 6 during the flight phase. In addition, the onboard server 2 maintains a seat entertainment database 20 that includes management data of the seat entertainment devices 5, such as seat number, PNR of the passenger currently using the device 5, 6, addresses IP, MAC addresses, current status, capabilities, etc. Furthermore, similar management data in relation to the personal communication devices 6 registered in the aircraft's local network can be kept in the seat entertainment database 20. The application storage module 21 stores the client application code that it can be picked up, installed and run by on-board devices 5, 6 (in particular by personal communication devices 6 which may not have client software installed). The user data update management module 22 is reserved to execute the computer program instructions that implement the communication and management functions of the on-board server to realize the communication scheme with the ground server 3 and the on-board devices 5 , 6 as explained in detail above.

Claims (13)

1. A method for data communication from an on-board server (2) that is installed in an aircraft (1) and that is coupled through a wireless interface (4) to a server on the ground (3) that is located remotely with respect to the plane (1), comprising the method: - receiving, from the on-board server (2) from the ground server (3), executable application code and user data prior to take-off of the aircraft (1), in which at least a first part of the application code executable refers to an on-board server operating system (2) and at least a second part of the executable application code refers to at least one seat entertainment terminal (5) mounted inside the aircraft (1) and / or is refers to at least one personal mobile terminal (6) of a user on board the aircraft (1); - storing by the on-board server (2), prior to take-off from the plane (1), the user data; - install and execute by the on-board server (2), prior to the take-off of the aircraft (1), the first received part of the executable application code, thereby updating the operating system of the on-board server (2); - distribute the second part of the executable application code received for the installation and execution of at least one terminal via the on-board server (2), prior to take-off of the plane (1) and / or after take-off of the plane (1) seat entertainment (5) and / or the at least one personal mobile terminal (6); - receive, from the on-board server (2) from the ground server (3), delta user data and delta executable application code after take-off and before landing of the aircraft (1), updating the delta user data the user data received prior to take-off by forming updated user data and updating the executable application code delta the first part of the executable application code and / or updating the second part of the executable application code received prior to the aircraft take-off (1) ; - transmit, by the on-board server (2), after take-off and before landing of the aircraft (1), at least a part of the updated user data for the at least one seat entertainment terminal (5) mounted inside of the aircraft (1) and / or the at least one personal mobile terminal (6) of a user on board the aircraft (1) for the presentation of the updated user data transmitted to the user; - install and run by the on-board server (2), after take-off and before landing of the aircraft (1), the first updated part of the received executable application code, thereby updating the operating system of the on-board server (2 ); - distribute by the on-board server (2), after take-off and before landing of the aircraft (1), the second updated part of the executable application code received for the installation and execution of at least one seat entertainment terminal (5 ) and / or the at least one personal mobile terminal (6), wherein the reception of the delta user data is triggered by an update request (45) sent by the onboard server (2) to the ground server (3) periodically, and wherein the method further comprises setting, by the on-board server (2), an update period (57) for sending the update request (45) periodically depending on a number and requested content of the requests for updates. content collection from the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6) or depending on the amount of delta user data previously received from the ground server (3). The method of claim 1, wherein the update request (45) is also sent by the on-board server (2) depending on a flight phase of the aircraft (1), depending on a geographical location of the aircraft (1), in response to determining an availability of the wireless interface (4) after a period of unavailability of the wireless interface (4), or a combination thereof. The method of claim 1 or claim 2, wherein the update request (45) sent by the onboard server (2) is triggered by a terminal update request (45) by the entertainment terminal. seat (5) or by the personal mobile terminal (6) to the on-board server (2). 4. The method of any of claims 1 to 3, further comprising: - during the transmission of an update request (45) from the on-board server (2) to the ground server (3), after take-off and before landing of the aircraft (1), to be determined by the on-board server (2) an unavailability of the wireless interface (4) with the server on the ground (3); and - transmitting, by the on-board server (2), at least one element of the user data received by the on-board server (2) prior to take-off and / or at least one updated user data element consisting of user data delta previously received to the seat entertainment terminal (5) and / or the personal mobile terminal (6). The method of any of claims 1 to 4, wherein the delta user data includes a version identifier and a subsequent update request (45) that occurs after the update request (45) requesting data Additional delta user data includes the version identifier including a version of the delta user data previously received by the onboard server (2) in response to the update request (45). The method of claim 5, wherein the additional delta user data represents only differences between the updated user data available on the on-board server (2) when the subsequent update request (45) is transmitted to the ground server (3) and a current version of the user data that is available on the ground server ( 3) when the subsequent update request (45) is received. The method of any of claims 1 to 6, wherein the user data comprises flight-related data including passenger name registration data of the passengers on board the aircraft (1), wherein the update request (45) includes a flight identifier and the delta user data comprises updated passenger name record data of passengers on board the aircraft (1) including current information about connecting flights and / or accommodation of passengers on board the plane (1). The method of any of claims 1 to 7, further comprising, after take-off and before landing of the aircraft (1): - receiving by the on-board server (2) a request from the seat entertainment terminal (5) or the personal mobile terminal (6) to modify at least one element of the user data stored in the ground server (3) or another server that is remote from the plane (1); - transmit, by the on-board server (2) to the ground server (3), the request to modify the at least one element of the user data stored on the ground server (3) being another remote server with respect to the aircraft ( one); - receive, by the on-board server (2) from the ground server (3), a response to the request to modify the at least one element of the user data stored on the ground server (3) being another server remote from the plane (1). The method of claim 8, wherein the response includes the delta user data. 10. An on-board server (2) that is installed in an aircraft (1) and that is coupled through a wireless interface (4) to a server on the ground (3) that is located remotely from the aircraft (1), the on-board server (2) being arranged to: - receiving executable application code and user data from the server on the ground (3) prior to take-off of the aircraft (1), in which at least a first part of the executable application code refers to an operating system of the on-board server (2) and at least a second part of the executable application code refers to at least one seat entertainment terminal (5) mounted inside the aircraft (1) and / or refers to at least one personal mobile terminal (6) of a user on board the aircraft (1); - storing user data prior to take-off of the aircraft (1); - installing and executing the first received part of the executable application code, thereby updating the operating system of the on-board server (2) prior to take-off of the aircraft (1); - distribute the second part of the executable application code for installation and execution in the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6), prior to take-off from the plane (1) and / or after take-off of the aircraft (1); - receive delta user data and delta executable application code from the ground server (3) after take-off and before landing of the aircraft (1) updating the delta user data the user data received prior to take-off forming user data updating, and updating the executable application code delta the first part of the executable application code and / or updating the second part of the executable application code received prior to take-off of the aircraft (1); - transmitting, after take-off and before landing of the aircraft (1), at least a part of the updated user data for the at least one seat entertainment terminal (5) mounted inside the aircraft (1) and / or the at least one personal mobile terminal (6) of a user on board the aircraft (1) for the presentation of the updated user data transmitted to the user; - installing and executing the first updated part of the received executable application code, thereby updating the operating system of the on-board server (2), after take-off and before landing of the aircraft (1); - distribute the second updated part of the executable application code for installation and execution in the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6), after take-off and before landing of the airplane (1), wherein the on-board server (2) is arranged to send an update request (45) to the ground server (2) periodically, triggering the reception of delta user data and wherein the on-board server (2) is further arranged to set an update period (57) for sending the update request (45) periodically depending on a number and requested content of the content collection requests from the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6) or depending on the amount of delta user data previously received from the ground server (3). The onboard server (2) of claim 10 which is further arranged to perform the method of any of claims 2 to 9. 12. A computer program to be executed by an on-board server (2) that is installed on an airplane (1) and that is couples through a wireless interface (4) to a server on the ground (3) that is located remotely from the plane (1), the computer program being configured - when executed by the on-board server (2) - to cause the onboard server (2): - receiving executable application code and user data from the server on the ground (3) prior to take-off of the aircraft (1), in which at least a first part of the executable application code refers to an operating system of the on-board server (2) and at least a second part of the executable application code refers to at least one seat entertainment terminal (5) mounted inside the aircraft (1) and / or refers to at least one personal mobile terminal (6) of a user on board the aircraft (1); - storing the user data prior to taking off the plane (1); - installing and executing the first received part of the executable application code, thereby updating the operating system of the on-board server (2) prior to take-off of the aircraft (1); - distribute the second part of the executable application code for installation and execution in the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6), prior to take-off from the plane (1) and / or after take-off of the aircraft (1); - receive delta user data and delta executable application code from the ground server (3) after take-off and before landing of the aircraft (1), updating the delta user data the user data received prior to take-off forming data from user updated and updating the executable application code delta the first part of the executable application code and / or updating the second part of the executable application code received prior to take-off from the aircraft (1); - transmit, by using at least a part of the application code executed and after take-off and before landing of the aircraft (1), at least a part of the updated user data for the at least one seat entertainment terminal (5) mounted inside the aircraft (1) and / or the at least one personal mobile terminal (6) of a user on board the aircraft (1) for the presentation of the updated user data transmitted to the user; - installing and executing the first updated part of the received executable application code, thereby updating the operating system of the on-board server (2), after take-off and before landing of the aircraft (1); - distribute the second updated part of the executable application code for installation and execution in the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6), after take-off and before landing of the airplane (1), in which the computer program is configured - when run by the on-board server (2) - to make the on-board server (2) send an update request (45) to the on-board server (2) periodically, activating the reception of delta user data and in which the computer program is additionally configured - when executed by the on-board server (2) - to make the on-board server (2) set an update period (57) for sending the update request (45 ) periodically depending on a number and requested content of the content collection requests from the at least one seat entertainment terminal (5) and / or the at least one personal mobile terminal (6) or depending on the amount of delta user data previously received from the ground server (3). The computer program of claim 12 which is configured - when run by the on-board server (2) - to cause the on-board server (2) to perform the method of any of claims 2 to 9.