RU2779291C2 - Systems and methods for interactions between ticket holders and self-service functions - Google Patents

Abstract

FIELD: wireless communication.

SUBSTANCE: invention relates to the field of services specifically intended for wireless communication networks, namely to automated interaction with passenger services, for example luggage processing. Ticket information, for example an airline boarding pass, can be stored on a mobile device. The presence of a geolocation device, for example Bluetooth beacon, is detected by the mobile device at a departure site, for example an airport. When the mobile device detects an additional geolocation device, when the mobile device is near a self-service function, an application is launched on the mobile device, which directs the mobile device to the self-service function, for example a luggage drop-off counter, and instructs a user of the mobile device on how to use the self-service function.

EFFECT: provision of simplification of a procedure of interaction between mobile devices and self-service functions due to elimination of the need for prior knowledge of a certain self-service function by a mobile device.

25 cl, 10 dwg

Description

The invention relates to automated interactions with passenger services, such as baggage handling. In particular, but not exclusively, this applies to baggage handling at airports, ports, vocals, other transport hubs, public places, stadiums and arenas.

Checking in luggage at the airport can be time-consuming and tiring for passengers. When there is a large influx of passengers, long queues can form partly due to the slow, manual check-in process, which involves ground staff printing baggage receipts for each piece of baggage and attaching these receipts to the baggage.

The baggage check-in process incurs a high cost for airports and airlines in terms of ongoing operating and maintenance costs for baggage check generation equipment, plus personnel costs associated with the check-in process and maintenance.

In recent years, some steps have been taken to reduce these costs and simplify the check-in process and reduce queuing times for passengers. For example, many airlines provide online check-in services that require passengers arriving at the airport to check in their luggage. More recently, some airlines have introduced semi-automated self-service baggage drop counters, where a baggage receipt is generated by scanning a boarding pass and joined by the passenger. Some airlines are taking a hybrid approach, using combined installations that allow for self-service and ground handler assistance. While these measures mitigate some of the problems discussed above, they all require some kind of interaction between the passenger and the ground handler, kiosk, or other computerized equipment. These solutions themselves create additional problems, as they require significant changes to airport check-in counters and significant investments in self-service equipment. Both directions are costly and difficult to operate.

In addition to the aforementioned problems, there is a growing awareness of the needs of passengers with disabilities. In many countries, legislation guarantees adequate assistance to passengers with disabilities and reduced mobility at airports. An example is EU directive 1107/2006, which states that check-in and check-in and baggage drop desks are areas where an airport is responsible for assisting passengers with disabilities and reduced mobility. Current or future legislation requires access to any automated or self-service baggage check-in solution and may require, for example, a specific maximum tactile access height for wheelchair users and specific additional controls for visually impaired passengers.

The invention aims to solve and mitigate these problems.

According to one aspect of the invention, a method is provided for facilitating interaction between a ticket holder and a self-service function associated with a ticket, comprising the steps of: detecting proximity to a self-service function by a mobile device, wherein information related to the ticket is stored on the mobile device and the self-service function is associated with the ticket; after detecting, using the mobile device, the proximity to the position, activating the application on the mobile device, and the application is associated with a self-service function; and transmitting to the mobile device, via the application, information about the self-service function, including referral information.

The invention also provides a system for facilitating interaction between a ticket holder and a ticket-related self-service function, comprising: a self-service function; a mobile device, wherein information relating to the ticket is stored on the mobile device; at least a geolocation device; moreover, the mobile device is configured to detect a geolocation device in a position near the self-service function, and at least one server that stores computer software for performing the steps: if the mobile device detects a geolocation device near the position, activating the application on the mobile device, and the application associated with the self-service function; and transmitting to the mobile device, via the application, information about the self-service function, including referral information.

The second aspect of the invention provides a method for facilitating interaction between a ticket holder and a ticket-related self-service function, comprising the steps of: at a position near the ticket-related self-service function, activating an application on a mobile device, wherein the application is associated with the self-service function, and information is stored on the mobile device relating to the ticket; and transmitting to the mobile device, via the application, information about the self-service function, including referral information.

Embodiments of the invention may have the advantage of simplifying the interaction between ticket holders and self-service functions. In one preferred embodiment, the self-service function is a baggage claim system, for example for use at an airport. Embodiments of the invention may have the advantage of simplifying interactions with the baggage drop desk, and enabling airlines or other service providers to reduce the amount of human interaction required in baggage check-in and other self-service processes and thus reduce cost and expense.

In one embodiment of the invention, the ticket is associated with the passenger's flight and includes identification of the passenger and the flight. The ticket information may contain a boarding pass. In one embodiment, the presence of a mobile device at a location can be detected using a geolocation device, such as a Bluetooth beacon.

In one embodiment, the application requests ticket information stored on the mobile device and transmits the ticket information to a remote server. The remote server, upon receiving the ticket information ticket, reports the information related to the self-service function to the application for presentation to the user of the mobile device.

In one embodiment, the self-service function is a baggage claim and the ticket related information is a boarding pass, the passenger information on the boarding pass is passed to the departure management system. The departure management system may determine whether the baggage associated with the boarding pass is eligible for baggage check-in and communicates the suitability to the mobile device.

In one embodiment of the invention, after baggage has been placed at the baggage drop counter, the baggage is weighed and a determination is made if the weight exceeds the permitted weight, and if the weight exceeds the permitted weight, payment of the excess baggage penalty through the application is charged.

In one embodiment, the baggage receipt is printed at the baggage drop counter and instructions for attaching the baggage receipt to the baggage are transmitted for presentation to the user on a mobile device via an application.

In one embodiment, after checking in at the baggage drop counter, the boarding information and the route to the boarding gate are transmitted to the application.

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

fig. 1 is a diagram of an embodiment of the invention;

fig. 2 is a flowchart showing steps according to an embodiment of the invention;

fig. 3 is a diagram of a system in which the invention is implemented;

fig. 4 - logical architecture of the system;

fig. 5 - logical architecture of the cloud service;

fig. 6 is a class diagram showing a service model indicating available interfaces;

fig. 7 - diagram of the luggage rack controller;

fig. 8 - high-level interactions occurring in the application for a mobile device;

fig. 9 is a process flow diagram for a mobile application; and

fig. 10 is a process flow diagram for the overall system.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the examples below, the baggage drop sequence is initiated from the passenger's smartphone, tablet, laptop or similar mobile computing device. Geolocation technology, such as Bluetooth beacons or other position sensors, is used to enable an application on a mobile device to detect when it is in the vicinity of a given beacon or other device. However, automatic position detection is not essential to the invention. Although described in relation to baggage check-in, embodiments of the invention may also be used in connection with other passenger interactions, such as passenger processing kiosks for printing baggage checks, boarding passes, scanning passports and other features, mobile payment interactions via a passenger's smartphone, or other device, and interactions with other airport facilities, including, but not limited to, self-service checkpoints and checkpoints, such as automated checkpoints or passport control turnstiles. Embodiments are described with specific reference to airports, but the application of the invention extends to any travel infrastructure where a passenger is required to check in or check in baggage, including ports and stations. Embodiments of the invention can also be used for mass booking events to help refer visitors, such as sporting events and entertainment such as concerts and festivals.

In the embodiments shown in the drawings relating specifically to an airport solution, positioning technology, such as Bluetooth beacons distributed around the airport, is used to enable a passenger's mobile device, such as a smartphone, tablet, laptop, or other device, to determine the presence of this beacon. Any other indoor or outdoor geolocation technology can be used to allow the device to determine its relative position. However, it is clear that while preferred, Bluetooth beacons or other positioning technology is not essential to the invention. The passenger downloads the baggage drop application on their mobile device. This application can be a unique baggage drop application or a baggage drop module of an airline or airport application. The mobile device 10 detects the presence of positioning devices, for example, when it enters an airport and passes near the first beacon 12. As the passenger passes through the airport to the baggage drop area, the second beacon 14 is detected by the device 10, which initiates the baggage drop application on the device. Detection by the passenger's mobile device of the first beacon at the entrance to the airport is optional, but preferred, since the device's detection of the beacons allows interaction with other services provided at the airport.

The use of beacon detection to track the movement of a passenger through an airport or similar facility is described in WO2013117723.

Once triggered, the app either requests the passenger's booking details from their mobile boarding pass stored on their phone, such as using Apple® Wallet or similar applications, or, in the absence of a stored boarding pass, asks the passenger to scan their printed boarding pass either using their camera. device or scanner provided at the baggage drop desk.

When a mobile boarding pass is stored on the device, the application will identify from the stored data associated with the passenger whether the passenger has checked in baggage, and if so, how many seats. If baggage is checked in, the application displays instructions to the passenger on how to carry out the baggage drop-off process. If no checked baggage is found, the app may prompt the passenger to make changes to their booking in order to be able to check in.

When interacting with another self-service function, the process behaves in a similar way. For example, when the feature is a self-service passport control application, which, again, is a unique application or application module of an airline or airport, detects the presence of the device in the passport control area and provides instructions to the user through the display device where to go and how to use the passport scanner.

Thus, in one embodiment, the system uses a passenger's smartphone or other mobile device and optionally any indoor or outdoor geolocation technology, such as Bluetooth beacons or other types of sensors and mapping applications, to automate the baggage check-in process or any another passenger process that requires interaction with the system at the airport or other related locations. In the vicinity of a baggage drop-off area, kiosk or passenger handling facility, security checkpoint or electronic turnstile, a mobile application on the passenger's smartphone or other mobile device is activated and the passenger and their booking details are identified. The passenger's device "pairs" with the baggage drop counter and all additional baggage drop control instructions are performed electronically/wirelessly via a smartphone or mobile device. The system comprises a mobile application, for example on a smartphone, a processing unit (controller) connected to the baggage drop-off counter, and an API cloud service through which the interaction between the mobile application and the baggage drop-off counter takes place, as described in more detail below.

While the embodiment described below uses Bluetooth as the initiating mechanism for pairing the mobile device with the luggage system, other methods are possible. For example, another type of automatic pairing, such as other Near Field Communication (NFC), WIFI or BLE beacons, or a manual method, such as a QR or other barcode that is scanned by the owner of the mobile device to launch an application or voice activation command, such as Amazon Alexa ^T.M. In the case of a barcode, the passenger can scan the 2-D barcode on a sticker at the check-in desk or take a photo of the code in a known manner. To address security issues, the barcode can be created using electronic ink and changed regularly. For clarity, communication between the mobile device and the baggage handling system is via an API service as described below using WIFI or other communication protocol.

The process with regard to baggage check-in is shown in more detail in FIG. 2 from the passenger's point of view. The process is generally denoted 100. At step 102, the passenger checks in online via their smartphone or other mobile device. As mentioned above, this can be done through a special application or through the check-in module on the airline's website. As part of the check-in process, a mobile boarding pass is generated that includes various passenger information, including the passenger ID and baggage allowance. The boarding pass is stored in a suitable storage location on the mobile device. An example of a suitable storage location is in the Apple Wallet app on Apple IOS devices or Google PassWallet on Android devices. Other storage options are also possible.

Each airline can choose to offer a two-step self-check-in process or a one-step process. In FIG. 2 is an example of a two-step process in which, at step 106, the passenger prints a baggage check and attaches it to their baggage. He can print it at home or at work or at a kiosk at the airport. The kiosk may be designed to print baggage receipts or provide another function such as online check-in. In the one-step process, step 106 is omitted and the passenger proceeds directly to baggage check-in.

At the entrance to the airport, the passenger's mobile device detects a beacon located near the entrance to the airport (12, Fig. 1). The mobile device detects the second beacon again when the passenger is in the vicinity of this second beacon 14 at the entrance to the baggage drop area of the airport. This detection demonstrates the intent in the user's mobile device application. An API call is made to get the details of the check-in represented by the beacon, and a session request to the cloud service is made using the check-in id from the API call and the mobile device id. This is described in more detail below.

As an alternative to messaging via the passenger's smart device, the relevant section of the airport may be provided with an identification kit instructing passengers to open a baggage drop application or visit a website. There may be a QR code or other barcode that, when scanned by the device's camera, will automatically open an app or website, or initiate a baggage check-in process if that app is not already open. This option gives the airline the advantage of knowing which SBD a given passenger is using, as the barcode can include a unique code that broadly corresponds to the location at the airport. This helps the airline to control usage and manage passenger traffic.

In one preferred embodiment, messaging to passenger devices and an ID kit are used to improve reliability and to ensure that passengers can use the system, for example, even forgetting to turn on Bluetooth.

In one embodiment, the identification kit includes Braille instructions for blind or visually impaired passengers, and the application may include voice instructions.

Upon opening the baggage drop application, the passenger proceeds to the designated baggage drop counter at step 110. The application may instruct the passenger to present themselves to a specific one or group of self-service baggage drop terminals. At this stage, the application or baggage drop module retrieves the boarding pass data stored on the device. This may include baggage allowance information or information that can be retrieved using the passenger identification from the airline's Departure Control System (DCS). A suitability check may be performed, for example, to determine whether it is too early or too late for a passenger to check in their baggage, or if a mobile device check-in option is available for their particular flight.

At step 112, the passenger appears in the baggage drop area and the application displays a message asking the baggage to be placed on the baggage belt or stationary scale. As with traditional baggage check-in, baggage is weighed to check if it fits within the allowed weight limit. The weight is passed back to the application, which can check the accepted weight against the allowed limit, which is either stored as part of the boarding pass or retrieved from the DCS.

If baggage fails the weight check, the passenger is asked to pay for excess baggage. This can be done with a credit or debit card previously stored in the airline's app, or through a regular online transaction. The transaction is of the "card missing" type and is unique to each airline, each of which charges its own overweight penalties.

Based on the fact that the weight is within the allowed limits, or that the overweight has been paid, at step 114 the baggage receipt is printed. In the case of the above two-step process, this step is not required because the baggage check already exists. The application then displays information about the passenger regarding how to attach the baggage check to the baggage.

After attaching the baggage check, the LPC barcode can be read using the device's camera. This is useful when baggage is not delivered to the specified destination or when the passenger does not show up for the flight or there is a claim for compensation. In one embodiment, a 3D scan of the baggage may be performed to verify that the baggage fits within the permitted dimensions and is designed strictly in accordance with the requirements of transportation.

At step 116, the passenger verification step is performed. Because the application has access to the DCS airline, it can extract the PNR (passenger name record) and compare the data on the receipt with this record. The application may direct the passenger to take a photo or use one or more other forms of verification offered by the mobile device, such as biometric identification or fingerprint recognition. The data collected in this way may be stored for future reference. Passenger checks can be carried out before the baggage receipts are printed.

At step 118, if the passenger's identity is verified, the baggage is accepted by the Departure Control System (DCS) and the packing tag is displayed to the passenger on the smartphone. This shortcut is stored in the application and/or on the mobile device. The baggage is then handed over to the baggage handling system, this step being carried out automatically or with the help of an airline employee.

Once the baggage has been handed over, the application may provide the passenger with additional information regarding their flight, such as, but not limited to, boarding time and boarding gate number. At this point, the application may automatically close, or may return the passenger to a navigation application such as disclosed in WO2013/117723, which directs the passenger to the boarding gate using short range beacons distributed throughout the airport.

In FIG. 3 shows the important hardware components used in the above process. An application is downloaded to the passenger's mobile device, designated 200, which consists of the logic for checking in the passenger's baggage. As mentioned above, the application may be, for example, an airline application module or a standalone application. The device 200 communicates with the airline's departure control system (DCS) 210 and a cloud service 220 that contains a set of APIs and associated logic. The baggage check-in system includes a baggage check-in counter 230 and a controller 235, which can be either a hardware controller associated with a baggage check-in counter (BCIU) 230 that contains software and/or firmware for communicating with the BCIU 230, or the CUTE/CUSS module, which performs the same functions. CUTE (Common Use Terminal Equipment) and CUSS (Common Use Self Service). CUTE and CUSS are well-known standards that allow multiple airlines or service companies to use the equipment. The controller also communicates with the cloud service 220. Although not required, a beacon 240 for automatic identification of the baggage drop area is provided, which communicates with the mobile device via Bluetooth ^TM or other communication protocol. In the case of beacons, the mobile device 200 also communicates with the beacon registry 250 to retrieve the check-in identifier. Even if beacons are used, the beacon registry 250 may not be required since the service is maintained by the cloud service 220.

In FIG. 4 shows the logical architecture of the system. In general, the cloud service (220 in FIG. 3) acts as an intermediary between the mobile device 200 and the baggage rack controller. The service exposes a single connection endpoint to the mobile device, alleviates any networking complexity, allows "over the air" protocols for many devices, schedules the availability of the baggage claim service, and provides an abstraction for any controller-specific messaging. A WebSocket connection 400 is established between the mobile device 200 and the cloud service and between the cloud service and the baggage rack controller. The last connection will be established by the baggage rack controller and maintained for the life of the controller. The controller is designed to ensure that the connection is established. If the connection is interrupted, the controller must re-establish the connection. The cloud service will treat the baggage drop desk as unavailable if the WebSocket connection is not active. Although websocket is described, other asynchronous or bisynchronous methods may be used.

Likewise, mobile device 200 is responsible for establishing a connection with cloud service 220 and for maintaining the connection for the duration of the session. As with the controller, service discovery from each mobile device simplifies the process.

The end-to-end session is displayed by associating the id of the mobile device and the baggage rack controller.

The logical architecture of cloud service 220 is shown in FIG. 5. A cloud service is formed by a set of microservices based on a distributed reactive platform. Each service endpoint registers an address to which events, based on the (op) statement , will be routed through the event bus. The WebSocket service is an external pairing service that communicates directly with controllers and mobile devices.

In FIG. 6 is a class diagram 600 showing a service model that reflects the available interfaces and is coarser in nature than the platform service model. It includes the following services:

BagDropSvc 602

This service contains the interfaces used in the session between the mobile device and the controller. Some interfaces can "pass through" to additional services, such as a session, but most, if not all, of the underlying interfaces will be managed here. These include baggage entry, baggage receipt printing, weighing, and more.

BagDropMngmtSvc 604

this service manages controller dispatching. When the controller is first started, a registration request is sent. The service interacts withConfigurationSvc606 to authenticate the request and store the new configuration for the controller. It also manages the availability status of the controller.

TimerSvc 608

A session has a predetermined period of inactivity. TimerSvc regulates it and interacts with sessionSvc to manage session state in general.

ConfigurationSvc 606

As stated, this service interacts with BagDropMngmtSvc to register and unregister controllers. In addition, each controller can have unique attributes that can be uploaded and saved. Controllers can be enabled and disabled via the interface.

SessionSvc 610

This service manages the session between the mobile device and the controller. It interacts with AuthSvc to authenticate users on start_session and to authenticate tokens, and with timerSvc to invalidate a session after a period of inactivity.

AuthSvc 612

This service interface acts as the front end of one or more authentication and authorization implementations. The initial implementation will provide a local user id/password authentication scheme, and JWT (JSON Web Tokens) for authorization.

In FIG. 7 shows the logical architecture of the baggage rack controller 235 shown in FIG. 3. Workstation 702, which may be any suitable computing device, implements a hardware service 704 and a baggage drop controller service 706. The workstation, in the preferred embodiment, is implemented as a public terminal, for example, running under the Windows ^TM operating system, as discussed above. The baggage drop controller service acts as a communication layer between the cloud service and the hardware service via WebSocket 708 and the hardware communication layer 710. It also manages the state of the machine and registers with the cloud service. The hardware service 704 connects to the IO server 710 and other peripheral equipment. Alternatively, the hardware service may connect to a shared self-service module.

The IO server 710 includes a PLC 712 for controlling one or more baggage belts 714 and other equipment 716. It is connected either to the airport's baggage handling system or directly to the equipment.

In FIG. 8 shows the architecture of an application 800 for a mobile device (application). The application has two main components, the SDK 802 and user-written event handlers 804 . The architecture of the mobile device is intended to port the applicable processing to the SDK 802 as much as possible. This makes it easier for the application developer, who is a specific airline or external provider, to implement the service. Applicable processing includes the flow of operations as well as socket communication between the mobile device and the cloud service.

To this end, the application developer implements a set of documented 804 event listeners or handlers. These listeners, or observers, are registered to receive callbacks from the SDK, at which time the handler executes the logic predefined to achieve a specific result. The handler 804 may also need to call the SDK 802 with a result, or simply notify the SDK 802 of its completion. In FIG. 8 shows the high level interactions between the UX (user experience) layer 806, the application logic 808, and the SDK 802.

Table 1 below lists the event handlers implemented by the application developer.

Operator Description no_session Called when start_session fails, such as when the baggage drop-off desk is not available session_ready The session is ready, the application asks the user to place the luggage on the scale. It also invokes the airline's rules if they are not already in the application. scale_result The scale readings are delivered to the handler. The rules of the airport are attached to them. In case of violation of the rules of the airline or airport, the handler offers the passenger options. bagtag_printed The handler is informed that the luggage can be collected. The application can contact the passenger before calling induct_bag. If the baggage receipt has already been printed (in this case, print_bagtag is not called), the application immediately calls sdk induct_bag) bag_inducted The handler is cleared and ends the session. end_session Alternative to bag_inducted

Table 1

Table 2 lists the methods that access the sdk that are implemented by the application.

Method Description start_session Request to initiate a communication session with the baggage drop desk. Most likely caused by an external trigger (eg beacon, NFC) from the nearest baggage drop. print_bagtag The app needs to call its DCS to check in the baggage. The successful result (image, PECTAB, etc.) is included in this call. induct_bag Request to enter baggage into the BHS system. print_receipt Request to print a ticket for a baggage check. end_session Request to end this session.

table 2

In FIG. 9 is a flowchart showing the end-to-end interaction between SDK 802, airline mobile application components, and UX 806. In the example shown in FIG. 9, the baggage receipt has not yet been printed. If the baggage receipt had already been printed, another route would have been chosen to support this.

In FIG. 10 shows the end-to-end interactions between the main actors of the system, the mobile device application, the cloud service, and the self-check-in desk. Also shown is the DCS (Departure Control System) interacting with the application. Similar to the example in FIG. 9, the baggage receipt has not yet been printed. If the baggage receipt had already been printed, another route would have been chosen.

Security can be achieved by ensuring that all transmissions, for all sessions, between the mobile device and the cloud service, and between the cloud service and the baggage claim controller, are made according to secure cryptographic protocols. The secure WebSocket (WSS) protocol is currently preferred. JSON Web Tokens (JWT) are used to authenticate and authorize transactions between all levels. JWT is a compact, URL-safe means of representing claims between parties by encoding them as JSON objects that can be digitally signed or encrypted.

In the mobile device application, HMAC (Hash Function Based Message Authentication Code) algorithms are used between the mobile device and the cloud service. Each customer (such as an airline) accepts a single combination of user ID and password. On session_start, these credentials are passed to the cloud service, which authenticates them. The JWT is generated using a private key. The mobile device is responsible for sending the JWT with every request. A new JWT can be generated at any time by the cloud service. The mobile client is responsible for storing the JWT for each event received from the cloud service and returning the latest version on subsequent requests.

HMAC algorithms are also used between the baggage drop controller and the cloud service. Each baggage drop controller is pre-configured with a unique id, username and password. The first time you run the module, the controller registers with the cloud service by passing in its unique credentials with a registration request. If the registration is successful, the cloud service response contains the JWT that will be required in every message from the controller to the cloud service.

Alternatively, RSA public/private key encryption may be used.

The API manages interactions between cloud service 220 and controller 235, between cloud service 220 and mobile device 200, and between cloud service 220 and both controller and mobile device (in proxy mode).

Each event or API operation is carried in a JSON payload over a secure WebSocket (WSS) connection and contains an event operator (op). The operator type is used to route the message to the appropriate handler.

The session between the mobile application and the baggage drop-off desk is initiated during start_session, lasts using a JsonWebToken, and ends either with the end or timeout of the session call. The mobile application client is responsible for passing the token with every call made to the cloud service. This can be the responsibility of the SDK, as it is the only one that communicates with the cloud service over a WebSocket connection.

1. Cloud service - mobile device

The main command is sent in the following format:

This format is suitable for all API calls except for start_session, which will send the application's user ID and password. As a result, the returned token indicates successful authentication and an active session with the baggage drop desk. The transaction ID is optional for the requester. If a transaction ID is received, it is preferred, but not required, to return it in the response payload.

reply

reply is a generic response sent from either a cloud service or a mobile device. The message carries information related to the previous request and an (optional) transaction ID. It can be used to acknowledge a request in the absence of a specific response payload. This API is bi-directional.

Description of fields

Key Meaning Required op reply Yes token Session token provided by the service Yes txid transaction ID No for {api request} Yes result successful or unsuccessful Yes reason_code reason for failure conditionally

Example

Reason codes (tbd)

The code Description NO_RESPONSE The service did not respond within the waiting period NOT_SUPPORTED Universal response to a query. Examples include baggage receipt printing, ticket printing.

Start_session

start_session requests that a session with the baggage drop-off counter identified by id be started with the client. The credentials are passed in the request. Each client of the system will have a unique set of credentials. Credentials are not unique for each application user. This is a unidirectional, asynchronous request. As a result of this call, the client will receive either a session_ready event or a no_session event. The direction in general is the direction from the mobile application to the cloud service.

Description of fields

Key Meaning Required op session_start Yes txid transaction ID No id User ID provided by the client Yes pwd Password provided by the client Yes bagdrop_id Bag drop off ID provided during discovery Yes

Example

session_ready

session_ready is one of two events that result from a start_session request. It notifies the client that the session with the baggage drop desk has begun. The answer includes the capabilities of the baggage drop desk, for example, whether printing of the baggage receipt and ticket is available. The direction is, in general, the direction from the cloud service to the mobile application.

Description of fields

Key Meaning Required op session_ready Yes txid Returned transaction ID No token Session token provided by the service Yes bagdrop_id ID of the baggage drop-off counter from which the session is performed Yes config Key-value pair of configured baggage drop-off counter capabilities. TBD values. No

Example

no_session

no_session is one of two events that result from a start_session request. It notifies the client that the session with the baggage drop desk could not be started. The reason code will be attached to the response. The direction is, in general, the direction from the cloud service to the mobile application.

Description of fields

Key Meaning Required op no_session Yes txid transaction ID No reason_code Valid reason code (see table) No bagdrop_id Bag drop-off counter ID Yes

Example

Reason codes

The code Description OUT_OF_SERVICE The baggage drop desk is not operational. IN_USE The baggage drop desk is in use, a session is in progress.

end_session

end_session is sent by either party to indicate the sender's desire to end the session. While generally sent from the mobile app to clear both sides, it can be sent by the cloud service for a number of reasons. The direction, in general, is the direction from the mobile application to the cloud service. May be sent from a cloud service.

Description of fields

Key Meaning Required op end_session Yes token Session token provided by the service Yes txid transaction ID No bagdrop_id ID of the baggage drop-off counter from which the session is performed Yes reason_code Reason for ending the session No

Example

Reason codes

The code Description PROCESS_COMPLETE Either party considers that the registration of the sequence of operations is completed. USER_REQUESTED The user (passenger) requested to stop the process UNIT_ERROR The baggage drop desk has detected some error or malfunction and cannot continue. SESSION_TIMEOUT Session timed out BAGGAGE_ERROR There was a problem preventing this baggage from being checked in

scale_result

scale_result is sent by the cloud service, forwarded from the baggage drop-off counter, to relay the results of weighing baggage by the scales of the baggage drop-off counter. The answer includes a set of restrictions on the weight/size of the airport or baggage handling system. The direction is the direction from the cloud service to the mobile application.

Description of fields

Key Meaning Required op scale_result Yes token Session token provided by the service Yes txid transaction ID No bagdrop_id ID of the baggage drop-off counter from which the session is performed Yes weight Baggage weight Yes dimension Luggage dimensions Yes weight_unit Units used (K=kilograms, P=lbs) Yes dimension_unit Units used (I=inches, M=millimeters) Yes bhs_rules BHS Rule Matrix No bhs_rules.weight Weight limit No bhs_rules.dimension Size limit No bhs_rules.weight_unit Units used conditionally bhs_rules.dimension_unit Units used conditionally result Numerical recommendation (see reason codes section) Yes

Example

Reason codes

The code Description PASSED Weight/size meet all requirements FAILED_WEIGHT_AIRLINE Airline weight limit not met FAILED_WEIGHT_BHS BHS weight limit not met FAILED_SIZE_AIRLINE Airline size limit not met FAILED_SIZE_BHS BHS size limit not met PLACE_IN_TUB_RETEST Recommendation code for placing luggage in the box and on the scale

print_bagtag

print_bagtag is sent by the mobile device to the cloud service. When the request is delivered to the baggage drop-off desk, it is considered to be an intermediary call. The request contains an image to be printed, for example in PECTAB format. The direction is the direction from the mobile app to the cloud service.

Description of fields

Key Meaning Required op print_bagtag Yes token Session token provided by the service Yes txid transaction ID No bagdrop_id ID of the baggage drop-off counter from which the session is performed Yes image Image to be printed Yes format Image format (eg PECTAB) Yes

Example

Formats

The code Description PECTAB parametric table

induct_bag

induct_bag is sent by the mobile device to the cloud service. When the request is delivered to the baggage drop-off desk, it is considered to be an intermediary call. It is assumed that the request is sent to the baggage drop desk to initiate the entry of baggage into the baggage handling system. This call is optional depending on the configuration. For example, some configurations may require baggage to be automatically entered after some specific step, in particular if the baggage receipt is pre-printed and attached to the baggage. The direction is the direction from the mobile app to the cloud service.

Description of fields

Key Meaning Required op induct_bag Yes token Session token provided by the service Yes txid transaction ID No bagdrop_id ID of the baggage drop-off counter from which the session is performed Yes

Example

print_receipt

print_receipt is sent by the mobile device to the cloud service. After the request has been delivered to the baggage drop-off desk, it is considered to be an intermediary call. The request contains an image to be printed, for example in PECTAB format.

The direction is the direction from the mobile app to the cloud service. A response is expected.

Description of fields

Key Meaning Required op print_receipt Yes token Session token provided by the service Yes txid transaction ID No bagdrop_id ID of the baggage drop-off counter from which the session is performed Yes image Image to be printed Yes format Image format (eg PECTAB) Yes

Example

Formats

The code Description PECTAB parametric table

2. Cloud Service - Controller

The main command is sent in the following format:

This format is suitable for all API calls except register , which will send a unique baggage handler ID, username, and password. The transaction ID is optional for the requester. If a transaction ID is received, it is preferred, but not required, to return it in the response payload.

reply

reply is a generic response sent by either the cloud service or the controller. The message carries information related to the previous request and an (optional) transaction ID. It can be used to acknowledge a request in the absence of a specific response payload. This API is bi-directional.

Description of fields

Key Meaning Required Op answer Yes Token Session token provided by the service Yes txid transaction ID No For {api request} Yes result successful or unsuccessful Yes reason_code reason for failure conditionally

Examples

Reason codes

The code Description NO_RESPONSE The service did not respond within the waiting period

register

register is sent by the baggage drop controller (CUTE, CUSS or other module) to the cloud service. This is a one-time message sent the first time the controller is brought online. The controller receives one of two events as a result of a register, registered , or registration_failed request. The direction is the direction from the controller to the cloud service.

Description of fields

Key Meaning Op register bagdrop_id Preconfigured Rack ID username Preconfigured rack username password Preconfigured rack password

Example

registered

registered is sent by the cloud service to the controller. The message indicates successful registration and that the session has started. The direction is the direction from the cloud service to the controller.

Description of fields

Key Meaning op registered token Session token provided by the service

Example

registration_failed

registration_failed is sent by the cloud service to the controller. The message indicates that the attempt to register the controller failed. The direction is the direction from the cloud service to the controller.

Description of fields

Key Meaning op registration_failed

Example

Reason codes

The code Description UNKOWN_UNIT_ID The baggage drop desk was not found in the database (must be pre-configured in the cloud service). BAD_CREDENTIALS Username and/or password is incorrect

deregister

deregister is sent by the baggage drop controller (CUTE, CUSS or other module) to the cloud service. The API request tells the cloud service that the controller has been placed on standby and its entry has been removed from the system. The direction is the direction from the controller to the cloud service.

Description of fields

Key Meaning op deregister token Session token provided by the service bagdrop_id Preconfigured Rack ID username Preconfigured rack username password Preconfigured rack password

Example

mark_available

mark_available is sent by the baggage drop controller (CUTE, CUSS or other module) to the cloud service. The API request tells the cloud service that the controller is now available to accept sessions. If the controller is already available, the cloud service will ignore the request. In all cases, an acknowledgment will be sent back. The direction is the direction from the controller to the cloud service.

Description of fields

Key Meaning op mark_available token Session token provided by the service

Example

mark_unavailable

mark_available is sent by the baggage drop controller (CUTE, CUSS or other module) to the cloud service. The API request tells the cloud service that the controller is not available to accept sessions. If the controller is already marked as unavailable, the cloud service will ignore the request. In all cases, an acknowledgment will be sent back. The direction is the direction from the controller to the cloud service.

Description of fields

Key Meaning Op mark_unavailable Token Session token provided by the service

Example

Reason codes

The code Description MAINTENANCE The controller is taken offline for maintenance MODE_CHANGE The baggage drop desk changes to another mode, such as manual mode

scale_result

scale_result is sent to the persistent baggage check-in cloud service. The answer includes a set of restrictions on the weight/size of the airport or baggage handling system. The direction is the direction from the controller to the cloud service.

Description of fields

Key Meaning op scale_result token Session token provided by the service weight Baggage weight dimension Luggage dimensions weight_unit Units used (K=kilograms, P=lbs) dimension_unit Units used (I=inches, M=millimeters) bhs_rules BHS Rule Matrix bhs_rules.weight Weight limit bhs_rules.dimension Size limit bhs_rules.weight_unit Units used bhs_rules.dimension_unit Units used result Numerical recommendation (see reason codes section)

Example

Reason codes

The code Description PASSED Weight/size meet all requirements FAILED_WEIGHT_AIRLINE Airline weight limit not met FAILED_WEIGHT_BHS BHS weight limit not met FAILED_SIZE_AIRLINE Airline size limit not met FAILED_SIZE_BHS BHS size limit not met PLACE_IN_TUB_RETEST Recommendation code for placing luggage in the box and on the scale

print_bagtag

print_bagtag is sent by the cloud service to the controller. When a request is initiated by a mobile device, it is considered a proxy call. The request contains an image to be printed, for example in PECTAB format. The direction is the direction from the cloud service to the cloud controller. Waiting for a response from the controller.

Description of fields

Key Meaning Required op print_bagtag Yes token Session token provided by the service Yes transaction_id transaction ID No image Image to be printed Yes format Image format (eg PECTAB) Yes

Example

Formats

The code Description PECTAB parametric table

induct_bag

induct_bag is sent by the cloud service to the controller. When a request is initiated on a mobile device, it is considered a proxy call. It is assumed that the request is sent to the baggage drop desk to initiate the entry of baggage into the baggage handling system. This call can be considered optional based on the configuration. For example, some configurations may require baggage to be automatically entered after some specific step, in particular if the baggage receipt is pre-printed and attached to the baggage. The direction is the direction from the cloud service to the controller. A response is expected.

Description of fields

Key Meaning Required op induct_bag Yes token Session token provided by the service Yes txid transaction ID No

Example

print_receipt

print_receipt is sent by the cloud service to the controller. When a request originates from a mobile device, it is considered a proxy call. The request contains an image to be printed, for example in PECTAB format. The direction is the direction from the mobile app to the cloud service. A response is expected.

Description of fields

Key Meaning Required op print_receipt Yes token Session token provided by the service Yes txid transaction ID No image Image to be printed Yes format Image format (eg PECTAB) Yes

Example

Formats

The code Description PECTAB parametric table

As described, the system comprises a front end application, which is either a unique application or a module on an airline/airport website. This is the interface through which airlines and/or airports provide their passengers with a baggage claim service. The internal software engine implements the logic for the self-check-in process and initiates the process. The API provides communication between the application, the internal software engine and hardware of the baggage handling system, and self-check-in peripherals such as printers and scales. Other fast peripherals may include automated readers and baggage raters, for example BHS equipment may include new or existing conveyor belts and scales.

Embodiments of the invention may also be used where printed boarding passes are required for passenger use in lieu of mobile boarding passes and with any type of baggage check, including temporary and permanent baggage checks, baggage handling systems without checks, and with self-printed baggage checks.

Embodiments of the invention have many advantages. The interaction between the passenger and the self-service point is simplified for the passenger and allows operators to reduce costs, such as traditional check-in staff and other equipment, while requiring relatively small changes to existing check-in systems and other systems, such as passport control, etc. . From the passenger's point of view, it provides convenience and time savings, thus enhancing the passenger's airport experience.

Although the description has been made in relation to the baggage claim system, embodiments of the invention may be used in connection with other airport self-service functions, such as electronic gates providing e-passport and/or boarding pass verification, final pre-boarding control, and check-in and/or generation kiosks. and printing of baggage receipts. In one embodiment, the passenger's mobile device connects to the baggage handling system upon arrival at the airport and the passenger is directed to the desired carousel and their baggage is also directed to that carousel.

Embodiments of the invention can be used with similar services in other ports, vocals, i.e. places of mass passage of people, as well as in places of mass events, sports facilities, etc., where individuals interact with services such as ticket control.

Embodiments of the invention may also be preferred for disabled passengers. For example, by using the speech capabilities of a smart device, a blind or visually impaired passenger's experience of baggage check-in, passport control, and other airport functions can be greatly improved. Embodiments of the invention also allow the combination of passenger information on a smart device with payment services that an airline or airport can already provide through existing mobile applications.

Claims (36)

1. A method for facilitating interaction between a ticket holder and a ticket-related self-service function, comprising: using the mobile device to detect proximity to the self-service function, wherein the mobile device stores information related to the ticket and the self-service function is associated with the ticket; after detecting, using the mobile device, the proximity to the position, activating the application on the mobile device, and the application is associated with a self-service function; and transmitting to the mobile device through the application and through the cloud service information about the interaction between the ticket holder and the self-service function, including direction information, and the cloud service acts as an intermediary between the mobile device and the self-service function. 2. The method of claim 1, wherein the ticket is associated with the passenger's flight and includes identification of the passenger and flight. 3. The method of claim 2, wherein the ticket information contains a boarding pass. 4. The method of claim 1, wherein the mobile device detects a geolocation device indicating proximity to a self-service feature. 5. The method of claim 4, wherein the geolocation device is a Bluetooth beacon. 6. The method of claim 1, wherein the application requests ticket information stored on the mobile device and transmits the ticket information to a remote server. 7. The method of claim 6, wherein the remote server, upon receiving the ticket information ticket, reports the information related to the self-service function to the application for presentation to the user of the mobile device. 8. The method of claim 1, wherein the self-service function is a baggage claim and the ticket related information is a boarding pass, comprising transmitting the passenger information on the boarding pass to the departure management system. 9. The method of claim. 8, comprising determining by the departure control system whether the baggage associated with the boarding pass is suitable for baggage check-in, and transferring the suitability to the mobile device. 10. The method according to claim 8, comprising, after placing the baggage at the baggage drop-off counter, weighing the baggage, determining whether the weight exceeds the permitted weight, and if the weight exceeds the permitted weight, charging a fine for exceeding the baggage allowance through the application. 11. The method of claim. 1, comprising printing a baggage receipt at the baggage drop desk and transmitting instructions for attaching a baggage receipt to baggage for presentation to a user on a mobile device via an application. 12. The method according to claim 8, comprising, after checking in the baggage at the baggage drop counter, transmitting to the application information about the boarding and the path to the boarding gate. 13. A method for facilitating interaction between a ticket holder and a ticket-related self-service function, comprising: at a position near the self-service function associated with the ticket, activating the application on the mobile device, the application being associated with the self-service function, and information related to the ticket is stored on the mobile device; transmitting to the mobile device through the application and through the cloud service information about the interaction between the ticket holder and the self-service function, including direction information, and the cloud service acts as an intermediary between the mobile device and the self-service function. 14. The method of claim 13, wherein the application is activated by scanning or imaging a barcode using a mobile device. 15. A system for facilitating interaction between a ticket holder and a ticket-related self-service function, comprising: self-service function; a mobile device, wherein information relating to the ticket is stored on the mobile device; at least one geolocation device; moreover, the mobile device is configured to detect the geolocation device in a position near the self-service function, and at least one server that stores computer software for carrying out the steps: if the mobile device detects a geolocation device near the position, activating the application on the mobile device, the application being associated with a self-service function; and transmitting to the mobile device through the application and through the cloud service information about the interaction between the ticket holder and the self-service function, including direction information, the cloud service acting as an intermediary between the mobile device and the self-service function. 16. The system of claim 15, wherein the ticket is associated with the passenger's flight and includes identification of the passenger and flight. 17. The system of claim 15, wherein the ticket information contains a boarding pass. 18. The system of claim 17, wherein the at least one geolocation device is a Bluetooth beacon. 19. The system of claim 15, wherein the application requests the ticket information stored on the mobile device and transmits the ticket information to the server. 20. The system of claim 19, wherein the server, upon receiving the ticket information ticket, reports information related to the self-service function to the application for presentation to the user of the mobile device. 21. The system according to claim 15, comprising a departure management system, in which the self-service function is a baggage drop desk containing a baggage handling system and a baggage claim controller, and the ticket-related information is a boarding pass containing the transmission of passenger information in the boarding pass flight control system. 22. The system of claim 21, wherein the departure control system is configured to determine if the baggage associated with the boarding pass is eligible for baggage check-in and transferring the suitability to the mobile device. 23. The system of claim 22, wherein the baggage handling system comprises a weighing device for weighing the baggage after being placed at the baggage drop counter to determine if the weight exceeds the permitted weight, and, if the weight exceeds the permitted weight of collection, payment of the excess baggage penalty through Appendix. 24. The system of claim. 22, wherein the baggage handling system includes a printer for printing a baggage receipt and a baggage drop controller configured to transmit instructions for attaching a baggage receipt to baggage for presentation to a user on a mobile device via an application. 25. The system of claim 15, configured to, after checking in baggage at a baggage claim counter, transmit boarding information and a path to the boarding gate to the application.

Images