DE212018000068U1

DE212018000068U1 - Systeme für Interaktionen zwischen Ticketinhabern und Selbstbedienungsfunktionen

Info

Publication number: DE212018000068U1
Application number: DE212018000068.9U
Authority: DE
Original assignee: Sita Ypenburg BV
Current assignee: SITA B.V., NL
Priority date: 2017-11-06
Filing date: 2018-11-02
Publication date: 2019-04-10
Anticipated expiration: 2028-11-03

Abstract

System zum Erleichtern der Interaktion zwischen einem Ticketinhaber und einer mit dem Ticket zusammenhängenden Selbstbedienungsfunktion, das Folgendes umfasst:
eine Selbstbedienungsfunktion;
ein Mobilgerät, auf dem Informationen über das Ticket gespeichert sind;
wenigstens ein Geolocation-Gerät; wobei das Mobilgerät so konfiguriert ist, dass es das Geolocation-Gerät an einem Standort in der Nähe einer Selbstbedienungsfunktion erfasst, und
wenigstens einen Server, auf dem Computersoftware gespeichert ist, um die folgenden Schritte auszuführen:
Aktivieren einer Anwendung auf dem Mobilgerät beim Erfassen des Geolocation-Geräts in der Nähe des Standortes durch das Mobilgerät, wobei die Anwendung mit der Selbstbedienungsfunktion zusammenhängt; und
Übermitteln von Informationen über die Selbstbedienungsfunktion, einschließlich Richtungsangaben, über die Anwendung an das Mobilgerät.

Description

Die vorliegende Erfindung ist für automatisierte Interaktionen mit Passagierdiensten wie der Gepäckabfertigung ausgelegt. Insbesondere, aber nicht ausschließlich, ist sie für die Handhabung von Gepäck auf Flughäfen, Seehäfen, Eisenbahnen, an anderen Massenverkehrsorten, Veranstaltungsorten, Stadien und Arenen vorgesehen.
In einer Flughafenumgebung kann das Aufgeben von Gepäck ein zeitaufwändiges und stressiges Erlebnis für Passagiere sein. Zu Stoßzeiten können sich lange Warteschlangen bilden, die zum Teil durch den langsamen, mit Personal besetzten Check-in-Prozess verursacht werden, wobei Gepäcketiketten für jedes Gepäckstück vom Bodenpersonal ausgedruckt und am Gepäckstück befestigt werden.
Der Gepäckaufgabeprozess bedeutet für Flughäfen und Fluggesellschaften aufgrund der laufenden Betriebs- und Wartungskosten für die Gepäcketikettierungsausrüstung und der Personalkosten in Verbindung mit dem Check-in-Prozess und der Wartung hohe Gemeinkosten.
In den vergangenen Jahren wurden einige Maßnahmen getroffen, um diese Kosten zu reduzieren, den Check-in-Prozess zu rationalisieren und die Wartezeiten für Passagiere zu verkürzen. Viele Fluggesellschaften bieten heute zum Beispiel Online-Check-in-Dienste an, so dass Passagiere ihr Gepäck bei der Ankunft am Flughafen nur noch abgeben müssen. In jüngerer Zeit haben einige Fluggesellschaften halbautomatisierte Selbstbedienungs-Gepäckaufgabestellen eingeführt, wo ein Gepäcketikett anhand eines Scans einer Bordkarte erstellt und vom Passagier befestigt wird. Einige Fluggesellschaften haben mit einer kombinierten Selbstbedienungs- und Bodenpersonal-unterstützten Einrichtung einen Hybridansatz eingeführt. Obwohl diese Maßnahmen die oben erörterten Probleme etwas gemildert haben, erfordern sie alle eine Art Interaktion zwischen einem Passagier und einem Bodenabfertiger, einem Kiosk oder einer anderen computerisierten Ausrüstung. Diese Lösungen verursachen selbst weitere Probleme, da sie wesentliche Modifikationen an den Check-in-Schaltern auf Flughäfen und erhebliche Investitionen in die Selbstbedienungsausrüstung erfordern. Beides ist teuer und operativ komplex.
Zusätzlich zu den oben genannten Punkten gibt es ein zunehmendes Bewusstsein für die Bedürfnisse behinderter Passagiere. Viele Länder haben Gesetze erlassen, um zu gewährleisten, dass Passagiere mit Behinderungen und eingeschränkter Mobilität auf Flughäfen angemessen unterstützt werden. Ein Beispiel ist die EU-Verordnung 1107/2006, in der die Check-in- und Gepäckerfassungs- und -aufgabeprozesse als Bereiche bezeichnet werden, in denen der Flughafen für die Bereitstellung von Hilfe für Passagiere mit Behinderungen oder eingeschränkter Mobilität zuständig ist. Bestehende oder zukünftige Gesetze erfordern den Zugriff auf jede automatisierte oder Selbstbedienungs-Gepäckaufgabelösung und können beispielsweise eine festgelegte maximale Höhe für den Berührungszugriff von einem Rollstuhl aus und festgelegte zusätzliche Steuergeräte für sehbehinderte Passagiere voraussetzen.
Es ist Ziel der Erfindung, diese Probleme anzugehen und zu mildern.
Die Erfindung stellt ein System zum Erleichtern der Interaktion zwischen einem Ticketinhaber und einer mit dem Ticket zusammenhängenden Selbstbedienungsfunktion bereit, das Folgendes umfasst: eine Selbstbedienungsfunktion; ein Mobilgerät, wobei auf dem Mobilgerät Informationen bezüglich des Tickets gespeichert sind; wenigstens [sic] Geolocation-Gerät; wobei das Mobilgerät so konfiguriert ist, dass es das Geolocation-Gerät an einem Standort in der Nähe einer Selbstbedienungsfunktion erfasst, und wenigstens einen Server, auf dem Computersoftware gespeichert ist, um die folgenden Schritte auszuführen: Aktivieren einer Anwendung auf dem Mobilgerät beim Erfassen des Geolocation-Geräts in der Nähe des Standortes durch das Mobilgerät, wobei die Anwendung mit der Selbstbedienungsfunktion zusammenhängt; und Übermitteln von Informationen über die Selbstbedienungsfunktion, einschließlich Richtungsangaben, über die Anwendung an das Mobilgerät.
Ausgestaltungen der Erfindung können den Vorteil haben, dass sie die Interaktion zwischen Ticketinhabern und Selbstbedienungsfunktionen vereinfachen. In einer bevorzugten Ausgestaltung ist die Selbstbedienungsfunktion ein Gepäckaufgabesystem, zum Beispiel zur Verwendung auf einem Flughafen. Ausgestaltungen der Erfindung können den Vorteil haben, dass sie Interaktionen mit der Gepäckaufgabe einfacher gestalten und es der Fluggesellschaft oder anderen Dienstleistern ermöglichen, den Umfang an menschlicher Interaktion, die für die Gepäckaufgabe erforderlich ist, und andere Selbstbedienungsprozesse zu reduzieren und somit Kosten und Gemeinkosten zu senken.
In einer Ausgestaltung der Erfindung bezieht sich das Ticket auf eine Passagierreise und enthält eine Passagier- und Reiseidentifikation. Die Ticketinformationen können eine Bordkarte beinhalten. In einer Ausgestaltung kann die Anwesenheit des Mobilgeräts an dem Standort unter Verwendung eines Geolocation-Geräts, z.B. eines Bluetooth-Beacons, erfasst werden.
In einer Ausgestaltung fragt die Anwendung die auf dem Mobilgerät gespeicherten Ticketinformationen ab und übermittelt die Ticketinformationen an einen entfernten Server. Als Reaktion auf den Empfang der Ticketinformationen liefert der entfernte Server der Anwendung Informationen bezüglich der Selbstbedienungsfunktion, um diese dem Nutzer des Mobilgeräts zu präsentieren.
In einer Ausgestaltung ist die Selbstbedienungsfunktion eine Gepäckaufgabestelle und die Informationen über das Ticket beinhalten eine Bordkarte; die Passagierinformationen in der Bordkarte werden an ein Abflugkontrollsystem übermittelt. Das Abflugkontrollsystem kann ermitteln, ob mit der Bordkarte zusammenhängendes Gepäck für eine Gepäckaufgabe berechtigt ist und übermittelt die Berechtigung an das Mobilgerät.
In einer Ausgestaltung der Erfindung wird beim Abgeben von Gepäck an der Gepäckaufgabestelle das Gepäck gewogen, und es wird ermittelt, ob das Gewicht ein zulässiges Gewicht überschreitet, und wenn das Gewicht ein zulässiges Gewicht überschreitet, dann wird die Zahlung einer Übergepäckgebühr über die Anwendung veranlasst.
In einer Ausgestaltung wird ein Gepäcketikett an der Gepäckaufgabestelle ausgedruckt und es werden Anweisungen zum Befestigen des Gepäcketiketts am Gepäck übermittelt, um sie dem Nutzer des Mobilgeräts über die Anwendung zu präsentieren.
In einer Ausgestaltung werden beim Empfang von Gepäck durch die Gepäckaufgabestelle Informationen über das Anbordgehen (Boarding) und eine Wegbeschreibung zu einem Abfluggate an die Anwendung übermittelt.
Ausgestaltungen der Erfindung werden nun unter Bezugnahme auf die Begleitzeichnungen lediglich beispielhaft beschrieben. Dabei zeigt:

1 eine schematische Übersicht über eine Ausgestaltung der Erfindung;
2 ein Ablaufdiagramm, das die Schritte in einem Verfahren zum Erleichtern der Interaktion zwischen einem Ticketinhaber und einer mit dem Ticket zusammenhängenden Selbstbedienungsfunktion darstellt;
3 eine Übersicht über ein System, das die Erfindung verkörpert;
4 die logische Architektur des Systems;
5 die logische Architektur des Cloud-Dienstes.
6 ein Klassendiagramm, das ein Dienstmodell zeigt, das verfügbare Schnittstellen anzeigt;
7 eine schematische Darstellung des Gepäckeinheit-Controllers;
8 die Interaktionen auf hoher Ebene, die in der Anwendung auf dem Mobilgerät stattfinden;
9 ein Prozessablaufdiagramm für die mobile App; und
10 ein Prozessablaufdiagramm für das gesamte System.

Beschreibung bevorzugter Ausgestaltungen
In den nachfolgend gegebenen Beispielen wird die Gepäckaufgabesequenz von einem Smartphone, Tablet, Laptop oder einem ähnlichen mobilen Computergerät eines Passagiers initiiert. Geolocation-Technologie wie Bluetooth-Beacons oder andere Standortsensoren werden verwendet, damit eine App auf einem Mobilgerät erkennen kann, wenn sie sich in der Nähe eines bestimmten Beacons oder eines anderen Geräts befindet. Die automatische Standorterfassung ist für die Erfindung jedoch nicht wesentlich. Obwohl mit Bezug auf die Gepäckaufgabe beschrieben, können Ausgestaltungen der Erfindung auch in Verbindung mit anderen Passagierinteraktionen verwendet werden, wie beispielsweise Passagierabfertigungskiosks zum Ausdrucken von Gepäcketiketten, Bordkarten, Scannen von Pässen und für andere Funktionen, Interaktionen mit mobil angeordneten Zahlungen über das Smartphone oder ein anderes Gerät der Passagiere und Interaktionen mit anderen Flughafeneinrichtungen, wie z.B., aber ohne darauf beschränkt zu sein, Selbstbedienungskontrollstellen und -gates, z.B. automatisierte Passkontrollgates oder - schranken. Ausgestaltungen werden mit spezifischem Bezug auf Flughäfen beschrieben, aber die Erfindung ist weiter auf jede beliebige Reiseumgebung anwendbar, in der ein Passagier einchecken oder Gepäck aufgeben muss, und schließt somit Seehäfen und Bahnhöfe ein. Ausgestaltungen der Erfindung können auch für Massenticketveranstaltungen verwendet werden, um die Leitung von Zuschauern und Publikum zu unterstützen, zum Beispiel auf Sportplätzen und Veranstaltungen wie Konzerten und Festivals.
In den in den Figuren gezeigten Ausgestaltungen, die sich speziell auf eine Flughafenlösung beziehen, wird eine über einen Flughafen verteilte Standorttechnologie wie Bluetooth-Beacons verwendet, damit das Mobilgerät eines Passagiers, z.B. ein Smartphone, Tablet, Laptop oder ein anderes Gerät, die Anwesenheit eines gegebenen Beacon erkennen kann. Es kann jede andere Geolocation-Technologie für den Innen- oder Außenbereich benutzt werden, damit das Gerät seinen relativen Standort erkennen kann. Wie sich zeigen wird, ist/sind Bluetooth-Beacons oder eine andere Standorttechnologie, obwohl bevorzugt, für die Erfindung nicht wesentlich. Das Mobilgerät verfügt über eine Gepäckaufgabe-Anwendung, die vom Passagier heruntergeladen wird. Diese Anwendung kann eine spezifische Gepäckaufgabe-App oder ein Gepäckaufgabe-Modul einer App der Fluggesellschaft oder des Flughafens sein. Das Mobilgerät 10 erfasst die Anwesenheit der Standortgeräte, wenn es zum Beispiel in den Flughafen gelangt und in der Nähe eines ersten Beacon 12 vorbeikommt. Während der Passagier durch den Flughafen in Richtung Gepäckaufgabebereich geht, wird das zweite Beacon 14 vom Gerät 10 erfasst, wodurch die Gepäckaufgabe-Anwendung auf dem Gerät gestartet wird. Die Erfassung des ersten Beacon durch das Mobilgerät des Passagiers beim Betreten des Flughafens ist nicht wesentlich, aber vorteilhaft, da die Erfassung von Beacons durch das Gerät die Interaktion mit anderen Diensten ermöglicht, die auf dem Flughafen bereitgestellt werden.
Die Nutzung einer Beacon-Erfassung zum Verfolgen der Bewegung eines Passagiers durch einen Flughafen oder eine ähnliche Umgebung ist in der WO 2013/117723 beschrieben.
Nach dem Starten der Anwendung fragt diese entweder die Buchungsdetails des Passagiers von der im Telefon gespeicherten mobilen Bordkarte ab, z.B. mit Apple® Wallet oder ähnlichen Apps, oder, wenn keine Bordkarte gespeichert ist, wird der Passagier gebeten, seine ausgedruckte Bordkarte entweder mit der Kamera seines Geräts oder mit einem an der Gepäckaufgabestelle bereitgestellten Scanner zu scannen.
Wenn eine mobile Bordkarte im Gerät gespeichert ist, erkennt die App anhand der gespeicherten Daten zum Passagier, ob der Passagier Gepäck eingecheckt hat oder nicht und wenn ja, wie viel. Wenn Gepäck eingecheckt wurde, zeigt die App dem Passagier Anweisungen an, wie der Gepäckaufgabeprozess ablaufen soll. Wenn kein eingechecktes Gepäck erfasst wird, kann die App dem Passagier die Möglichkeit geben, die Buchung dahingehend zu ändern, dass das Einchecken gestattet wird.
Wenn die Interaktion mit einer anderen Selbstbedienungsfunktion erfolgt, funktioniert der Prozess auf ähnliche Weise. Wenn die Funktion beispielsweise die Selbstbedienungs-Passkontrolle ist, erfasst die App, die wiederum eine spezifische App oder ein Modul einer App der Fluggesellschaft oder des Flughafens ist, die Anwesenheit des Geräts in einem Passüberprüfungsbereich und zeigt dem Nutzer Anweisungen über das Gerätedisplay an, wie fortzufahren ist und wie der Pass-Scanner zu bedienen ist.
Somit nutzt das System in einer Ausgestaltung ein Smartphone oder ein anderes Mobilgerät des Passagiers und optional eine beliebige Geolocation-Technologie für den Innen- oder Außenbereich, wie Bluetooth-Beacons oder andere Arten von Sensoren und Mapping-Anwendungen, um den Gepäckaufgabeprozess oder einen beliebigen anderen Passagierprozess, der eine Interaktion mit einem System auf einem Flughafen oder anderen zugehörigen Standorten erfordert, zu automatisieren. In der Nähe eines Gepäckaufgabebereichs, eines/einer Passagierabfertigungskiosk oder -station, einer Kontrollstelle oder eines eGates startet eine mobile App auf dem Smartphone oder einem anderen Mobilgerät des Passagiers und der Passagier und seine Buchungsdetails werden erkannt. Das Gerät des Passagiers „koppelt“ sich mit der Gepäckaufgabeeinheit und weitere Anweisungen zur Erledigung der Gepäckaufgabe werden alle elektronisch/drahtlos über das Smartphone oder Mobilgerät ausgeführt. Das System umfasst eine mobile Anwendung zum Beispiel auf einem Smartphone, eine mit der Gepäckaufgabeeinheit verbundene Verarbeitungseinheit (Controller) und einen Cloud-basierten API-Dienst, der die Interaktion zwischen der mobilen Anwendung und der Gepäckaufgabeeinheit, vermittelt oder „vertritt (Proxy)“, wie nachfolgend näher beschrieben wird.
Obwohl die nachfolgend beschriebene Ausgestaltung Bluetooth als Auslösemechanismus zum Koppeln eines Mobilgeräts mit dem Gepäcksystem nutzt, sind andere Verfahren möglich. Zum Beispiel könnte eine andere Art der automatischen Kopplung angewendet werden, wie beispielsweise eine andere Nahfeldkommunikation (NFC), WIFI- oder BLE-Beacons, oder ein manuelles Verfahren wie ein QR-Code oder ein anderer Barcode, der vom Besitzer des Mobilgeräts zum Starten der Anwendung gescannt wird, oder ein Sprachaktivierungsbefehl wie Amazon Alexa TM. Wenn Barcodes verwendet werden, kann der Passagier einen 2D-Barcode auf einem Aufkleber an einem Check-in-Schalter scannen oder den Code auf bekannte Weise abfotografieren. Um Sicherheitsbedenken anzugehen, können Barcodes mit E-Ink erstellt und regelmäßig geändert werden. Der Klarheit halber erfolgen Kommunikationen zwischen dem Mobilgerät und dem Gepäckabfertigungssystem (BHS) über einen API-Dienst, wie nachfolgend beschrieben, unter Verwendung von WIFI oder einem anderen Kommunikationsprotokoll.
Der Gepäckaufgabeprozess ist in 2 ausführlicher aus der Sicht des Passagiers dargestellt. Der Prozess ist allgemein bei 100 dargestellt. Bei Schritt 102 checkt der Passagier online über sein Smartphone oder ein anderes Mobilgerät ein. Wie oben erwähnt, könnte dies über eine spezifische Anwendung oder über ein Check-in-Modul auf der Website der Fluggesellschaft erfolgen. Im Rahmen des Check-in-Prozesses wird eine mobile Bordkarte erstellt, die verschiedene Passagierinformationen enthält, inkl. Passagier-ID und Freigepäck. Die Bordkarte wird an einem geeigneten Speicherort auf dem Mobilgerät gespeichert. Ein geeigneter Speicherort ist beispielsweise die Apple Wallet-Anwendung auf Geräten, die mit Apple IOS betrieben werden, oder Google PassWallet auf Android-Geräten. Andere Speicheroptionen sind möglich.
Jede Fluggesellschaft kann zwischen dem Angebot eines Zweischritt-Selbst-Gepäckaufgabeprozesses und eines Einschrittprozesses entscheiden. Das Beispiel in 2 ist ein Zweischrittprozess, bei dem der Passagier bei Schritt 106 ein Gepäcketikett ausdruckt und das Etikett an seinem Gepäck befestigt. Dieser Ausdruck kann in der häuslichen Umgebung oder Büroumgebung des Nutzers oder an einem Kiosk auf dem Flughafen erfolgen. Der Kiosk kann für das Ausdrucken von Gepäcketiketten vorgesehen sein oder eine andere Funktion, wie z.B. Online-Check-in, bereitstellen. Im Einschrittprozess fällt Schritt 106 weg und der Passagier geht direkt zur Gepäckaufgabe über.
Beim Betreten des Flughafens erfasst das Mobilgerät des Passagiers ein in der Nähe des Flughafeneingangs platziertes Beacon (12, 1). Das Mobilgerät erfasst noch ein zweites Beacon, wenn sich der Passagier beim Betreten eines Gepäckaufgabebereichs des Flughafens in der Nähe dieses zweiten Beacon befindet. Diese Erfassung instanziiert eine Absicht in der Anwendung des Mobilgeräts des Nutzers. Es erfolgt ein API-Aufruf, um Details zu der durch das Beacon repräsentierten Gepäckaufgabestelle zu erhalten, und eine Sitzungsanforderung erfolgt an den Cloud-Dienst unter Verwendung der Gepäckaufgabe-ID von dem API-Aufruf und einer Mobilgeräte-ID. Dies wird nachfolgend ausführlicher beschrieben.
Als Alternative zu Benachrichtigungen über das Smart-Gerät des Passagiers kann der betreffende Teil des Flughafens mit Hinweisschildern versehen werden, die die Passagiere anweisen, die Gepäckaufgabe-App zu öffnen oder die Website zu besuchen. Es könnte ein QR-Code oder ein anderer Barcode bereitgestellt werden, der beim Scannen mit der Kamera des Geräts die App oder Website automatisch öffnen oder den Gepäckaufgabeprozess initiieren würde, wenn diese App bereits geöffnet ist. Diese Option hat für die Fluggesellschaft den Vorteil, dass sie weiß, welche Selbst-Gepäckaufgabestelle (SBD) ein bestimmter Passagier benutzt, da die Barcodes einen individuellen Code enthalten können, der weitgehend dem Standort innerhalb des Flughafens entspricht. Dies unterstützt die Fluggesellschaft bei der Überwachung der Nutzung und der Kontrolle des Passagieraufkommens.
In einer bevorzugten Option werden sowohl Benachrichtigungen an die Geräte der Passagiere als auch Hinweisschilder verwendet, um die Zuverlässigkeit zu verbessern und sicherzustellen, dass Passagiere das System nutzen können, wenn sie zum Beispiel vergessen haben, Bluetooth einzuschalten.
In einer Ausgestaltung beinhalten die Hinweisschilder eine Anweisung in Brailleschrift für blinde oder sehbehinderte Passagiere, und die App kann Sprachanweisungen beinhalten.
Wenn die Gepäckaufgabe-App geöffnet ist, geht der Passagier bei Schritt 110 zur angegebenen Gepäckaufgabestelle. Die App kann den Passagier anweisen, sich an einem bestimmten oder einer Gruppe von Selbst-Gepäckaufgabeterminal(s) einzufinden. Zu diesem Zeitpunkt hat die Gepäckaufgabe-Anwendung oder das Modul die auf dem Gerät gespeicherten Bordkartendaten abgerufen. Hierzu können Freigepäckinformationen gehören, oder diese Informationen können mit Hilfe der Passagieridentifikation vom Abflugkontrollsystem (DCS) der Fluggesellschaft abgerufen werden. Eine Berechtigungsprüfung kann durchgeführt werden, um beispielsweise zu ermitteln, ob der Passagier zur Gepäckaufgabe zu früh oder zu spät ist oder ob die Gepäckaufgabeoption des Mobilgeräts für den jeweiligen Flug nicht verfügbar ist.
Bei Schritt 112 findet sich der Passagier im Gepäckaufgabebereich ein und die Anwendung zeigt eine Meldung an, in der er aufgefordert wird, sein Gepäck auf das Gepäckband oder die statische Waage zu stellen. Wie bei jeder herkömmlichen Gepäckaufgabe wird das Gepäck gewogen, um zu prüfen, ob es innerhalb der zulässigen Vorgaben liegt. Das Gewicht wird an die App zurück übermittelt, die das empfangene Gewicht anhand von Vorgaben prüfen kann, die entweder als Teil der Bordkarte gespeichert sind oder vom DCS abgerufen werden können.
Wenn das Gepäck die Gewichtsprüfung nicht besteht, dann wird der Passagier aufgefordert, für das Übergepäck zu zahlen. Dies kann über eine Kredit- oder Debitkarte erfolgen, die bereits in der Anwendung der Fluggesellschaft gespeichert ist, oder über eine reguläre Online-Transaktion. Die Transaktion ist vom Typ „Karte nicht vorhanden“ und für jede Fluggesellschaft spezifisch, die jeweils eigene Übergepäckgebühren haben.
Unter der Annahme, dass das Gewicht innerhalb der zulässigen Vorgaben liegt oder für ein Übergewicht bezahlt wurde, wird bei Schritt 114 nun ein Gepäcketikett ausgedruckt. Bei dem oben genannten Zweischrittprozess ist dieser Schritt nicht erforderlich, da das Gepäcketikett bereits vorhanden ist. Die App zeigt dem Passagier dann Informationen dazu an, wie das Gepäcketikett am Gepäck zu befestigen ist.
Nach dem Anbringen des Gepäcketiketts kann der LPC-Barcode über die Kamera des Geräts gelesen werden. Dies ist hilfreich, wenn ein Gepäckstück nicht am beabsichtigten Reiseziel ankommt oder der Passagier nicht zu seinem Flug erscheint oder ein Schadensersatzanspruch geltend gemacht wird. In einer Ausgestaltung kann ein 3D-Scan des Gepäcks durchgeführt werden, um zu überprüfen, ob das Gepäck innerhalb der zulässigen Abmessungen liegt und für eine Beförderung angemessen stabil konstruiert ist.
Bei Schritt 116 erfolgt ein Passagierverifizierungsschritt. Da die App Zugriff auf das DCS der Fluggesellschaft hat, kann sie das PNR (Passagiernamensregister) abrufen und die Daten auf dem Etikett mit diesem Register vergleichen. Die App kann den Passagier anweisen, ein Selfie aufzunehmen oder eine oder mehrere andere Formen der Verifizierung anzuwenden, die vom Mobilgerät angeboten werden, wie z.B. biometrische Identifikation oder Fingerabdruckerkennung. Auf diese Weise gesammelte Daten können zur späteren Bezugnahme gespeichert werden. Die Passagierverifizierung kann vor dem Ausdrucken der Gepäcketiketten erfolgen.
Wenn die Identität des Passagiers verifiziert wurde, wird bei Schritt 118 das Gepäck von dem Abflugkontrollsystem (DCS) akzeptiert und dem Passagier wird auf dem Smartphone ein Ausgabeetikett angezeigt. Dieses Etikett wird in der Anwendung und/oder auf dem Mobilgerät gespeichert. Das Gepäck wird dann dem Gepäckabfertigungssystem übergeben, wobei dieser Schritt automatisch oder mit Hilfe eines Mitarbeiters der Fluggesellschaft ausgeführt wird.
Nachdem das Gepäck nun übergeben wurde, kann die App dem Passagier weitere Informationen über seinen Flug liefern, wie z.B., aber ohne darauf beschränkt zu sein, die Einsteigezeit und das Gate. An diesem Punkt kann die App automatisch schließen oder den Passagier zu einer Wegfindungsanwendung des in der WO2013/117723 offenbarten Typs zurückbringen, die den Passagier unter Verwendung von über den Flughafen verteilten Nahfeld-Beacons zum Abfluggate führt.
3 zeigt die wesentlichen Hardwarekomponenten, die in dem oben beschriebenen Prozess verwendet werden. Auf dem Mobilgerät der Passagiere, das bei 200 dargestellt ist, befindet sich die App, die aus der Logik zum Einchecken des Gepäcks eines Passagiers besteht. Wie oben erwähnt, kann es sich bei der App beispielsweise um ein Modul einer App einer Fluggesellschaft oder eine unabhängige App handeln. Das Gerät 200 kommuniziert mit dem Abflugkontrollsystem (DCS) 210 der Fluggesellschaft und einem Cloud-Dienst 220, der einen Satz von APIs und die zugehörige Logik hostet. Ein Gepäck-Check-in-System beinhaltet eine Gepäck-Check-in-Einheit 230 und einen Controller 235, der entweder ein mit der Gepäck-Check-in-Einheit (BCIU) 230 assoziierter Hardware-Controller sein kann, der Software und/oder Firmware enthält, um mit der BCIU 230 zu kommunizieren, oder ein CUTE/CUSS-Modul, das dasselbe macht. CUTE (Common Use Terminal Equipment) und CUSS (Common Use Self Service). CUTE und CUSS sind gut bekannte Standards, die die Verwendung von Hardware durch mehrere Fluggesellschaften oder Dienstleistungsunternehmen ermöglichen. Der Controller kommuniziert auch mit dem Cloud-Dienst 220. Obwohl dies nicht unbedingt erforderlich ist, ist ein Beacon 240 zur automatischen Identifizierung des Gepäckaufgabebereichs vorgesehen, das mit dem Mobilgerät über Bluetooth TM oder ein anderes Kommunikationsprotokoll kommuniziert. Wo Beacons verwendet werden, da kommuniziert das Mobilgerät 200 auch mit einem Beacon-Registry 250, um eine Gepäckaufgabekennung abzurufen. Selbst wenn Beacons verwendet werden, ist das Beacon-Registry 250 möglicherweise nicht erforderlich, da der Dienst durch den Cloud-Dienst 220 unterstützt werden kann.
4 zeigt die logische Architektur des Systems. Im Allgemeinen fungiert der Cloud-Dienst (220, 3) als Vermittler zwischen dem Mobilgerät 200 und dem Gepäckeinheit-Controller. Der Dienst exponiert einen einzelnen Verbindungsendpunkt dem Mobilgerät, mildert jegliche Netzwerk-bezogenen Komplexitäten, ermöglicht Over-the-Air-Protokolle für mehrere Geräte, verwaltet die Verfügbarkeit des Gepäckaufgabedienstes und erstellt eine Abstraktion für jede Controller-spezifische Benachrichtigung. Eine WebSocket-Verbindung 400 wird zwischen dem Mobilgerät 200 und dem Cloud-Dienst und zwischen dem Cloud-Dienst und dem Gepäckeinheit-Controller hergestellt. Die letztgenannte Verbindung wird vom Gepäckeinheit-Controller hergestellt und für die Dauer der Betriebszeit des Controllers aufrechterhalten. Der Controller ist dafür zuständig sicherzustellen, dass die Verbindung steht. Wenn die Verbindung abgebrochen wird, muss der Controller die Verbindung wiederherstellen. Der Cloud-Dienst betrachtet die Gepäckaufgabeeinheit als nicht verfügbar, wenn die WebSocket-Verbindung nicht aktiv ist. Obwohl als WebSocket beschrieben, können andere asynchrone oder bisynchrone Verfahren angewendet werden.
Ebenso ist das Mobilgerät 200 dafür verantwortlich, eine Verbindung mit dem Cloud-Dienst 220 herzustellen und die Verbindung für die Dauer der Sitzung aufrechtzuerhalten. Wie beim Controller, wird durch Auffinden des Dienstes von jedem Mobilgerät der Prozess optimiert.
Die Ende-zu-Ende-Sitzung wird durch Binden der IDs sowohl des Mobilgeräts als auch des Gepäckeinheit-Controllers abgebildet.
Die logische Architektur des Cloud-Dienstes 220 ist in 5 dargestellt. Der Cloud-Dienst besteht aus einer Reihe von Mikrodiensten, die auf einer verteilten reaktiven Plattform gehostet werden. Jeder Dienstendpunkt registriert eine Adresse, über die Ereignisse, basierend auf operator (op), über den Ereignisbus geleitet werden. Der WebSocket-Dienst ist der externe Dienst, der direkt mit Controllern und Mobilgeräten kommuniziert.
6 ist ein Klassendiagramm 600, das ein Dienstmodell zeigt, das die verfügbaren Schnittstellen widerspiegelt, und grobkörniger als das Dienstplattformmodell ist. Die Dienste sind wie folgt:

BagDropSvc 602 Dieser Dienst umfasst die Schnittstellen, die in einer Sitzung zwischen dem Mobilgerät und dem Controller verwendet werden. Einige Schnittstellen können zu zusätzlichen Diensten, wie z.B. Sitzung, „durchlaufen“, die meisten, wenn nicht alle grundlegenden Schnittstellen werden jedoch hier verwaltet. Dazu gehören Gepäckeinführung, Gepäcketikettendruck, Wiegeservice usw.
BagDropMngntSvc 604 Dieser Dienst wickelt die Verwaltung von Controllern ab. Wenn ein Controller zum ersten Mal gestartet wird, wird eine Anmeldungsanforderung gesendet. Der Dienst interagiert mit ConfigurationSvc 606, um die Anforderung zu bestätigen und die neue Konfiguration für den Controller zu speichern. Er bearbeitet außerdem den Verfügbarkeitsstatus des Controllers.
TimerSvc 608 Eine Sitzung hat eine vorgegebene Inaktivitätsperiode. Der TimerSvc verwaltet dies und interagiert mit sessionSvc, um den Sitzungsstatus insgesamt zu bearbeiten.
ConfigurationSvc 606 Wie angegeben, interagiert dieser Dienst mit BagDropMngmtSvc, um Controller anzumelden und abzumelden. Darüber hinaus kann jeder Controller über spezifische Merkmale verfügen, die hochgeladen und gespeichert werden können. Controller können über die Schnittstelle aktiviert und deaktiviert werden.
SessionSvc 610 Dieser Dienst verwaltet eine Sitzung zwischen dem Mobilgerät und dem Controller. Er interagiert mit AuthSvc, um Nutzer bei start_session zu authentifizieren und Tokens zu validieren, und mit timerSvc, um eine Sitzung nach einer Zeit der Inaktivität zu invalidieren.
AuthSvc 612 Diese Dienstschnittstelle fungiert als Fassade für eine oder mehrere Implementierungen von Authentifizierung und Autorisierung. Bei einer ersten Implementierung werden ein lokales Nutzer-ID/Passwort-Authentifizierungsschema und JWT (JSON Web Tokens) für die Autorisierung bereitgestellt.

7 zeigt die logische Architektur des Gepäckeinheit-Controllers 235 in 3. Eine Workstation 702, die ein beliebiges geeignetes Computergerät sein kann, hostet den Hardwaredienst 704 und den Gepäckaufgabe-Controllerdienst 706. Die Workstation ist in einer bevorzugten Ausgestaltung als Common Use Terminal konfiguriert, mit einem Windows TM-Betriebssystem, wie oben erörtert. Der Gepäckaufgabe-Controllerdienst fungiert als Kommunikationsschicht zwischen dem Cloud-Dienst und dem Hardwaredienst über WebSocket 708 und der Hardware-Kommunikationsschicht 710. Sie verwaltet außerdem den Maschinenstatus und meldet sich beim Cloud-Dienst an. Der Hardwaredienst 704 verbindet sich mit einem IO-Server 710 und anderen Hardwareperipheriegeräten. Alternativ kann sich der Hardwaredienst mit einem Common Use Self-Service-Modul verbinden.
Der IO-Server 710 beinhaltet eine programmierbare logische Steuerung (PLC) 712, um eine oder mehrere Gepäckbandeinstellungen 714 und zu andere Hardware 716 zu steuern [sic]. Er ist entweder mit dem Gepäckabfertigungssystem des Flughafens oder direkt mit der Hardware verbunden.
8 zeigt die Architektur der Mobilgerätanwendung (App) 800. Die App hat zwei Hauptkomponenten, ein Software Development Kit SDK 802 und nutzergeschriebene Event-Handler 804. Die Mobilgerätarchitektur ist so ausgelegt, dass möglichst viel der entsprechenden Verarbeitung in den SDK 802 geschoben wird. Dies erleichtert es dem App-Entwickler, der eine bestimmte Fluggesellschaft oder ein externer Anbieter ist, den Dienst zu implementieren. Die entsprechende Verarbeitung beinhaltet den Arbeitsablauf sowie die Socket-Kommunikationen zwischen Mobilgerät und Cloud-Dienst.
Um dies zu erreichen, implementiert der App-Entwickler einen Satz dokumentierter Event-Listener oder -Handler 804. Diese Listener, oder Beobachter, werden registriert, um Rückrufe vom SDK anzunehmen, wobei der Handler zu diesem Zeitpunkt eine vordefinierte Logik ausführt, um ein bestimmtes Ergebnis zu erzielen. Es kann auch erforderlich sein, dass der Handler 804 den SDK 802 mit dem Ergebnis aufruft oder einfach den SDK 802 über die Beendung informiert. 8 zeigt die Interaktionen auf hoher Ebene zwischen der UX (User Experience Layer) 806, der Anwendungslogik 808 und dem SDK 802.

Die folgende Tabelle 1 enthält eine Liste der Event-Handler, die ein App-Entwickler implementiert. Tabelle 1

Operator	Beschreibung
no_session	Wird aufgerufen, wenn start_session fehlschlägt, weil die Gepäckaufgabeeinheit z.B. nicht verfügbar ist.
session_ready	Die Sitzung ist fertig, die App sollte den Nutzer darüber informieren, das Gepäck auf die Waage zu stellen. Dies ist auch ein Trigger für das Abrufen von Regeln der Fluggesellschaft, sofern nicht bereits in der App zwischengespeichert.
scale_result	Das an den Handler gelieferte Ergebnis der Waage. Im Ergebnis sind Regeln des Flughafens eingeschlossen. Wenn eine Prüfung der Fluggesellschafts- oder Flughafenregeln fehlschlägt, informiert der Handler den Passagier über Optionen.
bagtag_printed	Der Handler wird darüber informiert, dass das Gepäck zur Einführung bereit ist. Möglicherweise möchte die App zuerst mit dem Passagier kommunizieren, bevor induct_bag aufgerufen wird. Wenn das Gepäcketikett bereits ausgedruckt wurde (in diesem Fall würde print_bagtag nicht aufgerufen), würde die App direkt sdk induct_bag aufrufen.
bag_inducted	Handler führt Bereinigung durch und beendet die Sitzung.
end_session	Alternative zu bag_inducted.

Tabelle 2 enthält eine Liste von Methodenaufrufen an den SDK, die von der App implementiert werden. Tabelle 2

Methode	Beschreibung
start_session	Anforderung zum Starten einer Sitzung mit der Gepäckaufgabe. Aufruf erfolgt höchstwahrscheinlich infolge eines externen Triggers (z.B. Beacon, NFC) von einer nahegelegenen Gepäckaufgabeeinheit.
print_bagtag	Die App wird ihr DCS aufgerufen haben, um das Gepäck zu überprüfen. Das erfolgreiche Ergebnis (Bild, Pectab usw.) wird in diesen Aufruf einbezogen.
induct_bag	Anforderung zur Einführung des Gepäcks in das BHS-System.
print_receipt	Anforderung für den Ausdruck eines Gepäcketikettenbelegs.
end_session	Anforderung zum Beenden der Sitzung.

9 ist ein Prozessablaufdiagramm, das die Ende-zu-Ende-Interaktion zwischen dem SDK 802, den Komponenten der mobilen App der Fluggesellschaft und dem UX 806 zeigt. In dem Beispiel von 9 wurde das Gepäcketikett noch nicht ausgedruckt. Wenn das Gepäcketikett bereits ausgedruckt wurde, würde ein anderer Pfad genommen, um dies zu unterstützen.
10 zeigt die Ende-zu-Ende-Interaktionen zwischen den Hauptsystemakteuren, der App des Mobilgeräts, dem Cloud-Dienst und der Selbst-Gepäckaufgabeeinheit. Die Interaktion zwischen dem DCS (Departure Control System) und der App wird ebenfalls gezeigt. Ähnlich wie in dem Beispiel von 9, wurde das Gepäcketikett noch nicht ausgedruckt. Wenn das Gepäcketikett bereits ausgedruckt wurde, würde ein anderer Pfad genommen.
Sicherheit kann dadurch erreicht werden, dass sichergestellt wird, dass die gesamte Kommunikation für alle Sitzungen zwischen dem Mobilgerät und dem Cloud-Dienst und zwischen dem Cloud-Dienst und dem Gepäckaufgabeeinheit-Controller über sichere kryptografische Protokolle erfolgt. Das sichere WebSocket-Protokoll (WSS) wird derzeit bevorzugt. JSON Web Tokens (JWT) werden zur Authentifizierung und Autorisierung von Transaktionen über alle Schichten verwendet. JWT ist eine kompakte, URL-sichere Möglichkeit, Claims zwischen Parteien zu repräsentieren, indem sie als JSON-Objekte codiert werden, die digital signiert oder verschlüsselt werden können.
In der App des Mobilgeräts werden HMAC-(Hash-based Message Authentication Code)-Algorithmen zwischen dem Mobilgerät und dem Cloud-Dienst verwendet. Jeder Client (z.B. eine Fluggesellschaft) erhält eine einmalige Kombination aus Nutzer-ID und Passwort. Bei session_start werden diese Anmeldeinformationen an den Cloud-Dienst übergeben, der sie überprüft. Ein JWT wird mit einem privaten Schlüssel generiert. Das Mobilgerät ist für das Senden des JWT mit jeder Anforderung zuständig. Ein neues JWT kann jederzeit vom Cloud-Dienst generiert werden. Es liegt in der Verantwortung des Mobile Clients, das JWT bei jedem vom Cloud-Dienst empfangenen Ereignis zu sichern und die neueste Version bei nachfolgenden Anforderungen zurückzugeben.
HMAC-Algorithmen werden auch zwischen dem Gepäckaufgabeeinheit-Controller und dem Cloud-Dienst verwendet. Jeder Gepäckaufgabeeinheit-Controller ist mit einer/einem spezifischen ID, Nutzernamen und Passwort vorkonfiguriert. Beim ersten Start des Moduls meldet sich der Controller beim Cloud-Dienst an und übergibt seine spezifischen Anmeldeinformationen bei der Anmeldungsanforderung. Bei einer erfolgreichen Anmeldung enthält die Antwort des Cloud-Dienstes ein JWT, das in jeder Nachricht vom Controller an den Cloud-Dienst erforderlich sein wird.
Alternativ kann eine öffentliche/private RSA-Verschlüsselung verwendet werden.
Die API wickelt Interaktionen zwischen dem Cloud-Dienst 220 und dem Controller 235, zwischen dem Cloud-Dienst 220 und dem Mobilgerät 200 und zwischen dem Cloud-Dienst 220 und sowohl dem Controller als auch dem Mobilgerät (in einem Proxy-Modus) ab.
Jedes/jeder API-Ereignis oder -Vorgang wird in JSON-Nutzdaten (Payload) über eine sichere WebSocket-Verbindung (WSS) übermittelt und enthält einen Ereignis-Operator (op). Der Typ Operatortyp [sic] wird dazu verwendet, die Nachricht an einen geeigneten Handler weiterzuleiten.
Eine Sitzung zwischen der mobilen App und der Gepäckaufgabeeinheit wird während start_session initiiert, mit Hilfe von JsonWebToken propagiert und entweder mit einem Aufruf zum Beenden der Sitzung oder einem Timeout beendet. Der mobile App-Client ist dafür zuständig, das Token bei jedem Aufruf an den Cloud-Dienst weiterzureichen. Dies kann in der Verantwortung des SDK liegen, da nur dieser über die WebSocket-Verbindung mit dem Cloud-Dienst kommuniziert.
Cloud-Dienst - Mobilgerät
Ein Grundbefehl wird im folgenden Format gesendet:


 {
    "token": "<service-supplied token>“,
    "op": "<command>“,
 "txid": "<generated transaction id>“,
    "args": [{
            "key1": "val1“,
            "key2": "val2“,
            "key3": "val3“
    }]
 }

Dieses Format ist für alle API-Aufrufe gültig, mit Ausnahme von start_session, bei dem die Nutzer-ID und das Passwort der Anwendung gesendet werden. Das resultierende zurückgesendete Token zeigt eine erfolgreiche Authentifizierung und eine aktive Sitzung mit der Gepäckaufgabeeinheit an. Eine Transaktions-ID ist für den Anforderer optional. Wenn eine Transaktions-ID empfangen wird, wird es bevorzugt, aber es ist nicht zwingend notwendig, sie in Antwortnutzdaten zurückzuschicken.

reply

reply ist eine generische Antwort, die entweder vom Cloud-Dienst oder vom Mobilgerät gesendet wird. Die Nachricht enthält Informationen zu einer vorherigen Anforderung und (optional) die Transaktions-ID. Sie kann zum Bestätigen einer Anforderung ohne spezifische Antwortnutzdaten verwendet werden. Diese API ist bidirektional. Feldbeschreibung

Schlüssel	Wert	erforderlich
op	reply	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein
for	{die Anforderungs-API}	ja
result	in Ordnung oder fehlgeschlagen	ja
reason_code	Grund für Fehlschlag	kond

Beispiel


 {
     "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "reply“,
 "txid": "<generated transaction id>“,
   "args": [{
 "for": "mark_available“,
            "result": "ok“,
    }]
 }
 {
     "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "reply“,
 "txid": "<generated transaction id>“,
   "args": [{
 "for": "mark_available“,
            "result": "failed“,
            "reason_code": "NO_RESPONSE“
    }]
 }

Ursachen-Codes (noch festzulegen)

Code	Beschreibung
NO_RESPONSE	Der Dienst hat nicht innerhalb des Timeout-Zeitraums geantwortet
NOT_SUPPORTED	Generische Antwort auf eine Anforderung. Beispiele sind print bagtag (Gepäcketikett ausdrucken), print receipt (Beleg ausdrucken).

Start_session

start_session fordert an, dass eine Sitzung mit der ID-gekennzeichneten Gepäckaufgabestelle mit dem Client gestartet wird. Anmeldeinformationen werden in der Anforderung weitergeleitet. Jeder Client des Systems verfügt über einen spezifischen Satz von Anmeldeinformationen. Anmeldeinformationen sind nicht für jeden App-Nutzer spezifisch. Dies ist eine asynchrone Einweganforderung. Der Client erhält als Ergebnis dieses Aufrufs entweder ein session_ready- oder ein no_session-Ereignis. Die Richtung ist im Allgemeinen von der mobilen App zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	session_start	ja
txid	Transaktions-ID	nein
uid	Die vom Client bereitgestellte Nutzer-ID	ja
pwd	Das vom Client bereitgestellte Passwort	ja
bagdrop_id	Die beim Auffinden bereitgestellte ID der Gepäckaufgabeeinheit	ja

Beispiel


 {

 "op": "start_session“,
    "args": [{
       "uid": "myClientld“,
  "pwd": "myClientPwd“,
       "bagdrop_id": "ID105211“
    }]
 }

session_ready

session_ready ist eines von zwei Ereignissen, die sich aus einer start_session-Anforderung ergeben. Der Client wird darüber informiert, dass die Sitzung mit der Gepäckaufgabeeinheit gestartet wurde. Die Antwort beinhaltet Fähigkeiten der Gepäckaufgabeeinheit, z.B. Gepäcketikett- und Belegausdruck sind verfügbar oder nicht. Die Richtung ist im Allgemeinen vom Cloud-Dienst zur mobilen App.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	session_ready	ja
txid	Zurückgeschickte Transaktions-ID	nein
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
bag drop_id	Die ID der Gepäckaufgabeeinheit, mit der die Sitzung erfolgt	ja
config	Schlüssel-Wert-Paar konfigurierter Fähigkeiten der Gepäckaufgabeeinheit. Werte noch festzulegen.	nein

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "session_ready“,
    "args": [{
 "bagdrop_id": "ID105211“
   "config": [{
            "print_bagtag": true,
                   "print_receipt": true
            }],
 }]
 }

no_session

no_session ist eines von zwei Ereignissen, die sich aus einer start_session-Anforderung ergeben. Der Client wird darüber informiert, dass die Sitzung mit der Gepäckaufgabeeinheit nicht erfolgreich gestartet wurde. Ein Ursachencode wird an die Antwort angehängt. Die Richtung ist im Allgemeinen vom Cloud-Dienst zur mobilen App.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	no_session	ja
txid	Transaktions-ID	nein
reason_code	Gültiger Ursachencode (siehe Tabelle)	nein
bagdrop_id	Die ID der Gepäckaufgabeeinheit	ja

Beispiel


 {
    "op": "no_session“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "reason_code": "OUT_OF_SERVICE“
     }]
 }

Ursachencodes

Code	Beschreibung
OUT_OF_SERVlCE	Die Gepäckaufgabeeinheit ist außer Betrieb.
IN_USE	Die Gepäckaufgabeeinheit wird benutzt, es besteht bereits eine Sitzung.

end_session

end_session wird von einer der Parteien gesendet, um anzuzeigen, dass der Absender die Sitzung beenden möchte. Im Allgemeinen erfolgt der Versand von der mobilen App, damit beide Seiten bereinigt werden können, kann der Versand aus verschiedenen Gründen vom Cloud-Dienst aus erfolgen. Die Richtung ist im Allgemeinen von der mobilen App zum Cloud-Dienst. Versand kann vom Cloud-Dienst aus erfolgen.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	end_session	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein
bag drop_id	Die ID der Gepäckaufgabeeinheit, mit der die Sitzung erfolgt	ja
reason_code	Ursache für das Beenden der Sitzung	nein

Beispiel


 {
     "token“: "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "end_session“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "reason_code": "PROCESS_COMPLETE“
     }]
 }

Ursachencodes

Code	Beschreibung
PROCESS_COMPLETE	Beide Seiten sind der Ansicht, dass der Arbeitsablauf für das Check-in abgeschlossen ist
USER_REQUESTED	Der Nutzer (Passagier) hat den Prozessabbruch angefordert
UNIT_ERROR	Die Gepäckaufgabeeinheit hat einen Fehler oder eine Störung erfasst und kann nicht fortfahren
SESSION_TIMEOUT	Bei der Sitzung ist eine Zeitüberschreitung (Time-out) aufgetreten
BAGGAGE_ERROR	Es besteht ein Problem mit dem weiteren Einchecken dieses Gepäcks

scale_result

scale_result wird vom Cloud-Dienst gesendet, weitergeleitet von der Gepäckaufgabeeinheit, um die Ergebnisse des Wiegens des Gepäcks durch die Waage der Gepäckaufgabeeinheit zu übermitteln. Die Antwort enthält eine Reihe von Beschränkungen des Flughafens oder des Gepäckabfertigungssystems bzgl. Gewicht/Größe. Die Richtung ist vom Cloud-Dienst zur mobilen App.

Feldbeschreibung

Schlüssel	Wert	erforderlich
Op	scale result	ja
Token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein
bag drop_id	Die ID der Gepäckaufgabeeinheit, mit der die Sitzung erfolgt	ja
weight	Gewicht des Gepäcks	ja
dimension	Gepäckabmessungen	ja
weight_unit	Verwendete Einheit (K=Kilo, P=Pfund)	ja
dimension_unit	Verwendete Einheit (I=Zoll, M=Millimeter)	ja
bhs_rules	Anordnung von BHS-Regeln	nein
bhs_rules.weight	Gewichtsbeschränkung	nein
bhs_rules.dimension	Größenbeschränkung	nein
bhs_rules.weight_unit	Verwendete Einheit	kond
bhs_rules.dimension_unit	Verwendete Einheit	kond
result	Aufgezählte Empfehlung (siehe Abschnitt "Ursachencodes“)	ja

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "scale_result“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "weight": 20,
            "dimension": 10,
            "weight_unit": "K“,
            "dimension_unit": "I“,
            "bhs_rules": [{
                   "weight": 50,
                   "dimension": 20,
                   "weight_unit": "K“,
                   "dimension_unit": "I“
            }],
            "result": "PASSED“
    }]
 }

Ursachencodes

Code	Beschreibung
PASSED	Gewicht/Größe erfüllen alle Anforderungen
FAILED_WEIGHT_AIRLINE	Gewichtsbeschränkung der Fluggesellschaft nicht erfüllt
FAILED_WEIGHT_BHS	BHS-Gewichtsbeschränkung nicht erfüllt
FAILED_SIZE_AIRLINE	Größenbeschränkung der Fluggesellschaft nicht erfüllt
FAILED_SIZE_BHS	BHS-Größenbeschränkung nicht erfüllt
PLACE_IN_TUB_RETEST	Empfehlungscode, das Gepäck in eine Wanne zu legen und auf die Waage zu stellen

print_bagtag

print_bagtag wird vom Mobilgerät an den Cloud-Dienst gesendet. Da die Anforderung an die Gepäckaufgabeeinheit geschickt wird, wird sie als Proxy-Aufruf betrachtet. Die Anforderung enthält das auszudruckende Bild, z.B. im Pectab-Format. Die Richtung ist von der mobilen App zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	print_bagtag	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein
bag drop_id	Die ID der Gepäckaufgabeeinheit, mit der die Sitzung erfolgt	ja
image	Das auszudruckende Bild	ja
format	Das Bildformat (z.B. PECTAB)	ja

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "print_bagtag“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "image": "<image to print>“,
            "format": "PECTAB“
    }]
 }

Formate

Code	Beschreibung
PECTAB	Parametrische Tabelle

induct_bag

induct_bag_wird vom Mobilgerät an den Cloud-Dienst gesendet. Da die Anforderung an die Gepäckaufgabeeinheit geschickt wird, wird sie als Proxy-Aufruf betrachtet. Wie impliziert, ist die Anforderung für die Gepäckaufgabeeinheit, die Eingabe des Gepäcks in das Gepäckabfertigungssystem zu initiieren. Dieser Aufruf kann je nach Konfiguration optional sein. Bei einigen Konfigurationen kann es beispielsweise erforderlich sein, dass das Gepäck nach einem bestimmten Schritt automatisch eingeführt wird, insbesondere wenn das Gepäcketikett vorab ausgedruckt wurde und am Gepäck befestigt ist. Die Richtung ist von der mobilen App zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	induct_bag	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein
bag drop_id	Die ID der Gepäckaufgabeeinheit, mit der die Sitzung erfolgt	ja

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "induct_bag“,
    "args": [{
            "bagdrop_id": "ID105211“
    }]
 }

print_receipt

print_receipt wird vom Mobilgerät an den Cloud-Dienst gesendet. Da die Anforderung an die Gepäckaufgabeeinheit geschickt wird, wird sie als Proxy-Aufruf betrachtet. Die Anforderung enthält das auszudruckende Bild, z.B. im Pectab-Format.

Die Richtung ist von der mobilen App zum Cloud-Dienst. Eine Antwort ist zu erwarten.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	print_receipt	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein
bag drop_id	Die ID der Gepäckaufgabeeinheit, mit der die Sitzung erfolgt	ja
image	Das auszudruckende Bild	ja
format	Das Bildformat (z.B. PECTAB)	ja

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "print_receipt“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "image": "<image to print>“,
            "format": "PECTAB“
    }]
 }

Formate

Code	Beschreibung
PECTAB	Parametrische Tabelle

Cloud-Dienst - Controller

Ein Grundbefehl wird im folgenden Format gesendet:


 {
    "token": "<server-supplied token>“, 



    "op": "<command>“,
 "txid": "<generated transaction id>“,
    "args": [{
            "key1": "val1“,
            "key2": "val2“,
            "key3": "val3“
    }]
 }

Dieses Format ist für alle API-Aufrufe gültig, mit Ausnahme von register, bei dem die spezifische ID der Gepäckabfertigungseinheit, der Nutzername und das Passwort gesendet werden. Die Transaktions-ID ist für den Anforderer optional. Wenn eine Transaktions-ID empfangen wird, wird es bevorzugt, aber es ist nicht zwingend notwendig, sie in Antwortnutzdaten zurückzuschicken.

reply

reply ist eine generische Antwort, die entweder vom Cloud-Dienst oder vom Controller gesendet wird. Die Nachricht enthält Informationen zu einer vorherigen Anforderung und (optional) die Transaktions-ID. Sie kann zum Bestätigen einer Anforderung ohne spezifische Antwortnutzdaten verwendet werden. Diese API ist bidrektional.

Feldbeschreibung

Schlüssel	Wert	erforderlich
Op	reply	ja
Token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
Txid	Transaktions-ID	nein
For	{die Anforderungs-API}	ja
Result	in Ordnung oder fehlgeschlagen	ja
reason_code	Ursache für Misserfolg	kond

Beispiele

{
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "reply“,
 "txid": "<generated transaction id>“,
   "args": [{
 "for": "mark_available“,
            "result": "ok“,
    }]
 }
 {
     "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "reply“,
 "txid": "<generated transaction id>“,
   "args": [{
 "for": "mark_available“,
            "result": "failed“,
            "reason_code": "NO_RESPONSE“
   }]
}

Ursachencodes

Code	Beschreibung
NO_RESPONSE	Der Dienst hat nicht innerhalb des Timeout-Zeitraums geantwortet

register

registerwird vom Gepäckaufgabe-Controller (CUTE, CUSS-Modul oder andere) an den Cloud-Dienst gesendet. Dies ist eine einmalige Nachricht, die gesendet wird, wenn der Controller zum ersten Mal in Betrieb genommen wird. Der Controller empfängt eines von zwei Ereignissen infolge der Anmeldungsanforderung, registered (angemeldet) oder registration failed (Anmeldung fehlgeschlagen). Die Richtung ist vom Controller zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert
Op	register
bag drop_id	Die vorkonfigurierte ID der Einheit
username	Der vorkonfigurierte Nutzername der Einheit
password	Das vorkonfigurierte Passwort der Einheit

Beispiel


 {
    "op": "register“,
    "args": [{
            "bagdrop_id": „ID105211“,
            "username": "9e83a024-c374-4c3e-bd4e-ead758282513“,
            "password": "bfdfdcb7-4cd2-4b33-ae17-a11c45ae1802“
    }]
 }

registered

registeredwird vom Cloud-Dienst an den Controller gesendet. Die Nachricht zeigt an, dass die Anmeldung erfolgreich war und dass eine Sitzung gestartet wurde. Die Richtung ist vom Cloud-Dienst zum Controller.

Feldbeschreibung

Schlüssel	Wert
op	registered
token	Vom Dienst bereitgestelltes Sitzungs-Token

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "registered“
 }

registration_failed

registration_failed wird vom Cloud-Dienst an den Controller gesendet. Die Nachricht zeigt an, dass beim Anmelden des Controllers ein Problem aufgetreten ist. Die Richtung ist vom Cloud-Dienst zum Controller.

Feldbeschreibung

Schlüssel	Wert
Op	registration failed

Beispiel


 {
    "op": "registration_failed“,
    "reason_code": "BAD_CREDENTlALS“
 }

Ursachencodes

Code	Beschreibung
UNKOWN_UNlT_ID	Die Gepäckaufgabeeinheit wird in der Datenbank nicht gefunden (muss im Cloud-Dienst vorkonfiguriert werden)
BAD_CREDENTIALS	Nutzername und/oder Passwort falsch

deregister

deregisterwird vom Gepäckaufgabe-Controller (CUTE, CUSS-Modul oder andere) an den Cloud-Dienst gesendet. Die API-Anforderung informiert den Cloud-Dienst darüber, dass der Controller außer Betrieb genommen wurde und dass sein Eintrag aus dem System zu entfernen ist. Die Richtung ist vom Controller zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert
Op	deregister
Token	Vom Dienst bereitgestelltes Sitzungs-Token
bag drop_id	Die vorkonfigurierte ID der Einheit
Username	Der vorkonfigurierte Nutzername der Einheit
Password	Das vorkonfigurierte Passwort der Einheit

Beispiel


 {

  "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "register“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "username": "9e83a024-c374-4c3e-bd4e-ead758282513“,
            "password": "bfdfdcb7-4cd2-4b33-ae17-a11c45ae1802“
    }]
 }

mark_available

mark_available wird vom Gepäckaufgabe-Controller (CUTE, CUSS-Modul oder andere) an den Cloud-Dienst gesendet. Die API-Anforderung informiert den Cloud-Dienst darüber, dass der Controller jetzt für die Annahme von Sitzungen verfügbar ist. Wenn der Controller bereits verfügbar ist, wird die Anforderung vom Cloud-Dienst ignoriert. In allen Fällen wird eine Bestätigung zurückgesendet. Die Richtung ist vom Controller zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert
Op	mark available
Token	Vom Dienst bereitgestelltes Sitzungs-Token

Beispiel


 {

   "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "mark_available“,
 }

mark_unavailable

mark_available wird vom Gepäckaufgabe-Controller (CUTE, CUSS-Modul oder andere) an den Cloud-Dienst gesendet. Die API-Anforderung informiert den Cloud-Dienst darüber, dass der Controller für die Annahme von Sitzungen nicht verfügbar ist. Wenn der Controller bereits als nicht verfügbar kennzeichnet ist, dann wird die Anforderung vom Cloud-Dienst ignoriert. In allen Fällen wird eine Bestätigung zurückgesendet. Die Richtung ist vom Controller zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert
Op	mark unavailable
Token	Vom Dienst bereitgestelltes Sitzungs-Token

Beispiel


 {
   "token“: "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "mark_unavailable“,
    "args": [{
            "reason code": "MAINTENANCE“
    }]
 }

Ursachencodes

Code	Beschreibung
MAINTENANCE	Der Controller wird zur Wartung offline genommen
MODE_CHANGE	Die Gepäckaufgabeeinheit ändert den Modus, z.B. Umschaltung auf manuell

scale_result

scale_result wird von der Gepäckaufgabeeinheit an den Cloud-Dienst gesendet. Die Antwort enthält eine Reihe von Gewicht/Größe-Beschränkungen des Flughafens oder des Gepäckabfertigungssystems. Die Richtung ist vom Controller zum Cloud-Dienst.

Feldbeschreibung

Schlüssel	Wert
Op	scale result
Token	Vom Dienst bereitgestelltes Sitzungs-Token
Weight	Gewicht des Gepäcks
Dimension	Abmessungen des Gepäcks
weight_unit	Verwendete Einheit (K=Kilo, P=Pfund)
dimension_unit	Verwendete Einheit (I=Zoll, M=Millimeter)
bhs_rules	Anordnung von BHS-Regeln
bhs_rules.weight	Gewichtsbeschränkung
bhs_rules.dimension	Größenbeschränkung
bhs_rules.weight_unit	Verwendete Einheit
bhs_rules.dimension_unit	Verwendete Einheit
Result	Aufgezählte Empfehlung (siehe Abschnitt Ursachencodes)

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "scale_result“,
    "args": [{
            "weight": 20,
            "dimension": 10,
            "weight_unit": "K“,
            "dimension_unit": "I“,
            "bhs_rules": [{
                   "weight": 50,
                   "dimension": 20,
                   "weight_unit": "K“,
                   "dimension_unit": "I“
            }],
            "result": "PASSED“
    }]
 }

Ursachencodes

print_bagtag

print_bagtag wird vom Cloud-Dienst an den Controller gesendet. Da die Anforderung vom Mobilgerät ausging, wird sie als Proxy-Aufruf betrachtet. Die Anforderung enthält das auszudruckende Bild, z.B. im Pectab-Format. Die Richtung ist vom Cloud-Dienst zum Cloud-Controller. Eine Antwort vom Controller wird erwartet.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	print_bagtag	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
Transaction id	Transaktions-ID	nein
image	Das auszudruckende Bild	ja
format	Das Bildformat (z.B. PECTAB)	ja

Beispiel

{
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "print_bagtag“,
    "args": [{
            "bagdrop_id": "ID105211“,
            "image": "<image to print>“,
            "format": "PECTAB“
    }]
 }

Formate

Code	Beschreibung
PECTAB	Parametrische Tabelle

induct_bag

induct_bag wird vom Cloud-Dienst an den Controller gesendet. Da die Anforderung vom Mobilgerät ausging, wird sie als Proxy-Aufruf betrachtet. Wie impliziert, ist die Anforderung für die Gepäckaufgabeeinheit, die Eingabe des Gepäcks in das Gepäckabfertigungssystem zu initiieren. Dieser Aufruf kann je nach Konfiguration als optional angesehen werden. Bei einigen Konfigurationen kann es beispielsweise erforderlich sein, dass das Gepäck nach einem bestimmten Schritt automatisch eingeführt wird, insbesondere wenn das Gepäcketikett vorab ausgedruckt wurde und am Gepäck befestigt ist. Die Richtung ist vom Cloud-Dienst zum Controller. Eine Antwort wird erwartet.

Feldbeschreibung

Schlüssel	Wert	erforderlich
op	induct_bag	ja
token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
txid	Transaktions-ID	nein

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "induct_bag“
 }

print_receipt

print_receipt wird vom Cloud-Dienst an den Controller gesendet. Da die Anforderung vom Mobilgerät ausgeht, wird sie als Proxy-Aufruf betrachtet. Die Anforderung enthält das auszudruckende Bild, z.B. im Pectab-Format. Die Richtung ist von der mobilen App zum Cloud-Dienst. Eine Antwort wird erwartet.

Feldbeschreibung

Schlüssel	Wert	erforderlich
Op	print_receipt	ja
Token	Vom Dienst bereitgestelltes Sitzungs-Token	ja
Txid	Transaktions-ID	nein
Image	Das auszudruckende Bild	ja
Format	Das Bildformat (z.B. PECTAB)	ja

Beispiel


 {
    "token": "eyJpc3MiOiJ0b3B0YWwuY2....“,
    "op": "print_receipt“,
    "args": [{
            "image": "<image to print>“,
            "format": "PECTAB“
    }]
 }

Formate

Code	Beschreibung
PECTAB	Parametrische Tabelle

Wie beschrieben, umfasst das System eine Frontend-Anwendung, bei der es sich entweder um eine spezifische Anwendung oder um ein Modul auf der Website einer/eines Fluggesellschaft/Flughafens handelt. Über diese Schnittstelle bieten Fluggesellschaften und/oder Flughäfen ihren Passagieren den Gepäckaufgabedienst an. Eine Backend-Software-Engine hostet die Logik für den Selbst-Gepäckaufgabeprozess und steuert den Prozess. Eine API-befähigte die Kommunikation zwischen der App, der Backend-Software-Engine und der Gepäckabfertigungssystemhardware und den Selbst-Gepäckaufgabeperipheriegeräten wie Drucker und Waage. Andere schnelle Peripheriegeräte können automatisierte Lesegeräte und Gepäckbeurteilungsgeräte beinhalten, zum Beispiel kann die BHS-Hardware neue oder vorhandene Förderbänder und Waagen umfassen.

Es können auch Ausgestaltungen der Erfindung verwendet werden, bei denen vom Passagier ausgedruckte Bordkarten anstelle von mobilen Bordkarten zu verwenden sind, und mit jeder Art von Gepäcketikett, einschließlich temporärer und permanenter Gepäcketiketten, Gepäckabfertigungssysteme ohne Etikett und selbst ausgedruckter Gepäcketiketten.

Ausgestaltungen der Erfindung haben viele Vorteile. Die Interaktion zwischen dem Passagier und dem Selbstbedienungsstandort wird für den Passagier einfacher und ermöglicht den Betreibern die Reduzierung von Gemeinkosten, wie beispielsweise die Personalbesetzung herkömmlicher Check-in- und anderer Einrichtungen, während nur relativ geringe Modifikationen an vorhandenen Check-in-Systemen und anderen Systemen wie Passkontrollgates usw. erforderlich sind. Aus Sicht des Passagiers bietet sie Komfort und Zeitersparnisse, wodurch die Flughafenerfahrung des Passagiers verbessert wird.

Obwohl in Bezug auf ein Gepäckaufgabesystem beschrieben, können Ausgestaltungen der Erfindung in Verbindung mit anderen Selbstbedienungsfunktionen auf Flughäfen, wie eGates, verwendet werden, die elektronische Pass- und/oder Bordkartenkontrollen, letzte Einstiegskontrollen und Kiosks zum Einchecken und/oder Erstellen und Ausdrucken von Gepäcketiketten bereitstellen. In einer Ausgestaltung verbindet sich das Mobilgerät des Passagiers bei der Ankunft auf einem Flughafen mit einem Gepäckabfertigungssystem, der Passagier wird zum richtigen Karussell geleitet und auch sein Gepäck wird zu diesem Karussell geleitet.

Ausgestaltungen der Erfindung können mit ähnlichen Diensten in anderen Häfen, Eisenbahnen von Massenverkehrsorten sowie an Veranstaltungsorten, auf Sportplätzen usw. verwendet werden, wo Einzelpersonen mit Diensten wie Ticketkontrollen interagieren.

Ausgestaltungen der Erfindung können auch für Passagiere mit bestimmten Behinderungen vorteilhaft sein. Durch die Nutzung der Audio-Fähigkeiten eines Smart-Geräts kann zum Beispiel die Erfahrung eines blinden oder sehbehinderten Passagiers mit der Gepäckaufgabe, Passkontrolle und anderen Flughafenfunktionen erheblich verbessert werden. Ausgestaltungen der Erfindung ermöglichen auch die Integration von Passagierinformationen auf dem Smart-Gerät mit Zahlungsdiensten, die eine Fluggesellschaft oder ein Flughafen möglicherweise bereits über vorhandene mobile Anwendungen anbietet.

ZITATE ENTHALTEN IN DER BESCHREIBUNG

Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.

Zitierte Patentliteratur

WO 2013/117723 [0018, 0037]

Claims

System zum Erleichtern der Interaktion zwischen einem Ticketinhaber und einer mit dem Ticket zusammenhängenden Selbstbedienungsfunktion, das Folgendes umfasst: eine Selbstbedienungsfunktion; ein Mobilgerät, auf dem Informationen über das Ticket gespeichert sind; wenigstens ein Geolocation-Gerät; wobei das Mobilgerät so konfiguriert ist, dass es das Geolocation-Gerät an einem Standort in der Nähe einer Selbstbedienungsfunktion erfasst, und wenigstens einen Server, auf dem Computersoftware gespeichert ist, um die folgenden Schritte auszuführen: Aktivieren einer Anwendung auf dem Mobilgerät beim Erfassen des Geolocation-Geräts in der Nähe des Standortes durch das Mobilgerät, wobei die Anwendung mit der Selbstbedienungsfunktion zusammenhängt; und Übermitteln von Informationen über die Selbstbedienungsfunktion, einschließlich Richtungsangaben, über die Anwendung an das Mobilgerät.
System nach Anspruch 1, wobei sich das Ticket auf eine Passagierreise bezieht und eine Passagier- und Reiseidentifikation enthält.
System nach Anspruch 1, wobei die Ticketinformationen eine Bordkarte beinhalten.
System nach Anspruch 3, wobei das wenigstens eine Geolocation-Gerät ein Bluetooth-Beacon ist.
System nach Anspruch 1, wobei die Anwendung die auf dem Mobilgerät gespeicherten Ticketinformationen abfragt und die Ticketinformationen an den Server übermittelt.
System nach Anspruch 5, wobei der Server als Reaktion auf den Empfang der Ticketinformationen der Anwendung Informationen über die Selbstbedienungsfunktion liefert, um diese dem Nutzer des Mobilgeräts zu präsentieren.
System nach Anspruch 1, das ein Abflugkontrollsystem umfasst, wobei die Selbstbedienungsfunktion eine Gepäckaufgabestelle ist, die ein Gepäckabfertigungssystem und einen Gepäckaufgabe-Controller umfasst, und die Informationen über das Ticket eine Bordkarte beinhalten, wobei Passagierinformationen in der Bordkarte an ein Abflugkontrollsystem übermittelt werden.
System nach Anspruch 7, wobei das Abflugkontrollsystem so ausgelegt ist, dass es ermittelt, ob mit der Bordkarte zusammenhängendes Gepäck für eine Gepäckaufgabe berechtigt ist, und die Berechtigung an das Mobilgerät übermittelt.
System nach Anspruch 8, wobei das Gepäckabfertigungssystem eine Waage zum Wiegen von Gepäck beim Abgeben an der Gepäckaufgabestelle umfasst, um zu ermitteln, ob das Gewicht ein zulässiges Gewicht überschreitet, und wenn das Gewicht ein zulässiges Gewicht überschreitet, dann wird die Zahlung einer Übergepäckgebühr über die Anwendung veranlasst.
System nach Anspruch 8, wobei das Gepäckabfertigungssystem einen Drucker zum Ausdrucken eines Gepäcketiketts umfasst und der Gepäckaufgabe-Controller so konfiguriert ist, dass er Anweisungen zum Befestigen des Gepäcketiketts am Gepäck übermittelt, um sie dem Nutzer des Mobilgeräts über die Anwendung zu präsentieren.
System nach Anspruch 1, wobei das System so konfiguriert ist, dass es beim Empfang von Gepäck durch die Gepäckaufgabestelle Informationen über das Anbordgehen (Boarding) und eine Wegbeschreibung zu einem Abfluggate an die Anwendung übermittelt.