TECH N ICAL FI ELD

The present invention lies in the general technical field of aviation industry and aviation data handling . More particular it lies in the field of Departure Control Systems ( DCSs) and associated equipment. In particular, the present invention relates to a method for exchanging data in a common use DCS between a DCS unit and at least one All-in-One (AiO) common use self-service (CUSS) module, as well as to a common use DCS, comprising at least one All-in-One (AiO ) Common Use Self-Service (CUSS) module.

BACKGROU N D

Departure control systems ( DCSs) process and handle a large variety of aviation-related data. Such data include flight-related data of specific flights and/or passengers, e. g. Passenger Name Lists and Additional Deleting Lists. The data that are processed and handled by a DCS further include general airline related data, such as seasonal flight schedules, aircraft fleet databases, seat maps of the aircrafts, and the like. Current DCSs are further designed to exchange data with other DCSs, e. g. for through-check-in purposes, and to communicate with airport information systems, e. g. for sending post departure messages in accordance with the IATA ( International Air Transport Association ) standards. The DCSs belong to the backbone of the IT infrastructure of the airlines and are located worldwide in operation and computing centres of the airlines. For check-in and boarding, data exchange is required between terminal devices, in particular check-in counters, self- check-in kiosks and gate agent's work stations at a departure airport, and the DCS of the corresponding airline. DCSs and terminals are supplied from a number of suppliers. Data exchange between the DCS and the terminals at the airport typically relies on Internet connections.

SU M MARY OF DICLOSU RE

In spite of generally advanced present state of aviation data management and the availability of proven and sophisticated DCSs, a number of problems and drawbacks exists with present systems under typical and particularly under untypical and adverse operational conditions.

For example, the typical present architecture of central DCSs and terminal devices at the airports relies on substantially continuous and uninterrupted ( Internet) communication between the DCSs and the airport terminals. This communication requirement is world- wide and includes countries and/or areas of comparatively little IT infrastructure of and/or IT infrastructure of limited performance. Even if sufficient communication performance is generally available, the required amount of data communication is enormous for larger (international) airports, an aspect that is expected to further increase in importance due to foreseeable air traffic increases. It is accordingly desirable to reduce/limit the amount of data traffic between airports and external data centres where the DCSs are typically installed, and/or improve the robustness with respect to limitations/interruptions of the data communication. A further drawback of the aviation data handling , particularly flight-related data handling, according to the present state of the art is a huge amount of paper that is required for printing boarding passes and/or baggage tags which are used for only a very limited of period of time and are subsequently discarded, which is of both financial and environmental impact. It is accordingly desired to reduce (and ideally largely avoid ) the need for printed boarding passes and/or baggage tags.

Especially larger ( international ) airports frequently face the problem that passengers that are booked and validly checked in for a specific flight do not show up at the gate in time. At present, such passengers are publicly announced and requested to proceed to the gate. This procedure is known to be unsuccessful in a significant number of cases. Besides from the passenger missing the flight, this situation req uires considerable additional effort, such as removing the passenger from the passenger name list, removing the baggage, and booking the passenger for a subsequent flight. It is accordingly desirable to improve the methods for informing a passenger who is likely to miss a flight and increase the chance of the passenger to show up at the gate in time for boarding.

Moreover, it has to be considered that according to the prior art, common check-in procedures or at least baggage-drop procedures after a mobile or online check-in of a passenger, are operated by airport staff personnel. The personnel operates check-in kiosks which according to the prior art are connected to a common database of the respective DCS for handling information in relation to the check-in procedure. On the one hand, availability and costs of airport staff personnel may limit check-in capacities. On the other hand, kiosks according to the prior art typically use a common database. However, as already explained above regarding the communication between DCSs and terminal equipment, such usage of a common database relies on substantially continuous and uninterrupted ( Internet) communication between the DCSs and the airport terminals, and hence leads to the above-mentioned problems regarding communication capacities.

It is the overall object of the present invention to improve the state of the art with respect to handling of aviation data, particularly flight-related data. Favourably, the situation with respect to one or more of the above-mentioned aspect is improved. The overall object is solved in a general way by the subject matter of the independent claims. Exemplary and/or particularly favourable embodiments are defined by the dependent claims as well as the overall disclosure of the present document.

According to an aspect, the overall object is achieved by providing a method for exchang ing data in a common use DCS between a DCS unit and at least one All-in-One (AiO) Common Use Self-Service (CUSS) module in at least one of an assisted or a self-check-in mode, by means of a self-organising remote procedure call protocol, wherein the data exchange comprises query data for a number of queries, each query relating to a step in a check-in procedure and including a step name and at least one of an argument, a dictionary object, and an array of elements for carrying out the respective step.

According to another aspect, the overall object is achieved by providing a Common Use Departure Control System ( DCS), comprising: a) at least one All-in-One (AiO) Common Use Self-Service (CUSS) mod ule, adapted to provide at least one of an assisted check-in operation mode and a self-check-in mode, and including an AiO CUSS module communication interface for operatively exchanging information relating to passenger and baggage identification; and b) a data exchange link including a data exchange interface for operatively exchanging data relating to passenger and baggage identification with a DCS unit including a DCS unit communication interface ( 1 0) for operatively exchanging information relating to passenger and baggage identification ; wherein the data exchange interface is adapted to exchange the information relating to passenger and baggage identification with the DCS unit and the at least one AiO CUSS module by means of a self-organizing remote procedure call protocol.

An AiO CUSS module according to the present invention can be used for standard check- in at an airport staff personnel operated kiosk or in self check-in procedures. The module may constitute or at least be a part or type of a multi-mode-check-in station and/or check-in counter. Through the usage of the protocol according to the present invention, each CUSS module merely requires to exchange with the DCS unit an amount of data required for a particular step of a cheque-procedure or sub-steps thereof within a ma- chine-2-machine query-reply system. Each query relates to a step or sub-step of a check- in procedure and is contained together with an argument and/or a dictionary object in a data packet according to the present invention. The ability of the CUSS modules to operate in a self-check-in mode helps in carrying out check-in procedures more independent from available personnel as according to the prior art. Moreover, the self-organising remote procedure call protocol helps to minimise data transfer between the CUSS module and the DCS unit. Besides reducing the amount of transferred data, the protocol enables to reduce polls and customise information ex- change according to requirements of the respective server.

In comparison to the widely spread Hypertext Transfer Protocol ( HTTP) which relies on a permanent data exchange including cookies, web browser the specifications, etc. , the self-organising remote procedure call protocol according to the present invention only requires a comprehensive information exchange upon establishing a connection for the first time. Afterwards, only current information relating to respective query needs to be exchanged between client and server.

Furthermore, HTTP does not mandatorily check whether information sent can be accept - ed and processed by the receiving server. HTTP does also not check, whether sufficient memory space for handling certain data is available on the side of a client or receiver. In contrast to that, the self-organising remote procedure call protocol according to the present invention allows for permanently checking on the side of the server, whether a receiver, client or third party server provides data or file type acceptability and/or data stor- age capacity. Thereby, the protocol helps to guarantee that transfer data is delivered to a receiver and processed by the receiver.

Additionally, the self-organising remote procedure call protocol according to the present invention allows for integrating CUSS mod ules according to the present invention into any existing DCS infrastructure. Any split DCS system described herein may comprise or become a Common Use DCS according to the present invention by the implementation of at least one AiO CUSS Module according to the present invention to be used as a check-in counter or at least part thereof.

The solutions of the overall object according to the present invention can be further improved by the following embodiments of the present invention which may be inde- pendently combined with each other as required by a certain application.

According to a first further embodiment of a method according to the present invention, based on the query data, reply data is sent from the DCS unit to the AiO CUSS module, wherein each query data and each reply data are sent as data packets having a defined packet number which is increased by a defined value for each query. Data packets according to the present invention help in omitting unnecessary data transfer between the AiO CUSS module in the DCS unit in that they deliver information confined to a certain step or sub-step within a cheque-procedure. Data packets relating to a certain query preferably are identified by an identical packet number of the respective query data packet and reply data packet. By increasing the packet number by a defined value, such as a counter of an integer value like simply " 1 ", every query and respective reply can be unequivocally identified.

According to a further embodiment, a method according to the present invention comprises the steps of: a ) generating airline availability request data at the AiO CUSS module; b) sending the airline availability request data from the AiO CUSS module to the DCS unit; c) generating airline availability data based on the airline availability request data at the DCS unit; d ) sending the airline availability data from the DCS unit to the AiO CUSS module; e) displaying the airline availability data at the AiO CUSS module; f) retrieving airline selection data based on a selection from the airline availability data entered at the AiO CUSS module; g ) g. sending the airline selection data from the AiO CUSS module to the DCS unit.

Steps a ) to g ) described above relate to a query and response scheme concerning availability and selection of airlines at a certain AiO CUSS module. Hence, steps a ) to g ) may also be regarded as sub-steps of a first step in a check-in procedure for selecting an airline with which the check-in is to be performed. If of course the respective AiO CUSS module where the check-in procedure is carried out is explicitly assigned to a single airline only or if there is only a single airline available at the respective terminal or airport, steps a ) to g ) may also be omitted. Steps a ) to g ) may also be omitted if a boarding pass has already been issued to a passenger, e.g. in that the passenger already performed an online or mobile check-in and thus has printed out or loaded onto a mobile device, respectively, boarding pass information.

According to a further embodiment, a method according to the present invention comprises the steps of: h ) retrieving flight data entered at the AiO CUSS module; i) sending the flight data from the AiO CUSS module to the DCS unit; j) generating passenger list data based on the flight data at the DCS unit; k) sending the passenger list data from the DCS unit to the AiO CUSS

module;

I) retrieving passenger data entered at the AiO CUSS module; m) identifying the passenger by the passenger list data and the passenger data at the AiO CUSS module.

Steps h ) to m ) described above relate to a query and response scheme for the selection and identification of a passenger to be checked-in at a certain AiO CUSS module. Hence, steps h ) to m) may also be regarded as sub-steps of a second step in a check-in procedure for selecting a passenger for whom the check-in is to be performed. These steps, especially step m) may be repeated for each passenger of a predefined group of passengers to be checked-in for the same flight. Steps h ) to m) may be omitted if a boarding pass has already been issued to a passenger, e.g. in that the passenger already performed an online or mobile check-in and thus has printed out or loaded onto a mobile device, respectively, boarding pass information.

According to a further embodiment, a method according to the present invention comprises the steps of: n ) sending a passenger identification from the AiO CUSS module to the DCS unit; o) generating an airplane seat map at the DCS based on the passenger identification; p) sending the airplane seat map from the DCS unit to the AiO CUSS module; q ) retrieving seat selection data entered at the AiO CUSS module; r) assigning to the passenger a seat data in the airplane seat map based on the seat selection data at the AiO CUSS module.

Steps n ) to r) described above relate to a query and response scheme for assigning a certain seat to an identified passenger at a certain AiO CUSS mod ule. Hence, steps h) to m ) may also be regarded as sub-steps of a third step in a check-in procedure for selecting a seat for a passenger previously identified. Steps n ) to r) may be omitted if a boarding pass has already been issued to a passenger, e.g. in that the passenger already performed an online or mobile check-in and thus has printed out or loaded onto a mobile device, respectively, boarding pass information.

According to a further embodiment, a method according to the present invention comprises the steps of: s) sending passenger seat data from the AiO CUSS module to the DCS unit; t) generating passenger check-in confirmation data based on the passenger seat data at the DCS unit; u) sending the passenger check-in confirmation data from the DCS unit to the AiO CUSS module; v) displaying the passenger check-in confirmation data from at the AiO CUSS module.

Steps s) to v) described above relate to a query and response scheme for confirming check-in of an identified passenger having a seat assigned at a certain AiO CUSS module. Hence, steps s) to v) may also be regarded as sub-steps of a fourth step in a check-in procedure for confirming information and a preferred seat for a passenger previously identified. Steps s) to v) may be omitted if a boarding pass has already been issued to a passenger, e.g. in that the passenger already performed an online or mobile check-in and thus has printed out or loaded onto a mobile device, respectively, boarding pass information.

According to a further embodiment, a method according to the present invention comprises the steps of: w) generating baggage check-in request data at the AiO CUSS module; x) sending the baggage check-in request data from the AiO CUSS module to the DCS unit; y) generating baggage data request data based on the baggage check-in request at the DCS; z) sending the baggage data request data from the DCS unit to the AiO CUSS module. Steps w) to z) described above relate to a query and response scheme for requesting a baggage check-in at a certain AiO CUSS module. Hence, steps w) to z) may also be regarded as sub-steps of a fifth step in a check-in procedure for requesting baggage check- in. Steps w) to z) may be omitted if there is no baggage to be checked-in.

According to a further embodiment, a method according to the present invention comprises the steps of: aa) retrieving baggage data entered at the AiO CUSS module; bb) sending the baggage data from the AiO CUSS module to the DCS unit; cc) generating baggage check-in confirmation data based on the baggage data and the passenger identification data at the DCS unit; dd ) sending the baggage check-in confirmation data from the DCS unit to the AiO CUSS module; ee) displaying the baggage check-in confirmation data at the AiO CUSS module.

Steps aa ) to ee) described above relate to a query and response scheme for baggage check-in at a certain AiO CUSS module. Hence, steps aa ) to ee) may also be regarded as sub-steps of a sixth step in a check-in procedure for baggage check-in. Steps aa) to ee) may be omitted if there is no baggage to be checked-in.

According to a further embodiment, a method according to the present invention comprises the steps of: ff ) generating baggage identification data at the AiO CUSS module; gg ) issuing the baggage identification data at the AiO CUSS module; hh) generating baggage identification issue confirmation data at the AiO CUSS module; ii) sending the baggage identification issue confirmation data from the AiO CUSS mod ule to the DCS unit.

Steps ff) to ii) described above relate to a query and response scheme for issuing baggage identification data after having checked -in baggage at a certain AiO CUSS module. Hence, steps ff) to ii ) may also be regarded as sub-steps of a seventh step in a check-in procedure for issuing baggage identification data. Steps ff) to ii) may be omitted if there is no baggage to be checked -in.

In another embodiment of a method according to the present invention, issuing the baggage identification data involves issuing a Radio-frequency identification ( RFI D) baggage chip. Information about the passenger and the baggage can be at least temporarily stored on the RFI D baggage chip. Such an RFI D baggage chip can be used in a baggage handling system ( BHS) and/or a baggage reconciliation system ( B RS) comprising an RFI D baggage gate according to the present invention. The information stored on the RFI D baggage chip enables to process and control any transportation, handling, loading and unloading of baggage equipped with R FI D baggage chips.

An R FI D baggage chip according to the present invention may be attached to a piece of baggage as a R FI D baggage tag issued by the Aio CUSS or otherwise handed out to a passenger or airport staff personnel in order to be attached to luggage. Alternatively, the baggage chip may be integrated into the luggage and the AiO CUSS module according to the present invention can write baggage identification data onto the integrated RFI D baggage chip as well as read data therefrom. In the baggage claim area, and RFI D baggage chip or tag makes it possible to identify passengers accord ing to the baggage and vice versa in a fully or at least half automated way. Data from the R FI D baggage chip or tag maybe displayed on monitors to passengers claiming their baggage, to security personnel and/or airport staff personnel. Such a solution could for example be deployed in the vicinity of a baggage claim belt.

The baggage handling system can scan and analyse all piece of baggage passing certain control points and then display data from relating to the data stored on the R FI D baggage chip or tags to whomever it concerns, for example for enabling an owner of a respective piece of baggage to identify the baggage on a display at custom area. It is also possible to add an additional control layer to baggage claim areas by introducing is secure baggage receipt module to prevent an unauthorised baggage claim by a person who accidentally or deliberately claims baggage not belonging to that person.

A Secure baggage receipt module can for example be deployed in the vicinity of an exit of a baggage claim area. Such an exit of a baggage claim area usually constitute an entrance of a customs area in such a customs area exists. Security and/or customs personnel can check the baggage identification data from the R FI D baggage chip or tag and is thus able to monitor passenger and the baggage when passing a secure baggage receipt module, which may thus be part of or constitute an RFI D checkpoint for baggage according to the present invention. The baggage identification data may comprise a name, passenger number, flight number, photograph scanned in during the retrieval of baggage identification data, contact details, or alike. Such data can be counted checked by the personnel by means other identification means of the passenger, such as a passport, I D-card or an RFI D boarding pass as described in detail further down below.

According to a further embodiment, a method according to the present invention comprises the steps of: jj) generating boarding pass data at the AiO CUSS; kk) issuing the boarding pass data at the AiO CUSS;

II) generating boarding pass issue confirmation data at the AiO CUSS; mm) sending the boarding pass issue confirmation data from the AiO CUSS module to the DCS.

Steps jj ) to mm) described above relate to a query and response scheme for issuing boarding data after having completing check-in baggage of a passenger and/or baggage at a certain AiO CUSS module. Hence, steps jj ) to mm) may also be regarded as sub-steps of a eighth step in a check-in procedure for completing check-in and/or issuing boarding pass data. Steps jj) to mm) may be omitted if a boarding pass has already previously been issued.

In another embodiment of a method according to the present invention, issuing of the boarding pass data involves issuing a RFI D boarding chip. Hence, issuing the boarding pass data may involve exchanging a paper or digital boarding pass which has been previ- ously printed out loaded onto a mobile device by a passenger after online or mobile check-in, respectively, with an R FI D boarding chip. The usage and operation of such an RFI D boarding chip according to the present invention will be described in detail further down below.

In another embodiment of a method according to the present invention , wherein the da- ta retrieved at the AiO CUSS module is entered by the passenger. Hence, the passenger may carry out all above-mentioned steps of a check-in procedure according to the present invention on his own and/or in an airport staff assisted mode. In another embodiment of a system according to the present invention, the at least one AiO CUSS module includes or is operatively connected to an RFI D communication unit, the RFI D communication unit being configured to exchange flight-related data, in particular flight-related data of a specific passenger, with an R FI D chip. The R FI D communication unit may exchange communication with both, R FI D boarding passes and R FI D baggage chips or tags. Further functionality and operation of the RFI D communication unit will be described in detail further down below.

In another embodiment of a system according to the present invention, the at least one DCS unit is configured to associate the specific passenger with a passenger identification code, the passenger identification code being pre-stored on an RFI D boarding chip. Such a configuration of the DCS unit and operation of a system according to the present invention with pre-stored identification codes will be described in detail further down below.

In another embodiment of a system according to the present invention, the at least one DCS unit includes or is operatively coupled to a boarding RFI D reader and is configured to read the passenger identification code that is stored on an RFI D boarding chip which is presented to the boarding R FI D reader, wherein the DCS unit is further configured to change a passenger status in response to reading the passenger identification code. Such a configuration of the DCS unit and operation of a system according to the present invention with the boarding RFI D reader will be described in detail further down below.

In another embodiment of a system according to the present invention, the at least one DCS unit is configured to determine if an overweight surcharge is due for a specific piece of baggage of a specific passenger and to associate this specific passenger with a passenger identification code on an RFI D chip and/or issue a boarding pass only after payment of the overweight surcharge. Such a configuration of the DCS unit and operation of a system according to the present invention in connection with overweight surcharge will be described in detail further down below.

In another embodiment of a system according to the present invention, baggage identification data is indicative for a specific piece of baggage and a specific flight, and wherein the R FI D communication unit includes an RFI D prog rammer, and wherein the at least one AiO CUSS module is configured to program the baggage identification data into an R FI D baggage chip, the RFI D baggage chip being associated with the piece of baggage. The Association of the R FI D baggage chip to a certain baggage piece and passenger offers advantages as described above with respect to a method according to the present inven- tion.

In another embodiment of a system according to the present invention, the at least one DCS unit comprises at least one of a central DCS unit and an airport DCS unit located remote from the central DCS unit, the at least one airport DCS unit including an airport DCS unit communication interface for operatively exchanging information relating to passen- ger and baggage identification; wherein the data exchange interface is further adapted to exchange the information relating to passenger and baggage identification with the at least one airport DCS unit by means of at least one airport DCS protocol associated to the airport DCS unit.

According to an aspect, the overall object is achieved by providing a Departure Control System ( DCS). The DCS includes a central DCS unit, the central DCS unit including a central DCS unit communication interface for operatively connecting to and exchanging information with at least one airport DCS unit remote from the central DCS unit. The DCS further includes at least one airport DCS unit, the at least one airport DCS unit including an airport DCS unit communication interface for operatively connecting to and exchang- ing information with the central DCS unit. The central DCS unit is designed to execute a set of central DCS routines and the at least one airport DCS unit is desig ned to execute a set of airport DCS routines. The at least one airport DCS unit includes or is operatively connected to an R FI D communication unit, the R FI D communication unit being config- ured to exchange flight-related data, in particular flight-related data of a specific passenger, with an RFI D chip.

As will be discussed in more detail further below, more than one RFI D communication unit may be present in some embodiments. Routines, in particular routines that are implemented on the airport DCS unit for the R FI D communication also referred to as R FI D communication routines. Furthermore, data may be exchanged with more than one RFI D chip respectively type of R FI D chips, particularly with boarding RFI D chips and baggage RFI D chips as also discussed further below. The one ore more R FI D communication unit(s) may include one or more R FI D reader(s) and/or RFI D programmer(s) .

A DCS in accordance with the present disclosure that comprises a central DCS unit and one ore more airport DCS unit as described before is also referred to as split DCS in the following.

For carrying out the central DCS routines, functional central DCS modules are present; similarly, for carrying out the airport DCS routines, functional airport DCS mod ules are present. A separate and dedicated functional central DCS module respectively functional airport DCS module may be provided for each of the central DCS routines respectively airport DCS routines and may be designed for executing the corresponding routine. Alternatively, however, a number of central DCS routines respectively airport DCS routines may be carried out by a common functional central DCS module respectively functional airport DCS module. Likewise, a single central airport DCS routine respectively airport DCS routine may involve a number of two or more functional units and execution may be shared between them. Both the central DCS unit and the airport DCS unit are typically realized as computerized devices or systems with one or (typically) a plurality of processors as well as associated components, such as memory, databases, mass storages, ter- minal devices and the like.

The central DCS unit communication interface and the airport DCS unit communication interface are typically designed for coupling via Internet, but may additionally or alternatively also be designed for coupling via any other wired or wireless network and communication technology that is capable of handling the req uired amount of data with suffi- cient reliability.

In an embodiment, the departure control system includes a plurality of airport DCS units. In a typical setup, an airline operates one central DCS unit that is located, like DCSs of the state of the art, in its data centre and , and further has an airport DCS unit at each airport it serves, with the single airport DCS units being separately operatively connected to the central DCS unit. Alternatively or additionally, however, and airline may operate a number of airport DCS units which are substantially independent from each other at the same airport. This may be the case for larger airports/hubs with a corresponding large number of flight-related data handling, and/or for backup purposes.

An airport DCS unit is, in contrast to the central DCS unit, in direct operational interaction with passengers, check-in counter personal, gate agents, and the like. An airport DCS unit accordingly typically comprises communication interfaces for operatively coupling with user interfaces/periphery devices, such as check-in counter terminals, self check-in kiosks, boarding pass printers, baggage tag printers, and the like. Typically, an airport DCS unit and its communication interfaces are designed for operatively coupling with a plurality of periphery devices as mentioned above, such as a plurality of check-in counter terminals and self check-in kiosks. Alternatively or additionally, however, an airport DCS unit may be realized integral with one or more periphery devices, in particular with a check-in counter terminal or a self check-in kiosk. In an embodiment, the set of central DCS routines is at last in part different from the set of airport DCS routines. As a general rule, the central DCS routines include "high-level" routines that are common for all or at least some airports that are served by an airline and in particular routines that do not require on-site interaction with the counter agent or passenger. Typical central DCS routines that are implemented exclusively on the central DCS unit of a split DCS include creating, changing and maintaining the general databases of the airline, in particular an aircraft database with relevant information of typically all aircrafts of an airline. A further central DCS routine that is not implemented on an airport DCS unit is a through check-in routine for through check-in of passengers and/or baggage. Further of such routines that are typically only implemented on the central DCS unit are check-in routines that are typically carried out remote from the departure airport, in particular mobile check-in and ( Internet- based ) online check-in routines.

Typical airport DCS routines that are not implemented on a central DCS unit but only on an airport DCS unit of a split DCS include regular counter and/or kiosk check-in routines in operative coupling with the counter terminal and/or a self check-in kiosk, handling of the local timetable of flights departing from the corresponding airport, passenger boarding routines, or baggage handling routines. It is noted that different airport DCS units of different functionality, that is, with a set of at least partly different airport DCS routines, may be implemented on and executed by different airport DCS units that are located at the same and/or different airports. Furthermore, while most routines will typically be implemented only at a central DCS unit or an airport DCS unit, some overlap may exist between central DCS routines respectively airport DCS routines.

A split DCS architecture in accordance with the present invention generally reduces the data traffic between airports and remote data centres because at least some of the flig ht- related data of passengers and/or baggage can be handled locally, with no or little in- volvement of the central DCS unit and in particular with no or little requirement for realtime data exchange. Furthermore, since the amount of routines that is implemented on a central DCS unit respectively an airport DCS unit is reduced, each of them can be less complex, especially regarding the software and data processing power.

Furthermore, all tasks and routines that can be fully handled locally by an airport DCS unit can be executed even if the operational coupling to the associated central DCS unit is broken or unstable. Particularly regular counter check-in, self check-in, and boarding prior to the departure of an aircraft can be carried out and completed smoothly even without operational coupling to the associated central DCS unit. Whenever operative coupling between the central DCS unit and an airport DCS unit is present, however, which would normally be the case most of the time, data are transmitted and synchronize between the central DCS unit and airport DCS unit or airport DCS units substantially continuously and in real time.

The reduced complexity of a central DCS unit as compared to a present full-fledged DCS further allows an airline to operate several central DCS units, e. g. in different countries, in an economic way. This is particularly favourable in view of potentially different reg ulatory and legal circumstances, different data handling , security, and protection of data privacy requirements.

The at least one airport DCS unit includes an RFI D communication unit which implements an R FI D communication routine as airport DCS routine. The RFI D communication routine includes exchanging flight-related data, in particular flight-related data of a specific passenger, with an RFI D chip. Storing and processing some or favourably all data that are related to the check-in and boarding of a passenger and/or the baggage handling via RFI D technology allows a variety of typical airport routines to be carried out in a faster and smoother way, simultaneously reducing or fully avoiding the number of potential faults and mistakes, as will be explained further below in more detail.

As will further become apparent, the amount of paper that needs to be printed, handled, and subsequently discarded especially for boarding passes and baggage tags, is typically not fully avoided, but can be reduced. However, exclusively relying on RFI D technology for the check-in, boarding, and baggage handling is in principle possible. Typically, routines that are related to RFI D communication, such as writing information into and/or reading information from an RFI D chip are airport DCS routines that are implemented only on airport DCS units, but not on the associated central DCS unit. Accord ing to an embodiment of a system for handling RFI D boarding and/or baggage passes according to the present invention, handling is carried out by the airport DCS, then in particular acting as a slave server. Alternatively and/or additionally, all actions and/or data logs are archived on a master server of the central DCS.

In an embodiment, a number of R FI D communication units and/or different RFI D communication routines is present as will be discussed further below. In an embodiment, the at least one airport DCS unit is configured to associate the specific passenger with a passenger identification code, the passenger identification code being - pre-stored on an RFI D chip. A corresponding routine that includes associating the specific passenger with a passenger identification code is referred to as "RFI D check-in routine" which is implemented and can be executed by the airport DCS unit.

For this type of embodiment, an airline or airport has a pool with a plurality of R FI D chips that are typically attached to or integrated into an e. g. credit card like carrier. For a correspondingly equipped airport, all routines that are related to check-in, baggage drop, and boarding can be handled via the RFI D chip without relying on paper. An R FI D chip carry- ing a pre-stored passenger identification code is in the following also referred to as "boarding RFI D chip" and the corresponding carrier which carries or includes such a chip is referred to as "R FI D boarding pass". Favourably, the boarding R FI D chip is a read -only RFI D chip which, once programmed with a passenger identification code, can only be read, but not allow changing or adding further data. According to a typical embodiment, the passenger identification code is not permanently linked to a specific passenger and/or a specific flight, but to an airport or airline. As explained in more detail further below, the association between a passenger identification code and a specific passenger/specific flight is stored by the airport DCS unit and is only temporary and accordingly non-permanent. As already stated above, all actions and/or data logs may additionally be stored at the central DCS preferably acting as a master server.

The well-known step of printing a boarding pass is, when using an R FI D boarding pass as described, supplemented and potentially replaced by associating the specific passenger and particularly the boarding data of this specific passenger with the passenger identifi- cation code of an R FI D boarding chip. The RFI D boarding card with this R FI D boarding chip is handed to the passenger. Hand ing the R FI D boarding pass to the passenger may be carried out manually e. g . by a counter agent. Alternatively, the airport DCS unit may comprise or be operatively coupled with an RFI D boarding pass output unit that stores a plurality of R FI D boarding passes e. g. in a magazine and provides the R FI D boarding pass to the passenger subsequent to the data association as explained before.

An R FI D boarding pass is generally valid only at a specific airport and in combination with a specific airport DCS unit or set of airport DCS units of an airline and does typically not leave the airport. As discussed further below in more detail, the passenger does especially not carry the RFI D boarding pass when boarding the airplane.

The association of the passenger identification code and a specific passenger is stored only by the airport DCS unit. Favourably, this association is permanently deleted once it is not required anymore because the passenger has boarded, has changed the flight, the flig ht is cancelled, or the like. In any case, the specific passenger can not be identified by means of the information that is stored on the boarding R FI D chip without access to the corresponding association as stored by the DCS. Therefore, lost or stolen RFI D boarding passes are uncritical and the privacy of personal data is maintained.

Alternatively to checking in via a regular check-in counter with a counter agent, many passengers tend to check in using a self check-in kiosk. To enable kiosk check-in in com- bination with an R FI D boarding pass, an RFI D the self check-in kiosk may comprise or operatively couple to an R FI D boarding pass output unit as explained before.

In a further variant, passengers do self check-in via Internet. As mentioned before, Internet-based check-in is favourably generally handled by the central DCS unit. To enable boarding with an R FI D boarding pass, such boarding pass accordingly has to be handed to the passenger at the departure airport. For this purpose, R FI D boarding pass output units may be present that provide an RFI D boarding pass to a passenger after the identity and status of the passenger being entered into the RFI D boarding pass output unit or being read by the R FI D boarding pass output unit via a barcode reader or the like. While such RFI D boarding pass output units may be dedicated devices similar to the self check- in kiosk, self check-in kiosks with an R FI D boarding pass output unit as mentioned before may also be designed for this additional purpose.

As long as a passenger is only booked for a direct flight without intermediate stops at further airports (through checking ), no paper-based boarding pass is generally required. Favourably, however, a paper-based boarding pass is additionally printed and provided to the passenger as backup and to help the passenger memorizes the relevant flight data, such as boarding time, terminal, and gate. In particular when hand ing out RFI D boarding passes for point-to-point flights, the paper-based boarding pass, which may then merely have the size of a receipt or coupon, may be used by the passengers for financial documentation and proof for a valid reservation of a particular seat in the aeroplane. While not being essential, such paper-based boarding pass may also carry a machine-readable code, such as a barcode, e.g. a barcode according to the IATA standard. Since the paper-based boarding pass is generally not used, it is favourably smaller than present standardized boarding passes and may, e. g. , have one third of the size of the present standardized boarding pass. Thereby, the amount of paper that needs to be printed and subsequently discarded is considerably reduced. Instead of a paper-based boarding pass, "virtual" boarding passes are known and widely used that carry the required data in machine- readable graphical form, e. g. as (one-dimensional) bar code or (two-d imensional) data matrix. Such virtual boarding pass is typically directly transmitted to a personal device, e. g. a smart phone, of a passenger. Boarding passes that store information in a graphical form, are, independent whether they are paper-based or virtual as explained before, also referred to as "g raphical boarding passes" in the following, as opposed to R FI D boarding passes. For a system in accordance with the before-described embodiments where an RFI D boarding pass is used only at a specific airport, additional routines and functions are favourably provided for transfer handling .

If a passenger takes a flight from a first departure airport that is equipped with RFI D technology in accordance with the present disclosure with subsequent transfer at one or more transfer airports to the final destination (through checking ), an RFI D boarding pass as explained before is associated with the passenger and handed to the passenger for use at the first departure airport. Subsequent connection flights are favourably handled by the airport DCS unit in a conventional way. In particular, a paper-based boarding pass is favourably printed for each connection flight which may be used at the corresponding de- parture airport(s) of the connection f light(s) in a conventional way.

The RFI D check-in routine favourably includes an R FI D transfer check-in routine for associating an RFI D chip with a passenger and providing the corresponding RFI D boarding pass to the passenger in the above-described way (either at a kiosk or at a counter with counter agent) upon presentation of a graphical boarding pass. This option is particularly useful if an airline uses RFI D check-in at a transfer airport. The transfer passenger can simply present the conventional graphical boarding pass (which he/she received at the preceding departure airport, printed himself/herself, downloaded to a cell phone, or the like) and receive the R FI D boarding pass. Since an RFI D boarding chip and RFI D boarding pass is used locally at a specific airport only, it is irrelevant whether or not a specific airline relies on the use of R FI D technology at a specific airport that may serve as transfer airport. Furthermore, different airports/airlines may rely on different and potentially fully or partly incompatible R FI D tech- nologies.

It is particularly noted that, while the handling of an R FI D boarding pass is similar to the handling of a graphical boarding pass according to the state of the art and similar procedures are involved from the passenger's point of view, there is a fundamental technical difference: while a regular boarding pass is valid for a specific passenger and a specific flig ht only and carries passenger and flight specific information, the R FI D chip of an R FI D boarding pass does not carry any passenger-specific information. No information is written or programmed into the R FI D chip at the check-in, but only information, namely the passenger identification code, is red from the R FI D chip.

In an embodiment, the at least one airport DCS unit includes or is operatively coupled to a boarding RFI D reader and is further configured to read the passenger identification code that is stored on an R FI D chip which is presented to the boarding RFI D reader. The airport DCS unit of such embodiment is further configured to change a passenger status in response to reading the passenger identification code. Favourably, such airport DCS unit is further configured to cancel the association of the corresponding specific passenger with the passenger identification code. Favourably, such airport DCS unit is further configured to determine whether the specific passenger has validly checked in for a flight he/she wishes to board and changes the passengers status only if valid boarding is confirmed. Particularly, the passenger status may be changed to "boarded". Cancelling the association between a specific passenger and an RFI D boarding pass respectively passenger identification code is favourably carried out directly when it is not longer req uired, that is, when the passenger has boarded, e. g. along with changing the passenger status. Alternatively, the association may persist in the airport DCS unit until it is, e. g. , replaced by a new association for a new passenger. The passenger presents his/her R FI D boarding pass to the boarding R FI D reader in a similar way as a g raphical boarding pass, thus indicating to the DCS that the corresponding passenger has validly boarded. This information is subsequently handled in the same way as according to the state of the art. Cancelling the association between passenger and identification code is an optional step that is favourably carried out for safety and privacy reasons and further in view of re-used of the RFI D boarding pass for a further passenger as discussed in more detail below. Cancelling the association may be carried out immediately when the R FI D boarding pass is presented to the boarding RFI D reader or may be carried out subsequently in a later step.

In an embodiment, the at least one airport DCS unit includes or is operatively coupled to an R FI D collecting unit. The RFI D collecting unit is configured to physically collect RFI D chips respectively R FI D boarding passes carrying passenger identification codes.

Collecting the RFI D boarding passes is favourably carried out immediately prior to a passenger boarding. An RFI D collecting unit may accordingly be integral with or arranged in proximity to a boarding RFI D reader as mentioned before. I n embodiments where the RFI D boarding pass has a design substantially corresponding to a credit card, the R FI D boarding pass collecting unit may have an insertion slot like, e. g. , in a cash machine. Favourably, the boarding R FI D reader is arranged such that the information stored on the RFI D chip, particularly the passenger identification code, is red automatically upon insertion into the insertion slot. Furthermore, an airport DCS unit may be configured to cancel the association of the corresponding specific passenger with the passenger identification code that is stored on the boarding R FI D chip of a collected R FI D boarding pass.

In an embodiment, the at least one airport DCS unit is configured, subsequent to associating the specific passenger with the passenger identification code, to associate a further specific passenger, the further specific passenger being different from the specific passenger, with the same passenger identification code.

This type of embod iment allows the reuse of RFI D boarding passes for a further passenger. This type of embodiment is particularly favourable in connection with partly or fully automated R FI D collecting units as discussed before. In principle, however, collecting and returning the R FI D boarding passes to the pool of RFI D boarding passes can also be done manually, e. g. at smaller airports. At any point in time, however, only a single passenger can favourably be associated with a given passenger identification code.

For this type of embodiment, RFI D boarding passed can be reused may times and up to several thousand cycles. A limit is given only by the wear of the R FI D boarding passes. In an embodiment, the at least one airport DCS unit is configured to associate a passenger with a passenger with a passenger identification code only if no passenger is associated with this passenger identification code. In this way, any double-assignment is prevented.

In an embodiment, the at least one airport DCS unit includes or is operatively coupled to a barrier unit, wherein the at least one airport DCS unit is configured to control the barrier unit to unblock if the passenger identification code that is stored on an R FI D chip present- ed to a barrier R FI D reader is associated with a validly checked-in passenger. The barrier RFI D reader is part of or operatively coupled to the barrier unit.

The barrier unit may, e. g. , be a self boarding unit which is passed by the passengers immediately prior to boarding. A barrier unit according to this type of embodiment accordingly operates in the same way as self boarding units with a barrier according to the state of the art. I nstead of a graphical boarding pass, however, an R FI D boarding pass is presented.

If the barrier unit is a self boarding unit, it favourably comprises or is coupled to the RFI D collecting unit as explained before. For this type of embodiment, the barrier R FI D reader operates, at the same time, as boarding RFI D reader. For this type of embodiment, the barrier RFI D reader is further favourably coupled to or integral with an RFI D collecting unit as described above.

If the barrier unit is part of a boarding pass checking unit as typically present between the public area and the security area of an airport, no RFI D collecting unit is typically present since the RFI D boarding pass is subsequently required for boarding.

It is noted, that, in a specific installation, both of the above-mentioned types of barrier units may and typically will be present. Furthermore, such barrier units may be present at any desired location at the airport.

In an embodiment, the at least one airport DCS unit includes or is operatively coupled to a passenger location unit. The passenger location unit is configured to receive a passenger identification input indicative of a specific passenger to be located. The passenger location unit includes a number of RFI D communication units. Each of the RFI D communica- tion units is associated with a corresponding airport section. The passenger location unit is further configured to determine an airport section in which an R FI D chip with data that are associated with the specific passenger is located, and to provide an indication with respect to this airport section. Especially every larger airport faces the problem that passengers that are validly checked in for a flight do not show up at the gate for boarding in time. At present, such passengers are typically publicly announced which is not successful in a number of cases. In addition to the passenger missing the flight, passengers that do not show up cause significant amount of additional effort at the airport and for the airline, potentially even result - ing in a flight being delayed . E. g. , such passengers have to be removed from the passenger list, their baggage must be removed and typically they have to be booked for later flig ht.

RFI D boarding passes in accordance with the present disclosure may in a favourable way be used for locating a passenger who is missed for boarding. In accordance with this type of embodiment, the passenger identification code that is associated with a passenger who has not boarded at a given (latest) boarding time, is transmitted to the passenger identification unit and/or the passenger identification unit checks the boarding status of all passengers for a specific flight at or shortly after the given (latest) boarding time. The passenger identification number of the passenger to be located is broadcast via the an- tennas of the R FI D communication units. If the boarding RFI D chip with this passenger identification code receives such signal, it responds by broadcasting confirmation signal, e. g. the stored passenger identification code.

Once the passenger is located to be in an airport section of limited size, he or she can be announced in this area and potentially neighbouring areas by an airline or airport agent and asked to proceed to the gate. The size of the single airport sections is favourably sufficiently small to enable a passenger within such airport section to be reliably and easily contacted, with an area of 200 m ² per airport section being a typical but non-limiting value. While not being mandatory, this type of embod iment operates best with active boarding RFI D chips in view of the larger communication range of active RFI D chips. In general, however, the boarding RFI D chip on an R FI D boarding passes may be active or passive or both active and passive R FI D chips may be used.

The airport sections in which a passenger may be located may have some overlap and favourably cover all areas of an airport where the need for locating a passenger may occur. They do not necessarily cover the whole airport but may be limited, e. g. to terminal buildings. If desirable, more than one passenger localisation unit may be foreseen, e. g. one per terminal building in a larger airport.

In an embodiment, all RFI D communication units of a passenger location unit are activat- ed to broadcast the passenger identification code of a passenger to be located simultaneously. Alternatively, the passenger identification unit may be configured to first activate a subset of RFI D communication units and to activate one or more further subsets of RFI D communication units only if the corresponding passenger respectively the corresponding RFI D chip can not be located in the airport sections corresponding to the first subset. The passenger identification unit may accordingly be pre-programmed with a number of different subsets of R FI D communication units respectively airport sections that are associated with different probabilities of the passenger presence, or such probabilities may be determined automatically by the passenger location unit. RFI D communication units or subsets of RFI D communication units are favourably activated in an order of decreasing probability, starting with the highest probability. By way of example, a first subset that is activated first may include a duty free shop, a second subset may include a business launch (if the passenger to be located has a corresponding ticket) , and a third subset may include other and/or more remote areas of the airport, e. g. further terminal buildings and inter-terminal transfer shuttles.

In an embodiment, the at least one airport DCS unit is configured to determine if an overweight surcharge is due for a specific piece of baggage of a specific passenger and to associate this specific passenger with a passenger identification code of a boarding RFI D chip and/or print a boarding pass only after payment of the overweight surcharge. The payment of any overweight surcharge is accordingly not left to the discretion of the agents but necessarily follows the airline policy.

Most airlines generally follow some policy regarding the baggage weight that is free of chare and require an overweight surcharge to be paid if the baggage weight exceeds a pre-defined limit weight. In practice, however, it is known that the policy is not always followed because a number of counter agents tends to accept overweight baggage without requesting or enforcing the payment of an overweight surcharge. For this type of embodiment, the airport DCS unit includes or is operatively coupled to a baggage scale, which may, as it is the case accord ing to the state of the art, be part of a baggage drop unit of a check-in counter. Favourably, the overweight surcharge is automatically computed in accordance with the airline baggage policy respective fees schedule, and is displayed to the counter agent.

It is noted that the coupling of boarding pass printing and overweight surcharge payment may be used in combination with DCSs in accordance with the present invention, but may also be used in combination wit a DCS, check-in counters and baggage drop unit accord- ing to the state of the art. For this purpose, a check-in counter or check-in-terminal or a baggage drop unit is provided that comprises a baggage scale, the baggage scale being operatively coupled with the check-in counter or check-in terminal and/or a DCS. The DCS, the check-in counter or terminal and/or the baggage drop unit is configured to determine if an overweight surcharge is due for a specific piece of baggage of a specific passenger and to print a boarding pass only after payment of the overweight surcharge.

In an embodiment, the flight-related data include baggage identification data. The baggage identification data are indicative for a specific piece of baggage and a specific flight. The R FI D communication unit of such embodiment includes an R FI D programmer, and the at least one airport DCS unit is configured to program the baggage identification data into an R FI D chip. The RFI D chip is associated with the piece of baggage and is in the following referred to as "baggage RFI D chip". The data that may be programmed into baggage R FI D chips are favourably in accordance with the corresponding IATA standards.

For typical travellers' baggage, e. g. suitcases, at least one baggage R FI D chip is favourably directly integrated or permanently attached to the piece of baggage. While not being essential, a number of, e. g. , three baggage RFI D chip is favourably present at different sides of the baggage and the RFI D programmer is configured to program the identical baggage identification data into each of them, thus allowing the data to be subsequently read out for any orientation of the piece baggage with respect to an R FI D reader. For luggage from leather or plastic, the baggage RFI D chip(s) may be arranged on the inside of the piece of baggage or integrated into the shell, e. g. between an outer leather layer and an inner lining layer. For metal baggage, the baggage R FI D chip(s) are favourably arranged at the outside of the piece of baggage because of the electromagnetic shielding properties of typically used metals. According to the present invention, the usage of a single RFI D chip for per piece baggage or luggage may be sufficient. The system according to the present invention may therefore only use a first of a number of R FI D chips integrated into or attached to a certain piece of baggage. Baggage identification data may be written onto the first R FI D chip identified on the baggage. Alternatively or additionally, the usage of R FI D chips may also be restricted to authorised R FI D chips. The authorisation of the R FI D chips may be managed in a respective data base containing R FI D chip identification data, such as chip numbers, etc. In a method and system according to the present invention , then only authorised RFI D chips will be accepted. On the one hand, this enables to prevents the usage of faked or copied RFI D chips. On the other hand, the system may check, whether a certain piece of baggage luggage is not authorised for travel because of being identified as stolen or missed or alike.

For single-use luggage, such as single-use card box shipping boxes, dedicated baggage RFI D tags with a baggage R FI D chips may be provided. Alternatively, printed baggage tags with barcode may be used in this case. The same holds true if the destination airport is not equipped with RFI D-based baggage handling capabilities.

Further baggage handling equipment, such as conveying and transportation systems and/or sorting rooms of an airport may include baggage R FI D readers for reading the information stored in baggage R FI D chips. It is noted that providing the baggage han- dling equipment with corresponding R FI D readers - in addition to and/or as replacement for present bar code readers - is the only modification that is required to such baggage handling equipment that is typically part of the general technical airport infrastructure.

Providing baggage with baggage RFI D chips as discussed before and providing the airport infrastructure with corresponding R FI D readers is also favourably in the context of stolen baggage. If a piece of baggage that is quipped with a baggage RFI D chip as explained before is reported as stolen, the unique RFI D chip number that is typically stored by an RFI D chip may be recorded in a "stolen baggage database". Whenever baggage identification data shall be stored into a baggage RFI D chip as explained before or - more generally - whenever data from a baggage RFI D chip are read by an RFI D reader of the airport infrastructure, the unique R FI D chip number may be checked against such database. If the RFI D chip number is present in such data base, a corresponding information may be provided e. g. to the airport police or other competent authorities. A stolen and /or missed baggage database may be local and stored by the airport DCS unit, may be stored by the central DCS unit, or may by global and exchanged, e. g. with DCSs of further airlines.

Alternatively or additionally, a stolen baggage database is stored at the central DCS which then preferably acts as a master server. Storing such data may be restricted to the central DCS. The data may be synchronised between all master servers or any global database. As an airport DCS relates to a current airport on ly, the airport DCS can assess during check-in then acting as a slave server, whether a certain R FI D chip identification data, such as the chip number, is registered as stolen or missing in the database of the respective master server. This enables to globally manage theft and/or loss information for baggage. In contrast to boarding RFI D chips as discussed before, baggage R FI D chips are favourably recordable RFI D chips into which flig ht-related data for a plurality of up to thousands of flights can be programmed. For data protection and data privacy reasons, however, the data related to a flight are favourably cancelled or marked unreadable as soon as not longer required. For this purpose, the airport DCS unit and/or the RFI D programmer may be configured to delete stored data, in particular baggage identification data originating from a previous flight, when presenting the baggage to the RFI D programmer for programming baggage identification data of a subsequent flight. Alternatively, such data may be marked as unreadable rather than actually deleted . Similarly, R FI D programmers may be provided for this purpose, in an airport section or a passenger that is passed by a passenger after baggage claim, e. g. at the exit of the baggage claim area. This type of embodiment provides a particularly high level of data protection and data privacy if both the departure airport and the arrival airport are correspondingly equipped.

In some embodiment, an airport DCS unit of a split DCS includes or is operationally coupled to a weight checking unit, the weight checking unit including a baggage scale and a baggage R FI D reader and/or baggage barcode reader. Such weight checking unit is favourably located in the baggage flow after the check-in, e. g. in a sorting room where the baggage is sorted and compiled for the individual departing flights, and in any case at a point prior to the baggage being transported to the airport. The weight checking unit is configured to check whether the weight of a piece of baggage is in accordance with the baggage policy of an airline and particularly to check whether a due overweight surcharge has been paid. The weight checking unit is configured to pass a piece of baggage only if such conditions are fulfilled and to sort it out otherwise for new check-in. Such weight-checking unit may be present in addition to a system that allows check-in only if a due overweight-surcharge has been paid as described above for double-checking purposes, or may be present independently.

In an embodiment, the at least one airport DCS unit is designed to operate in a connected mode if operative connection with the central DCS unit is present and is further designed to alternatively operate in an autonomous mode if operative connection with the central DCS unit is not present. The at least one airport DCS unit is designed , in the connected mode, to locally store flight-related data and to synchronize the locally stored flig ht- related data with flight-related data stored by the central DCS unit. The at least one airport DCS units is further designed, in the autonomous mode, to operate as DCS tempo- rarily independent from the central DCS unit.

In the connected mode, synchronisation is favourably carried out on a continuous or quasi-continuous basis. That is, whenever new or updated relevant data are present on the central DCS unit and/or an airport DCS unit, they are transmitted to the other of the central DCS unit and airport DCS unit, respectively, which update their stored data respec- tively database accordingly. It is noted that data relating to a particular flight are favourably not synchronized with all connected airport DCS units at all airports, but only with one or more airport DCS units that is/are installed at the departure airport of this flight.

In some embodiments, an airport DCS unit is adapted, upon a previously temporarily interrupted operative coupling with the central DCS unit being restored, to transmit data that is stored by the airport DCS unit to the central DCS unit.

Via this transmission, the central DCS unit is synchronised with an airport DCS unit (also referred to as "back-synchronization" in the following ) . Such back-synchronisation may be carried out automatically. For this purpose, an airport DCS unit and/or the central DCS unit may be adapted to automatically detect if the operative coupling between an airport DCS unit and the central DCS unit is restored and trigger the back-synchronisation in this case. Alternatively or additionally, the back-synchronisation may be triggered manually.

When boarding is closed and prior to the flight departure, relevant data, in particular passenger-related data, are today often transmitted from an airline DCS to the arrival airport. In an architecture in accordance with the present disclosure such data would typically be transmitted by the central DCS unit. In some embodiments, however, an airport DCS unit is adapted to establish operational communication with an arrival airport and to transmit flig ht relevant data to the arrival airport if operative coupling to central DCS unit is inter- rupted when boarding is closed. This type of embodiment ensures that the arrival airport receives complete and up-to-data data in time even in case of a communication interruption between central DCS unit and airport DCS unit. Transmitting the relevant data from an airport DCS unit to the destination airport allows the flight to take off in time even if the connection to the central DCS unit is interrupted. In some embodiments, an airport DCS unit is particularly configured to handle and process Passenger Name Lists ( PN Ls) and/or Additional Deleting Lists (ADLs) and is designed to temporarily operate as DCS independent from the central DCS unit.

As explained before, a DCS generally belongs to a particular airline and manages flight data and flights of this airline. Especially third-party DCS belong to airlines. Airport DCS and central DCS belong to certain airport and/or flight management service providers. The present invention enables to connect any of these DCS via the self-organising remote procedure call protocol. Thus, all DCS may be integrated into a split DCS system. The embodiments and application scenarios as described so far are based on the general assumption that all flight seg ments, includ ing potential stopovers, are generally managed by a split DCS in accordance with the present disclosure, particularly by a split DCS. This, however, is not necessarily the case. In some typical application scenarios, only some fight segments, e. g. the first flight segment of a multi-segment flight, is executed by an airline using a split DCS, while some or all other flight segments are executed by airlines using a different DCS, e. g. a DCS in accordance with the state of the art. Furthermore, an airline using a DCS in accordance with the state of the art that is not designed for RFI D data exchange, may anyway whish to rely on RFI D boarding passes and/or RFI D baggage tags as explained before if such technology is used by a partner airline.

In some embodiments, the central DCS unit of a split DCS in accordance with the present disclosure is configured to operatively couple to a further external DSC and/or an external reservation system and to exchange data with and particularly receive data from the external DCS and/or external reservation system. I n the following, reference is mainly made in this context to an external DCS. An analogue approach, however, may also be used for another external reservation system which is not a DCS. An external DCS is, e. g. , a DCS belong ing to a partner airline and may in principle be a split DCS in accordance with the present disclosure, but is more typically a DCS according to the state of the art as widely used by airlines. The central DCS unit is configured to operatively couple with the external DCS via the central CDS unit communication interface or via a separate communication interface, using, e. g. , an internet-based communication channel. An airport DCS unit may accordingly exchange data with an external DCS via the central DCS unit. However, no direct communication channel is provided between an airport DCS unit and an external DCS in typical embodiments.

Operatively coupling a DCS in accordance with the present disclosure with an external DCS is particularly favourably since it allows making use of the advantages and features that are related with an RFI D chip storing flight-related data as explained above as well as further below also in combination with a DCS according to the state of the art. No modification is required on such external DCS. According to this type of embodiment, flight- related data are transmitted from the external DCS to the central DCS unit and are further transmitted from the central DCS unit to a corresponding airport DCS unit of the depar- ture airport. The data protocols and communication standards are not necessarily identical for the communication between the external DCS and the central DCS unit on the one hand and between the central DCS unit and the airport DCS units un the other hand. Data exchange or communication between the central DCS unit and the airport DCS units, i. e., communication between the units of a split DCS in accordance with the present disclosure, may especially be based on a proprietary protocol, while data exchange or communication between an external DCS and the central DCS unit may be based on an available and generally accepted standard, in particular SUA (Societe Internationale de Telecommunications Aeronautiques) standard. Data that may be communicated from an external DCS to the central DCS unit and further from the central DCS unit to an airport DCS unit may particularly include PN Ls ( Passenger Name Lists) and/or ADLs (Add/Delete Lists) . A PN L is typically transmitted some time before the regular check-in is opened . ADLs with last minute changes may also be transmitted later on.

For through checking, a split DCS in operative coupling with an external DCS is favourably designed and configured to print out boarding passes for the various flight segments based on the PN Ls and ADLs as provided by an external DCS managing a flight. I n this way, the external DCS and its data base or data bases remain the central instances where all data are consolidated and data consistency is ensured, even if airport check-in is carried out via the split DCS. A further advantage of this type of embodiment is that a common terminal hardware and a common user interface may be used on the airport side independent of whether a flight is generally managed by the DCS in accordance with the present disclosure or by a coupled external DCS. For this type of embodiment, online as well as mobile check-are carried out by passengers by directly accessing the external DCS which transmits the corresponding data to the central unit, typically as PN L/ADL as explained above. Favourably, check-in via the external DCS is disabled upon or somewhat before start of the airport check-in. In general, check-in can only be started for an external flight handled by an external DCS is the flight status for such a third-party DCS is set to "flight open" ( FO). While not being essential, this safety measure ensures any potential database inconsistency in case of a temporary communication interruption or communication breakdown between the external DCS and the central DCS unit respectively between the central DCS unit and a local DCS unit during airport-check-in.

Check-in at a regular check-in counter with a counter agent or self check-in at a check-in kiosk are carried out via the split DCS, particularly its airport DCS unit, in exactly the same way independent of whether a flight is generally managed by the split DCS in accordance with the present invention or a coupled external DCS. The same holds true for baggage drop and boarding.

As explained before, an airport DCS unit in accordance with the present disclosure is adapted, upon a previously temporarily interrupted operative coupling with the central DCS unit being restored, to transmit data that is stored by the airport DCS unit to the central DCS unit. This functionality may be available in the same way for embodiments where an external DCS is operatively coupled to the central DCS unit. That is, if a flight is generally managed via an external DCS and a communication interruption occurs during check- in/baggage drop at the airport, relevant data are temporarily stored by the airport DCS unit and transmitted, via the central DCS unit, to the external DCS upon coupling being restored. In case of temporary communication interruption between the central DCS unit an external DCS, relevant data are temporarily stored by the central DCS unit and are transmitted to the external DCS upon communication being restored. During regular operation, if all communication channels are operable, flight-related data, in particular passenger and baggage data may transmitted form the central DCS unit to the external DCS in real time upon such data being generated or modified, or may be transmitted only after boarding has closed or subsequent to the flight departure.

A DCS architecture in accordance with the present invention with a split between central DCS unit(s) and airport DCS unit(s) is further favourable in the context of specific regulatory and/or general legal requirements of individual countries/jurisdictions. Such requirements may be posed by Aviation or other authorities. E. g. , a number of countries require airlines to store flight-related data regarding their citizens inside the corresponding coun tries. Under such circumstances, different central DCS units may be provided in different countries/jurisdiction by the same airline, each central DCS unit storing flight-related data in accordance with the local requirements. The different central DCS units may be opera- tively coupled to exchange flight-related data between them as required . Furthermore, airport DCS units that are installed at a specific airport may be designed to couple to a number of central DCS units that are installed and operated in different countries.

In accordance with the present disclosure, a counter (typically a check-in counter or a self-check-in kiosk) may optionally include an image capturing device. The counter is part of or operatively connected to, e. g. , an airport DCS unit of a split DCS. The image capturing device may include a still or video camera for capturing a portrait image of an air passenger and/or a scanning device for scanning a passport photog raph form a passport, identity card, or the like of an air passenger. An airport DCS unit of such embodiment is further configured to temporarily store captured images of a passenger. For this type of embodiment, an image of an air passenger is captured in the process of check-in or self check-in, particularly in the context of providing a RFI D and/or graphical boarding pass. Further for this type of embodiment, a barrier unit may be designed to display, after iden- tifying a passenger by reading a passenger identification code from a boarding R FI D chip via an RFI D reader or reading information provided on a graphical boarding pass via a scanner, the corresponding previously captured passport photograph of this passenger on a display device, e. g. on a computer monitor. The barrier unit may further be designed to open, thereby allowing the passenger to pass, only after receiving an identity confirmation input, the identity confirmation input confirming identity of the person presenting the boarding pass with the passport photograph. Such identity confirmation input may be provided manually, e. g. by a counter agent, airport security officer, or the like. Alternatively or additionally, the barrier unit may include or be coupled to a further image capturing device at the barrier unit that is configured to capture an image of a passenger and compare it with a previously captured image via computer-implemented image processing/image comparison. Alternatively or add itionally, an image of an I D or passport of a certain passenger captured at check-in time may merely be compared to the appearance of the passenger at the boarding gate or via a gate monitor by airport staff personnel. After boarding, all captured images are favourably automatically deleted from the airport DCS unit. Alternatively, however, they may be further stored or transferred to a further database, such as a "Flown" database, if desired by the airline and compliant with applicable data privacy regulations.

The before-described type of embod iment has the particular advantage that it allows to ensure that a person actually boarding a plane as passenger is identical to person that checked in. It can accordingly prevented that a boarding pass is illegally handed over to a different person or is, e. g. , mistakenly confused. According to the state of the art, such check can only be achieved via time-consuming manual comparison and verification between the data of a identification document, such as a passport, and the printed data on the boarding pass.

In some embodiments, the DCS comprises a passenger identification unit. The passenger identification unit according to this type of embodiment may be implemented on the central DCS unit or an airport DCS unit of a split DCS in accordance with the present invention. In principle, it may also be implemented on any other DCS that is generally desig ned according to the state of the art. The passenger identification unit allows to check passenger identification data against a search database and provides an ind ication if the passenger identification data for a specific passenger match data that are present in the search database, making it likely that the passenger is a person with an entry in the search database. The passenger identification data are data sets with data that generally need to be provided by an air passenger, such as name, sex, date/place of birth, citizenship. The search database may, e. g. , be a database of wanted persons, a database of persons with restricted freedom to travel, such as tax debtors, or a "no flig ht" database of persons that shall not be allowed to enter a plane according to an airline policy, e. g. because of previous incidents with that passenger. The passenger identification data may be provided, e. g. , in form of a PN L and/or ADL as discussed above, from a G DS (Global Distribution System) or an APIS (Advance Passenger Information System ) as known in the art and widely used. The passenger identification unit is configured to transmit received or inputted passenger identification data or data sets to the search data base and receives a hit notification from the search database in case of a hit. For this case, the passenger identification unit is further configured to send a hit notification to an external IT system, such as a police or customs IT system to which it is operatively connected . For example, if a specific person that is present in a database of wanted persons appears on the PN L of a flig ht, a corresponding hit notification may be sent to the airport police of the arrival airport which may, in turn, decide on any actions to be taken. If the person is on a "no flig ht" database, check-in or boarding may be permitted.

In preferred embodiments, a passenger identification unit does not only provide the exact passenger identification data to the search database, but is configured to determine modified data that show some deviation to the provided passenger identification data but anyway have a reasonable likelihood of corresponding to a specific person. Particularly, IATA standards are comparatively tolerant with respect to name misspellings and accept a number of characters to deviate between, e. g., the name as provided by a passenger e. g. during self check-in or as entered by a counter agent, and the name as indicated by an I D or passport. The passenger identification unit may according ly be configured to determine, based on the provided or inputted passenger identification data, alternative data sets with alternative data that take into account deviations such as misspellings, and transmit such alternative data to the search database in addition to the original passenger identification data.

It is noted that for a passenger identification unit as explained before, the DCS and particularly the DCS do typically neither host nor have full access to the search database which is hosted, operated and maintained under control of the corresponding authority. In some cases, however, the search database may be an airplane data base and be hosted by the DCS. This may be the case, e. g. , for a "no flight" database.

It is further noted that an optional passenger identification unit as explained before is particularly useful in an avian context, but may also be valuable in a different context and applied in an analogue way. It may, for example, be used to provide an information if a person that is present in a search data base tries to enter means of transportation, e.g. a cross boarder train, a cross boarder bus.

According to a further aspect, the overall object is achieved by providing a passenger location unit. The passenger location unit is, in an operational state, arranged at or in an airport. The passenger location unit includes a number of R FI D communication units and each of the RFI D communication units is associated with a corresponding airport section. The passenger location unit is further configured to receive a passenger identification input indicative of a specific passenger to be located. The passenger location unit is further to determine an airport section in which an RFI D chip with data that are associated with the specific passenger to be located is located, and to provide an indication with respect to this airport section.

The passenger location unit may designed and operate according to any embodiment as discussed above and further below in context of an airport DCS unit.

BR I EF DESCR I PTION OF FIGU RES Figure 1 shows an exemplary departure control system along with periphery components in a schematic functional view;

Figure 2 shows an exemplary check-in counter in a schematic functional view;

Figure 3 shows an exemplary setup with a passenger location unit in a schematic functional view; Figure 4 shows a schematic perspective view of a first embodiment of an All-in-One (AiO) Common Use Self Service (CUSS) module according to the present invention;

Figure 5 shows a schematic perspective view of a second embodiment of an AiO CUSS module according to the present invention ;

Figure 6 shows a schematic perspective view of a third embodiment of an AiO CUSS module according to the present invention ;

Figure 7 shows a schematic perspective view of a fourth embodiment of AiO CUSS modules according to the present invention arranged in a row;

Figure 8 shows a schematic perspective view of an embodiment of RFI D boarding gate according to the present invention;

Figure 9 shows a schematic perspective view of an embod iment of RFI D baggage gate according to the present invention;

Figure 1 0 shows a schematic illustration of a data packet according to the present invention;

Figure 1 1 shows a schematic illustration of method steps in a check-in procedure according to the present invention. EXEPM PLARY EM BODI M ENTS

In the following , reference is first made to figure 1 . Figure 1 shows a departure control system in accordance with the present disclosure together with periphery components in a schematic functional view. Functional operational couplings between individual units and components are, like in subsequent figures, indicated by dotted lines. Those couplings are unidirectional and/or bidirectional information exchange couplings that are based on wired and/or wireless technologies and hardware and/or software protocols as generally known in the art.

The DCS includes a central DCS unit 1 and an airport DCS unit 2. The central DCS unit 1 is typically located at a data centre of an airline. The airport DCS unit 2 is typically installed remote from the central DCS unit 1 at an airport.

The arrangement as shown in figure 1 further includes a check-in counter 3 , a boarding pass checking unit 4 and a self boarding unit 5, each of them comprising a barrier unit as explained further below in more detail. The check-in counter 3 and the barrier units 4, 5 are typically installed at the same airport as the airport DCS unit 2. It is noted that the check-in counter 3 and the barrier units 4, 5 are shown for exemplary purposes. In a typical setup, a larger number of check-in counters 3 and/or boarding pass checking units 4 and/or self boarding units 5, is typically present.

The central DCS unit 1 includes a central DCS unit communication interface 1 0 and the airport DCS unit 2 includes an airport DCS unit communication interface 20. Via the communication interfaces 1 0, 20, the central DCS unit 1 and the airport DCS unit 2 are operatively coupled for information exchange, particularly flight-related data exchange. The coupling is typically an Internet-based coupling, but may also be any other suited data coupling as generally known in the art.

The central DCS unit 1 further includes a number of n of functional central DCS modules 1 1 - 1 , 1 1 -2, .. 1 1 -n that are designed to execute a number of central DCS routines. Simi- larly, the airport DCS unit 2 includes a number of m functional airport DCS modules that are designed to execute a number of airport DCS routines 21 - 1 , 2 1 -2, 21 -3 , 21 -4, ... 21 -m. In the example of figure 1 , there is a one-to-one matching between functional central DCS modules and central DCS routines respectively functional airport DCS modules and airport DCS routines. As explained before in the general description, however, this is not necessarily the case.

The central DCS unit 1 and/or the airport DCS unit 2 may and typically do include further modules, such as mass storage modules with databases and a central coordination module that schedules and coordinates operation of the single functional modules. Typically, the single functional modules are operatively functionally coupled with the central coor- dination module and exchange data with the central coord ination module of the central DCS unit 1 respectively the airport DCS unit 2. In addition to the functional operational couplings that are shown in figure 1 , further functional operational couplings may be present, e. g. between some or all of the functional central DCS modules 1 1 - 1 , 1 1 -2, ... 1 1 -n respectively between some or all of the functional airport DCS modules 21 - 1 , 21 - 2, ... 21 -m.

The set of central DCS routines that may be carried out by the central DCS unit 1 is at least partly disjunct from the set of airport DCS routines that may be carried out by the airport DCS unit 2. Some routines may accordingly only be carried out by the central DCS unit 1 , while some other routines may only be carried out by the airport DCS unit 2. In the exemplary embodiment of figure 1 , the functional central DCS module 1 1 - 1 is a fleet management module that is designed to carried out fleet management routines such as adding new aircraft to the fleet, removing aircraft from the fleet, and marking aircrafts for maintenance/service. Further exemplarily, one of the functional central DCS modules is a through check-in module that is designed to execute a through check-in routine for through check-in of passengers and/or baggage as generally known in the art.

Further exemplarily, the functional central DCS module 1 1 -n is a post departure messenger unit that is designed to execute a post departure message routine, the post departure message routine including sending post departure message as generally known in the art.

Further of such routines that are typically only implemented on the central DCS unit 1 are check-in routines that are typically carried out remote from the departure airport, in particular mobile check-in and ( Internet - based ) online check-in routines. Such external check-in options, i. e. check-in options that do not involve a counter at the departure air- port, are favourably automatically disabled upon or some time before the regular check- in starts in order to avoid data inconsistencies in case of a communication breakdown.

It is noted, however, that a subset of the before-mentioned routines may also be implemented on the airport DCS unit 2 and the airport DCS unit 2 may be designed to carry out such routines. In the exemplary embodiment of figure 1 , the functional airport DCS module 21 -2 is a counter check-in module that is designed to execute a counter check-in routine for passengers and/or baggage. Counter check-in may be carried out using an RFI D boarding pass. The counter check-in routine as executed by counter check-in module 21 -2 accordingly is or includes an R FI D communication routine.

In the exemplary embodiment of figure 1 , the check-in counter 3 is largely designed in the same way as the check-in counter for passenger and baggage check-in as known in the art and is operated by a counter agent. The check-in counter 3 includes a generally known terminal device 30, and R FI D reader 3 1 and a baggage scale 32. The R FI D reader 3 1 and the baggage scale 32 are operatively functionally coupled with the terminal device 30. The terminal device 30 is operatively functionally coupled with the counter check-in module 2 1 -2 a via communication link as generally known in the art, e. g. via local area network ( LAN ). Via the terminal device 30, the RFI D reader 3 1 and the baggage scale 32 are also operationally functional coupled with the counter check-in module 21 -2. Alternatively, such couplings may be direct and separate from the coupling of the terminal device 30. It is further noted that the split between the check-in counter 3 and the airport DCS unit 2 as shown in figure 1 is mainly made for clarity reasons. Via the be- fore-described operational functional couplings, the terminal device 30 can also be considered as functional part of the airport DCS unit 2. Furthermore, the check-in counters the and the airport DCS unit 2 may be formed fully or partly integral with each other.

The check-in counter 3 of the exemplary embodiment operates in substantially the same way as it is known from check-in counters and check-in procedures according to the state of the art. The known step of printing a boarding pass, however, is modified as follows: Rather than simply printing a standard boarding pass, the counter agent picks an RFI D boarding pass with a boarding R FI D chip from a pool of R FI D boarding passes. As explained before in the general description, the boarding R FI D chips stores (e. g. numeric or alphanumeric) passenger identification codes. The passenger identification codes are pre-stored on the boarding RFI D chips and the counter agent may pick any R FI D boarding pass. The passenger identification code that is stored on the boarding RFI D chip of the picked RFI D boarding pass is subsequently red by the R FI D reader 3 1 and transmitted to the counter check-in module 21 -2. Via an R FI D check-in routine that is executed by or under control of the counter check-in module 21 -2, the passenger identification code is associated with a specific passenger and a specific flight. Along with this association, the status of this passenger is changed to "checked in" in a corresponding database of the airport DCS unit 2. If - as it is normally the case - operational coupling to the central DCS unit 1 is available, the status change is further automatically transmitted to the central DCS unit 1 where a corresponding database is updated . While not shown in figure 1 for clarity reasons, the check-in counter 3 typically further comprises a paper boarding pass printer. Via this boarding pass printer, a paper-based boarding pass may be printed out additionally and serve for passenger information purposes.

Optionally, the check-in counter 3 may comprise an image capturing device ( not shown ) for capturing a portrait photograph or scanning a passport photograph as explained before in the general description of the invention.

Optionally, the counter check-in module 21 - 2 and the R FI D check-in routine are designed to check, via the baggage scale 32 , whether an overweight surcharge is due and enable, in the affirmative case, the association with the passenger with a passenger iden- tification code and/or printing of an RFI D boarding card only after valid payment of this overweight surcharge.

Optionally, the check-in counter 3 and the airport DCS unit 2 are further designed for through-checking. For subsequent connection flig hts, the paper-based boarding pass is printed by the optional boarding pass printer without associating the passenger with a passenger identification code of an boarding R FI D chip for such connection flights. As explained before in the general description, the paper-based boarding pass or passes for the connection flight or connection flights may be used directly for regular check-in at the transfer airport or transfer airports, following procedures as known in the art.

In a typical installation, the airport DCS unit 2 and the check-in counter 3 are installed at an airport that may serve as transfer airport. The airport DCS unit 2 and the check-in counter 3 may therefore be designed for entering information from a graphical boarding pass, e. g. via manual terminal input or barcode reader and to associate a passenger identification code of an check-in R FI D chip with this specific passenger. Additionally or alternatively, dedicated through checking counters ( not shown in figure 1 ) may be provided for this purpose.

The exemplary setup of figure 1 further includes a boarding pass checking unit 4. The boarding pass checking unit 4 includes a barrier unit 40 and a barrier R FI D reader 41 . The barrier unit 40 and the barrier RFI D reader 41 are operatively coupled to the airport DCS unit 2, particular to a boarding pass checking mod ule 21 -3 of the airport DCS unit 2. The boarding pass checking module 2 1 -3 is designed to execute a boarding pass checking routine, the boarding pass checking routine being an RFI D communication routine. As explained before in context of the check-in counter 3 , the split between the airport DCS unit 2 and the boarding pass checking unit 3 is made for clarity purpose and does not imply a specific configuration. Like the check-in counter 3 , the boarding pass checking unit may be considered as functional part of the airport DCS unit 3. In a typical airport installation, the boarding pass checking unit 4 is installed at the transition between the public and the security areas of an airport. The boarding pass checking unit 4 and/or a self boarding unit 5 as discussed further below in more detail may optionally be designed to display a previously captured photograph of an air passenger as explained before.

Upon an RFI D boarding pass with a valid association between a specific passenger and a specific flight that is accessible via the boarding pass checking unit 4 being presented to the RFI D reader 41 , the boarding pass checking module 21 -3 controls the barrier unit 40 to open in a generally known way, thus allowing the corresponding passenger to pass. Along with allowing the passenger to pass, a passenger status is accordingly updated in a database of the airport DCS unit 2. U pon presenting an RFI D boarding pass without valid association between a specific passenger and a flight, the boarding pass checking module 21 -3 does not control the barrier unit 40 to open. This is the case, e. g. if no passenger is associated with the boarding R FI D chip that is presented to the RFI D reader 41 , if an association between passenger and the passenger identification code is stored on the boarding R FI D chip is given but indicates the corresponding flight leaving from a different terminal, or the like.

While not shown in figure 1 , a conventional barcode reader for graphical barcodes is optionally present in addition to allow the passing of passengers without R FI D boarding pass. For this type of embodiment, the boarding pass checking unit 4 may be a boarding pass checking unit as known in the art that is additionally equipped with the R FI D reader 41 .

Rather than a coupling between the barrier unit 40 and the RFI D reader 41 via the boarding pass checking module 21 -3 , the barrier unit 40 may be designed for manual operation, e. g. via security staff. The exemplary setup of figure 1 further includes as self boarding unit 5. The self boarding unit 5 includes a barrier unit 50 and a combined RFI D reader/RFI D collecting unit 51 in operative coupling with a passenger boarding module 21 -4 of the airport DCS unit 2. The boarding module 21 -4 is designed to execute a passenger boarding routine, the passen- ger boarding routine being an R FI D communication routine.

Upon an R FI D boarding pass with a valid association between a specific passenger that is authorized to board a specific flight that is accessible via the barrier unit 50 and the passenger identification code that is stored on the boarding R FI D chip being presented to the RFI D reader 51 , the boarding module 2 1 -4 controls the barrier unit 50 to open in a gen- erally known way, thus allowing the corresponding passenger to pass and board a plane. Like for present self boarding systems, the self boarding unit 5 is typically installed directly at a gate and the barrier unit 50 enables only access to one specific plane and a specific flig ht. That is, the self boarding unit 5 is, at any given point in time, associated with a specific flight. Since the RFI D boarding pass shall be retained at the airport (and not taken to the plane) for subseq uent re-use and is further no longer required after boarding, it is automatically collected for return to the pool of RFI D boarding passes. Along with reading the passenger identification code and collecting the RFI D boarding pass, a passenger status is accordingly updated in a database of the airport DCS unit 2 to "boarded". Furthermore, the passenger boarding module 21 -4 controls the airport DCS unit 2 to cancel the association between the boarded passenger and the passenger identification code that is stored in the boarding R FI D chip.

While not shown in figure 1 , a conventional barcode reader for graphical barcodes is optionally present as part of the self boarding unit 5 to allow the boarding of passengers without RFI D boarding pass. For this type of embodiment, the self boarding unit 5 may be a self boarding unit as known in the art that is additionally equipped with the R FI D reader/R FI D collecting unit 51 .

In a variant, only an R FI D reader without R FI D collecting unit is present and the R FI D boarding passes may be collected manually, e. g. by a gate agent. In a further embodiment, the boarding unit 5 is not a self boarding unit and the barrier unit 51 is designed for manual operation by a gate agent upon an indication that a passenger is cleared for boarding .

Further in the example of Figure 1 , an optional external DCS 6 is shown that is operatively coupled to the central DCS unit communication interface 1 0. The split DCS with central DCS unit 1 and airport DCS unit 2 on the one hand and the external DCS 6 on the other hand interact and exchange data as discussed above in the context of the general description. Instead of or alternatively to the external DCS 6, another external reservation system may be present in an analogue way. In the example of Figure 1 , an exemplary number of two further optional airport DCS units 2', 2" are shown that are designed and operate in the same way as the before- discussed airport DCS unit 2. The further airport DCS units 2', 2" are typically installed at further airports.

In the following, reference is add itionally made to figure 2. Figure 2 shows a further ex- emplary check-in counter 3 that may be operatively coupled to or be part of an embodiment of an airport DCS unit 2. The check-in counter 3 of figure 2 includes an add itional RFI D prog rammer 33. A check-in routine of the airport DCS unit 2, such as an RFI D check-in routine as explained before, and/or a baggage handling routine, may control the R FI D programmer 33 to program baggage identification data, in particular baggage identification data according to the IATA standards, into a baggage R FI D chip or a number of baggage R FI D chips as generally explained before. Further R FI D readers may be present as part of the airport baggage handling system, e. g. at bagged conveyer belts, in a sorting room or the like in substantially the same way as it is presently the case for graphical barcode-based baggage tag readers. Such R FI D readers are a functional part of or operatively coupled to the airport DCS unit for supervising and controlling the baggage flow.

While, in the embodiment of figure 2, a boarding R FI D chip reader 3 1 is present as ex- plained before, this is not essential. Baggage hand ling based on RFI D chips may also be provided independent from and without relying on RFI D boarding passes.

In the following, reference is additionally made to figure 3. Figure 3 shows an embodiment of an airport DCS unit 2 that includes and/or is operatively coupled with a passenger location unit. In the exemplary setup, the passenger location unit includes a coordination module 21 -5 that is general part of the airport DCS unit 2. I n the shown exemplary architecture, the coordination module 21 -5 is operatively coupled to a number of RFI D communication units 60- 1 , 60- 2, ... 60-r, and 61 - 1 , 61 - 2, ... 61 -s via a communication link as generally know, e. g. via a LAN or WLAN network The R FI D communication units 60- 1 , 60- 2,... 60-r form a first set 60 of r R FI D communication units and are exemplary installed at a first airport terminal. Similarly, the RFI D communication units 61 - 1 , 61 - 2,... 61 -s form a second set 61 s of R FI D communication units and are exemplary installed at a second airport terminal. At or favourably shortly before the end of the general boarding time for a specific flight, the airport DCS unit 2 checks the status of all passengers that are booked for this flight. For passengers that are not (yet) marked as "boarded", a passenger location routine is initiated via the coordination module 21 - 5. As part of the passenger location routine, the coord ination module 21 - 5 transmits passenger identification data for the missing (that is, not (yet) boarded ) passenger(s) to the set 60 respectively 6 1 of RFI D communication units, in dependence of the departure terminal of the flight.

The passenger identification data include or comprise of the passenger identification code(s) that are stored on the RFI D boarding chip(s) of these missing passenger(s). The set 60 respectively 61 of RFI D communication units is activated and broadcasts the passenger identification code(s) of the missing passenger(s) as explained in more detail above in the general description. If an RFI D boarding chip responds, an acknowledgement signal is transmitted from the corresponding RFI D communication unit to the coordination unit 21 -5. Each of the R FI D communication units 60- 1 , 60- 2, ... 60-r, and 61 - 1 , 61 -2, ... 61 -s has a unique identifier that is transmitted along with or as part of the acknowledgment signal. Based on this unique identifier, the coordination unit 21 -5 identi- fies the airport section respectively the terminal section in which the missing passenger is located. Furthermore, a corresponding signal is transmitted from the coordination unit 21 -5 to a terminal unit (not shown ) where a corresponding airport section is displayed. There may be a central terminal unit and/or a number of terminal units and the indication may especially be given on a terminal unit that is closest to the airport section respectively the terminal section where the missing passenger is located. Alternatively or additionally, a corresponding signal may be provided to a device that is carried by an airport or airline employee, such as to a cell phone or pager device.

It is noted that, in the example of figure 3 , while the RFI D communication units RFI D communication units 60- 1 , 60- 2, ... 60-r, and 61 - 1 , 61 -2, ... 61 -s are shown separately from the airport DCS unit 2, they form functional part of the airport DCS unit 2 in the shown architecture is merely exemplary.

Figure 4 shows a first exemplary embodiment of an All-in-One (AiO) common use self- service (CUSS) module 1 00- 1 according to the present invention to be used as or as re- placement for a check-in counter 3 in a schematic perspective view. The Aio CUSS module 1 00- 1 is config ured as an Aio CUSS station for the self check-enough passenger, baggage and hand luggage. The embod iment of the AiO CUSS module 1 00- 1 shown in figure 4 is designed as a stand-alone device. As such, the AiO CUSS module 1 00- 1 may be placed for example at airports, hotels, railroad stations or other infrastructures associ- ated to traveller traffic.

The AiO CUSS mod ule 1 00- 1 comprises a combined control device 1 01 mounted on a chassis 1 02 formed as a stand. The control device 1 01 is designed as a touchscreen where a user, in particular a passenger P (see figure 5 ) , can read and input data as well as control the AiO CUSS module 1 00- 1 . An input device 1 03 and an output device 1 04 are built into the chassis 1 02. Near a base or foot of the chassis 1 02, a scale device 1 05 for weighing a piece of luggage L is provided.

Via the control device 1 01 , a person, in particular a passenger may carry out a check-in procedure in line with a method according to the present invention. Before, during or after that procedure, data is entered through the control device 1 01 - 1 , the input device 1 03 , and the scale device 1 05. Therefore, especially the input device 1 03 may be equipped with R FI D readers 3 1 , Bluetooth devices, Wi-Fi devices, scanners or alike in order to acquire data from any kind of data carrier from RFI D chips, boarding passes, mobile phones, passports, I D-cards or alike. The output device 1 04 may comprise RFI D programmers 33 , receipt and/or boarding pass issuing devices or printers for writing on- to RFI D chips, paper or alike data in line with a method and system according to the present invention.

Figure 5 shows a second exemplary embodiment of an AiO CUSS module 1 00-2 according to the present invention . The AiO CUSS module 1 00-2 is built-in into the check-in counter 3. For example, the check-in counter 3 may be either initially provided with the AiO CUSS module 1 00- 2 or the AiO CUSS module 1 00- 2 may be retrofitted to the check- in counter 3. In other words, any check-in counter 3 may be equipped with the AiO CUSS module 1 00-2 according to the present invention at any desired point of time.

The AiO CUSS module 1 00-2 has the chassis 1 02 designed as a box placed on top of the check-in counter 3 and holding the control device 1 01 such that it is directed to passengers P. The passengers P may be served by airport staff personnel S in an assisted check- in mode or may perform a self check-in at the AiO CUSS module 1 00-2. Instead of being equipped with a separate scale, the AiO CUSS module 1 00-2 is operationally coupled to the baggage scale integrated into the baggage conveyer belt of the check-in counter 3. Therefore, this integrated scale is used as the scale device 1 05 of the AiO CUSS module 1 00-2.

Figure 6 shows another exemplary embodiment of an AiO CUSS module 1 00-3 according to the present invention. The AiO CUSS module 1 00-3 is designed as a dual check-in counter. Here, the control device 1 01 is mounted onto the chassis 1 02 such that the con- trol device 1 01 is turnable between a staff operated position A and a passenger operated position B. I n the staff operated position A, the airport staff personnel S operates the AiO CUSS module 1 00-3. In the passenger operated position B, the passenger P operates the AiO CUSS module 1 00-3. The chassis 1 02 of the AiO CUSS module 1 00-3 is designed as a desk counter similar to the check-in counter 3. The input device 1 03 and the output device 1 04 are built in into the chassis 1 02. At least the input devices 1 03 are located such that they may be reached both by the passenger P and by the airport staff personnel S. The output device 1 04 can be located at the chassis 1 02 such that it faces to an area for the passengers P. Again, the scale device 1 05 is built into the baggage conveyer belt.

Figure 7 shows another exemplary embodiment of an AiO CUSS module 1 00-4 according to the present invention. Here, several AiO CUSS modules 1 00-4 are arranged in a row as self check-in stations. As such, the chassis 1 02 of the AiO CUSS module 1 00-4 can be designed such that it is built into a structure of the airport. For example, said structure may be a wall in a terminal building. The AiO CUSS module 1 00-4 is built into the wall, such that its front face is aligned with the wall in an ergonomic and practical manner.

The control device 1 01 of the AiO CUSS module 1 00-4 is aligned with the front face of the chassis 1 02 of the AiO CUSS module 1 00-4. Below the control device 1 01 , the scale device 1 05 is arranged such that it is located within an opening of the chassis 1 02 reaching through the wall. At the back of the opening , a door 1 06 of the AiO CUSS module 1 00-4 is arranged. The door 1 06 is closed as long as baggage check-in is not performed, possible or allowed. The door 1 06 is only opened after a successful baggage check-in, so that respective baggage L can enter a space behind the door 1 06, where a baggage con- veyor belt may be provided for transporting the baggage away to a baggage handling area of the airport. On a side of the chassis 1 02 of the AiO CUSS mod ule 1 00-4 next to the control device 1 01 and the scale device 1 05, the input device 1 03 and output device 1 04 are arranged such that they are aligned to the front face of the chassis 1 02. A further control device 1 07 is provided and located above the input device 1 03 and the output device 1 04. The further control device 1 07 may be designed as a touchscreen in a similar way as the control device 1 01 . Below the further control device 1 07, a transaction device 1 08 is built into the front face of the chassis 1 02. The transaction device 1 08 may serve for financial transactions, such as credit card and/or debit card operations and/or cash handling so that payment procedures can be carried out at the AiO CUSS module 1 00-4. Such payment procedures may be used for example for booking additional flight options, such as baggage transport, oversized baggage transport, overweight baggage transport and surcharges, general flight booking payments, etc.

Furthermore, the AiO CUSS module 1 00-4 is provided with a hand luggage device 1 09. The hand luggage device 1 9 can be built into the chassis 1 02 in a similar manner as the scale device 1 05. The hand luggage device 1 09 is configured to check the dimensions of the hand luggage and/or to weigh the hand luggage. Thereby, it may be automatically checked at the AiO CUSS module 1 00-4, whether the hand luggage meets predefined hand luggage specifications of a certain flight or airline. If the hand luggage specifications are not met, the hand luggage may be checked in as conventional baggage like the luggage L.

Figure 8 shows a schematic perspective view of an embodiment of RFI D boarding gate 200 according to the present invention. The R FI D boarding gate 200 can be placed at the entrance of a board ing gate which has to be passed by passengers for boarding onto an aeroplane and therefore replaces a respective (staffed ) boarding pass checking unit 4. The RFI D boarding gate 200 blocks the entrance and is equipped with a barrier unit 8 according to the present invention. The barrier unit 8 comprises an R FI D reader 3 1 and/or an R FI D collecting unit 41 so that it may read and/or collect RFI D boarding passes issued to passengers. The barrier unit 8 controls a barrier 201 of the R FI D boarding gate. The barrier 201 only opens to lead passengers P passed the entrance when the information on their respective R FI D boarding pass is associated and acknowledged for boarding on a certain flight. Figure 9 shows a schematic perspective view of an embodiment of R FI D baggage gate 300 according to the present invention . The RFI D baggage gate 300 is designed such that a baggage conveying device 301 passes through the R FI D baggage gate 300. The baggage conveying device 301 may be any kind of baggage conveyer or alike configured for transporting luggage L. The luggage should be provided with an R FI D baggage chip 302 according to an embodiment of the present invention. For reading from and/or writing onto the R FI D baggage chip 302, the R FI D baggage gate 300 comprises at least one RFI D reader 3 1 and at least one RFI D programmer 33 , respectively.

The R FI D reader 3 1 and/or the R FI D programmer 33 are arranged at the R FI D baggage gate 300, such that they can read baggage identification data from the RFI D baggage chip 302 and right baggage identification data onto the R FI D baggage chip 302, respectively. By reading the baggage identification data, the R FI D baggage gate 300 can communicate a certain location of the luggage L to the DCS unit 1 , 2 and/or to displays situated at baggage claim areas, custom areas, as well as entrances and exits thereof, and alike for displaying the baggage identification data. By possibly additionally writing bag- gage identification data onto the RFI D baggage chip 302 in the baggage gate 300, the luggage L may not be simply traced, but the tracing information can be saved on the R FI D baggage chip 302 so that it may be later processed.

Figure 1 0 shows a schematic illustration of a data packet 400 according to an embodiment of the present invention. The data packet 400 comprises a header 401 and a data body 402. The data packet 400 is used between all infrastructures according to the present invention using the self-organising remote procedure call protocol for communication and data exchange. The protocol may preferably be designed to operate as a SCTP protocol. In the alternative, also common TCP and U DP protocols may be used . The data packets 400 may be encrypted for example according to TNS version 1 .3. Encryption may be omitted when using a VPN connection as commonly installed in all airport network solutions.

The header 401 for example has a size of 1 6 bytes for example separated into eight fields: a version field 403 , a format field 404, a compression field 405, a code field 406, a se- quence field 407, a metaSize field 408, and a binSize field 409.

The version field 403 may have a size of 1 byte for identifying the version of the protocol used. Client and server exchanging data with each other must use the same version of a data packet 400. The value of the version field 403 of "0" may indicate that the version is invalid, since the current version has a value of " 1 ". The format field 404 indicates the format of the metadata. A value of "0" of the format field 404 may identify a meter that of packet using Concise Binary Object Representation (CBOR ) in line with R FC 7049.

The compression field 405 indicates whether or not binary data 41 0 and metadata 41 1 within the data packet 400 are compressed not. A value of "0" of the compression field 405 indicates that no compression is used. A value of " 1 " of the compression field 405 indicate that binary and metadata, 41 0, 41 1 are compressed using a deflate algorithm for example. The code field 406 contains a code for defining a certain query and response in line with to a method according to the present invention. Preferably, the codes are represented in the hexadecimal system. For example, codes may categorised as follows:

Value 0x00 Unacceptable

Value 0x01 OxOF Special Codes

Value 0x10 OxlF Request Codes

Value 0x20 0x2F Response Codes

Value 0x30 0x3F Informational Codes

Value 0x40 0x4F Client Error Codes

Value 0x50 0x5F Server Error Codes

Value 0x60 OxFF Reserved for future versions

The following exemplary codes can be used according to the respective functions when exchanging data in a system according to the present invention:

OxOA - Request for a list of servers

0x10 - Request

0x20 - Response (no errors)

0x2F - Server Notification

0x3A - Host does not accept the connection, Reconnect to an- other host (OxOA)

0x3F - Requested method was not found

0x40 - Invalid request or metadata

0x41 - Not supported protocol version

0x4E - The client is not authorized

0x4F - Denied Access to The client

0x50 - Unknown server error

The sequence field 407 contains the packet number. Preferably, a unique packet number is used for identifying the packet and associated to a certain query and response. The packet number can be a 32-bit integer. It should be increased by a value of 1 or any other practicable value in the server should respond to a query data packet 400 with the same number as contained in the sequence field 407 of the sequence field 407 of that query data packet 400. A special value of "0" may be inadmissible for requests, but can be used by the server to send notices. For example, code = 0x2F (Server Notification)

sequence = 0 represents a notification from the server (response - without request) . In that particular case, a client should not confirm the notification. Upon reaching the maximum value of 6871 9476735 (OxFFFFFFFF) , the client has to restart the packet number contained in the sequence field 407 with the value of 1 . A query response scheme in line with a method according to the present invention may for example be:

Client: Request 1

Server: Response 1

Client: Request 2

Server: Response 2

Server: Response 0 (Notification, for example new data is appeared)

Client: Request 15345 (Read Data)

Server: Response 15345

Client: Request 68719476735

Server: Response 68719476735

Client: Request 1

Server: Response 1

The metaSize field 408 indicates the amount of meta data, such as all information or identification data used in a method according to the present invention, contained in the metadata field 41 0 within the data body 402 of the data packet 400. The binSize field indicates the amount of binary data, such as for example image scans, contained within data body 402 of the data packet 400.

An exemplary parsing/reading order of the data packet 400 may be as follows:

1. Read 16 bytes (header size) from a socket

2. Check the "Compression" field 2.1. Equals 0 - Uncompressed Data

2.1.1. Continue reading from a socket until the number of bytes will not be equal (metaSize) [1]

2.1.2. Extract metadata according to the format in the format field

2.1.3. Continue reading from a socket until the number of bytes will not be equal (binSize) [1]

2.2. Equals 1 - Deflate Compressed Stream

2.2.1. Countiune reading from a socket until the number of bytes will not be equal (metaSize) and use stream decompression [ 1 ]

2.2.2. Extract metadata according to the format in the format field

2.2.3. Countiune reading from a socket until the number of bytes will not be equal (binSize) and use stream decompression [ 1 ]

Preferably, data should be read in chunks having multiples of 1 024 bytes ( 1 K, 4K, 8K, etc. ). Compressed data should be decompressed chunk by chunk while reading.

The described protocol according to the present invention supports multiple check-in modes which should not be understood as being limiting to the scope of the present invention but merely represent examples of the capabilities of AiO CUSS Modules 1 00 used in a system according to the present invention:

1 ) Standard self check-in + drop-off standard baggage;

2 ) Standard self check-in + drop-off RFI D baggage;

3 ) RFI D self check-in + drop-off standard baggage;

4) RFI D self check-in + drop-off R FI D baggage;

5 ) RFI D boarding pass for ON LI N E/MOBI LE checked in passengers;

6 ) Drop-off standard baggage for O N LI N E/MO BI LE checked in passengers;

7 ) Drop-off R FI D baggage for ON LI N E/MO BI LE checked in passengers. The AiO CUSS Modules 1 00 according to the present invention will support an increasing number of scenarios for check-in procedures. Presently, the following scenarios are feasible in line with the check-in modes listed above:

1 ) In a standard scenario, the passenger P will carry out a self check-in and baggage drop at a certain AiO CUSS Module 1 00. The passenger will obtain an ordinary (paper) boarding pass and baggage tag printed out at the AiO CUSS module 1 00.

2 ) In a regular check-in and baggage R FI D scenario, the passenger P carries out the check-in procedure and obtains an ordinary (paper) boarding pass at an AiO CUSS Module 1 00 in line with the present invention. The passenger P is in possession of luggage L with a builtin RFI D baggage chip 302. During the check-in procedure, the system according to the present invention records on the R FI D baggage tag 302 a baggage tag number given by the DCS. The step of printing out an ordinary paper baggage tag can be omitted.

3 ) In an R FI D boarding pass and baggage tags scenario, the passenger P is provided with an R FI D boarding pass an RFI D baggage tag after carrying out the check-in procedure at an AiO CUSS Module 1 00 in line with the present invention. Additionally, the system according to the present invention may provide the passenger P with a paper receipt or coupon for example in the form as it is a part of commonly known boarding passes accord ing to the prior art in order to facilitate identification of the passenger by airport staff personnel and aeroplane cabin crew personnel. The R FI D board ing pass is collected at the gate by the R FI D boarding gate 200 according to the present invention.

4) In another R FI D check-in and RFI D baggage tags scenario, the passenger P carries out a self check-in at a AiO CUSS Mod ule 1 00 according to the present invention. After the check-in, the passenger P obtains an RFI D boarding pass which is non- recordable in line with the present invention. Additionally, the system according to the present invention may provide the passenger P with a paper receipt or coupon for example in the form as it is a part of commonly known boarding passes according to the prior art in order to facilitate identification of the passenger by airport staff personnel and aeroplane cabin crew personnel. Moreover, an R FI D baggage chip 302 in line with the present invention is provided to the passenger.

5 ) In an R FI D boarding pass scenario for online or mobile check-in, the passenger P carries out the check-in procedure on an own computing or mobile device. The passenger P print out the boarding pass himself on an external printer or loads the boarding pass onto the mobile device. This boarding pass is exchanged with an RFI D boarding pass at the AiO CUSS Module 1 00 according to the present invention.

6 ) In an R FI D boarding pass for online or mobile check-in and standard baggage drop of scenario, the passenger P is provided with an R FI D boarding pass as described under previous item 5 ) above. In addition, the passenger P checked in luggage L in line with the method according to the present invention and is handed out an RFI D baggage chip at the AiO CUSS Module 1 00 according to the present invention.

7 ) In an R FI D boarding pass for online or mobile check-in and RFI D baggage drop of scenario, the passenger P is provided with an R FI D boarding pass as described in that item 5 ) above and the build in R FI D chip 302 others baggage is used as described under item 2 ) above at the AiO CUSS Module 1 00 according to the present invention.

When boarding at the RFI D baggage gate 300, binary data 41 1 , such as a scanned in image from the passenger P or in passport or I D of the passenger P may be used for identifying the passenger P by airport staff personnel S. Therefore, an R FI D baggage 300 ac- cording to the present invention may be provided with a display for displaying the binary data 41 1 . Similar procedures may be used at any E-gates or barriers equipped with RFI D readers 3 1 in line with the present invention. Such a comparison procedure of data and for example an image of the passenger P entering the boarding gate may also be carried out automatically by means of respective digital image processing after automatically recording an image of the passenger P.

Figure 1 1 shows a schematic illustration of a check-in and/or boarding procedure 500 at the AiO CUSS Module 1 00 and an RFI D baggage 300, respectively, in line with the method according to the present invention. In a step S 1 , an airline is selected by a passenger P. In a step S2 , the passenger P is identified . In a step S3 , a certain seat in an aeroplane is assigned to the passenger P. I n a step S4, a check-in of the passenger P is confirmed. In a step S5 , the passenger P is requested to check-in luggage L. In a step S6, the passenger P carries out the baggage check-in. In a step S7, baggage identification data is issued to the passenger P. In a step S9, a boarding pass is issued to the passenger P. In a step S9 the boarding pass is collected from the passenger at an RFI D baggage gate 300 line with the present invention.

In an exemplary check-in scenario, a protocol for communicating between the AiO CUSS Module 1 00 and the DCS unit in line with the present invention may have an exemplary form as follows while some of the above-mentioned steps S 1 to S9 can be left out according to the respective scenario:

! - Query method name

(...) - Arguments

{ ... } - Dictionary object (also known as Map, HashTable) key-value pairs

[ ... ] - Array of elements

NULL - No value

// - Comments within data samples Individual definition for respective scenario

1. Get Airlines (select airline)

2. Find passenger (Passenger data input)

3. Seat assign (select preferred seat )

4. Check-In (Confirm information and seat)

5. Confirm boarding pass is printed

Step 1

Query :

lairlines.list ({ "date" : "2015-04-03" } )

Reply (Now four active flights provided by two airlines) { "iata" : "ZZ" , "name":"Zet Airlines", "logo" : "Binary data"},

{ "iata" : "XX" , "name" : "Xet Airlines", "logo" : "Binary data"}

Step 2

Passenger selected airline "Zet Airlines" (iata - ZZ) and inputs :

1. Last name - "Tesla"

2. PNR - "ABC1234"

Query

!passengers . list ({

"airline" : "ZZ",

"name_last": "TESLA",

"pnr": "ABC1234",

"ticket" :NULL // E-Ticket

})

Reply (information provided for issuing boarding pass)

"flight_id": 9876, // Internal

"passenger id": 5432, // Internal

"is bp printed": false, // "true" if already printed "haslnfant" : false, //

"nameLast": "TESLA"

"nameFirst": "NIKOLA"

"gender": "M", // M - Male, F - Female

"seat": NULL, // No seat assigned "group": NULL, // No group

"pnr": "ABC123",

"ticket": "123456789", // E-Ticket number "sequence": NULL, // Check-In sequence (not assigned)

"flightCode" : "1234D",

"flightDate" : "2015-04-03",

"flightTime" : "12:35", // Departure time

"boardTime": "11:55", // Boarding time

" srcLocation" : "London",// From City

"srcAirportlATA" : "LHR" , / / From Airport IATA

" srcAirport" : "Heathrow", // From Airport Name

"dstLocation" : "New York",// Destination City

"dstAirportlATA" : "JFK",// Destination Airport IATA "dstAirport" : " John F Kennedy", // Destination Airport

Name

}

]

If reply contains more then one record, passenger should select himself.

Step 3

Now passenger should select seat we need retrieve seat map. Not full seatmap, just only parts for passenger class

Query

! flight . seatmap ({

"flight_id": 9876, //

"passenger_id" : 5432, //

})

Reply :

{

"deck" : [ {

"name": "Main deck"

"parts": [{

"class": "Y",

"name": "Economy",// Class Name

"cols": 7,

"rows": 10, / / Rows count

"start": 7, / / Rows start numbering from exclude" : : [13], // Skip row "13"

config" : ["A", "B", " -", "D", "E"] ,

spaces" : [

{ "row" : 5, "col": 4},

{ "row" : 5, "col": 5},

r

exists" : [

{ "row" : 5, "left": false, "right" : true } ,

{ "row" : 6, "left": true, "right" : false }

]

}] ,

"deny": {"7A": "ICON", "7B":""}, // Deny seats By this reply a seatmap is created having one section containing 10 rows; numbering starts from 7, exclude row "13": rows 7-12 (6 rows ) + 14-17 (4 rows)

Passenger select seat "7C"

Query

!passenger . seat . assign ({

"flight_id": 9876,

"passenger id": 5432,

"seat": "7C",

})

Reply

{

"error": NULL, // Means "OK" if no error message

Step 4

Now data displayed on screen and passenger should confirm it .

After confirm Query.

!passenger . confirm ({ // Check-In

"flight_id": 9876,

"passenger id": 5432,

})

Reply

"seat": "7C",

" sequence" : 42 ,

/ / Same data as Step 2 reply with extras

"barcode":

"bags_count" : 0,

"bags weight": 0,

Step 5

At this step the boarding pass is issued by printing, successful printing is confirmed.

Query

!passenger .bp printed ({// Boarding pass printed

"flight_id" ^~ : 9876,

"passenger id": 5432,

})

Reply

{NULL} Aspects of the Present Invention

1. Departure Control System (DCS), including:

a) a central DCS unit (1 ), the central DCS unit (1 ) including a central DCS unit communication interface (10) for operatively connecting to and exchanging information with at least one airport DCS unit (2) remote from the central DCS unit (1 );

b) at least one airport DCS unit (2), the at least one airport DCS unit (2) including an airport DCS unit communication interface (20) for operatively connecting to and exchanging information with the central DCS unit (1 );

wherein the central DCS unit (1 ) is designed to execute a set of central DCS routines and the at least one airport DCS unit (2) is designed to execute a set of airport DCS routines;

wherein the at least one airport DCS unit (2) includes or is operatively connected to an RFID communication unit, the RFID communication unit being configured to exchange flight-related data, in particular flight-related data of a specific passenger, with an RFID chip.

2. Departure control system according to aspect 1, wherein the departure control system including a plurality of airport DCS units (2, 2', 2").

3. Departure control system according to either of the preceding aspects, wherein the set of central DCS routines is at last in part different from the set of airport DCS routines. Departure control system according to either or the preceding aspects, wherein the at least one airport DCS unit ( 2 ) is configured to associate the specific passenger with a passenger identification code, the passenger identification code being-pre- stored on an R FI D chip. Departure control system according to aspect 4, wherein the at least one airport DCS unit ( 2 ) includes or is operatively coupled to a boarding RFI D reader (3 1 ) and is configured to read the passenger identification code that is stored on an R FI D chip which is presented to the boarding RFI D reader (3 1 ) , wherein the airport DCS unit is further configured to change a passenger status in response to reading the passenger identification code. Departure control system according to either of aspect 4 or aspect 5, wherein the at least one airport DCS unit ( 2 ) includes or is operatively coupled to an RFI D collecting unit ( 51 ), the RFI D collecting unit ( 51 ) being configured to physically collect RFI D chips carrying passenger identification codes. Departure control system according to either of aspect 4 to aspect 6 , wherein the at least one airport DCS unit ( 2 ) is config ured, subsequent to associating the specific passenger with the passenger identification code, to associate a further specific passenger, the further specific passenger being different from the specific passenger, with the same passenger identification code. Departure control system according to either of aspect 4 to aspect 7 , wherein the at least one airport DCS unit ( 2 ) includes or is operatively coupled to a barrier unit (40, 50), wherein the at least one airport DCS unit ( 2 ) is configured to control the barrier unit (40, 50) to unblock if the passenger identification code that is stored on an RFID chip presented to a barrier RFID reader (41 , 51 ) is associated with a validly checked-in passenger. Departure control system according to either of aspect 4 to aspect 8, wherein the at least one airport DCS unit (2) is configured to associate a passenger only if no passenger is associated with the passenger identification code. Departure control system according to either of the preceding aspects, wherein the at least one airport DCS unit (2) includes or is operatively coupled to a passenger location unit (21 -5, 60, 61 ), wherein the passenger location unit (21 -5, 60, 61 ) is configured to receive a passenger identification input indicative of a specific passenger to be located, wherein the passenger location unit (21 -5, 60, 61 ) includes a number of RFID communication units (60-1 , 60-2, ...60-r, 61 -1 , 61-2, ...61 -s), wherein each of the RFID communication units (60-1, 60-2, ... 60-r, 61-1, 61- 2, ...61 -s) is associated with a corresponding airport section, wherein the passenger location unit (60-1 , 60-2, ... 60-r, 61 -1 , 61-2, ... 61 -s) is configured to determine an airport section in which an RFID chip with data that are associated with the specific passenger is located, and to provide an indication with respect to this airport section. Departure control system according to either of the preceding aspects, wherein the at least one airport DCS unit (2) is configured to determine if an overweight surcharge is due for a specific piece of baggage of a specific passenger and to associate this specific passenger with a passenger identification code on an RFID chip and/or print a boarding pass only after payment of the overweight surcharge. Departure control system according to either of the preceding aspects, wherein the flight-related data include baggage identification data, the baggage identification data being indicative for a specific piece of baggage and a specific flight, and wherein the RFID communication unit includes an RFID programmer (33), and wherein the at least one airport DCS unit (2) is configured to program the baggage identification data into an RFID chip, the RFID chip being associated with the piece of baggage. Departure control system according to either of the preceding aspects, wherein the at least one airport DCS unit (2) is designed to operate in a connected mode if operative connection with the central DCS unit (1 ) is present and is further designed to alternatively operate in an autonomous mode if operative connection with the central DCS unit (1 ) is not present, wherein the at least one airport DCS unit (2) is designed, in the connected mode, to locally store flight-related data and to synchronize the locally stored flight-related data with flight-related data stored by the central DCS unit (1); wherein the at least one airport DCS unit (2) is further designed, in the autonomous mode, to operate as DCS temporarily independent from the central DCS unit (1 ). Passenger location unit (21 -5, 60, 61 ), wherein the passenger location unit (21 -5, 60, 61 ) is, in an operational state, arranged at or in an airport, wherein the passenger location unit (21-5, 60, 61) includes a number of RFID communication units (60-1 , 60-2, ...60-r, 61-1 , 61-2, ...61 -s), each of the RFID communication units (60-1, 60-2, ... 60-r, 61-1, 61-2, ... 61 -s) being associated with a corresponding airport section, wherein the passenger location unit (60-1 , 60-2, ...60-r, 61 -1 , 61 -2, ...61 -s) is configured to receive a passenger identification input indie- ative of a specific passenger to be located and is further to determine an airport section in which an R FI D chip with data that are associated with that specific passenger is located, and to provide an indication with respect to this airport section.