RU2773049C2 - System, device and method for access to shared infrastructure - Google Patents

Abstract

FIELD: infrastructure.

SUBSTANCE: invention relates to systems for providing access to a shared infrastructure. The effect is achieved by determining the location identifier for the user, associating the location identifier with the user identifier for the user, and transmitting the location identifier and the associated user identifier to the application, while the location identifier specifies the location of the device according to the hierarchical structure stored in the database, where each identifier location is associated with a predetermined location, and a hierarchical tree is provided specifying a location relative to each predetermined location.

EFFECT: enabling rapid scaling of the location identifier database.

26 cl, 3 dwg

Description

The field of technology to which the invention belongs

This invention generally relates to a system, method, and apparatus for providing access to a shared infrastructure, such as a machine implemented device. The shared infrastructure can be a device such as a boarding pass or baggage tag printer, a document reader, or a boarding pass or baggage tag printing kiosk. The system, for example, may be intended for use by consumers, passengers, and agents providing services to consumers or passengers.

State of the art

Typically, airlines share common infrastructure, such as computing devices, which are generally provided by an airport in order to serve their passengers. Prior art shared common infrastructure solutions are inflexible, costly, difficult to deploy and operate, and do not readily accommodate emerging technology such as the use of mobile devices. This is due to the fact that known solutions force airlines to work in an environment with the smallest connecting link. For example, a specific version of Microsoft Windows™, a specific version of Adobe™ Flash™, or a specific version of JAVA™ that are commonly used by shared devices in an airport environment may determine how known solutions interact with or access specific services. This can lead to technical difficulties in providing access to shared devices.

It should also be appreciated that known platforms, such as the Microsoft™ Windows™ platform, which can manage shared devices, are closed platforms. This forces users to access devices in the airport's local environment through a local interface in order to communicate with the platform. Thus, there are no conditions for being able to communicate remotely with one or more devices in the airport's local environment.

Accordingly, it should be appreciated that known solutions link features of end peripherals (such as printers, scanners, etc.) through an application interface, thereby preventing the development of peripherals and adding convenience and ease of use features to passengers without affecting Appendix.

Additionally, virtual private network (VPN) systems have the problem that they require users to enter additional data, such as additional security credentials when logging into an account, after accessing remote systems through a VPN, which can simply be considered a tunnel The through which the connection is sent.

The essence of the invention

The invention aims to solve these problems by providing a computer processing device for providing access to one or more electronic devices. The device comprises processing means configured to: determine a location identifier associated with a user account login event; associate a location identifier with a user session identifier; and pass the location ID and associated user session ID to the application.

Additionally, embodiments of the invention provide a mechanism that provides one or more tokens to one or more devices. The use of specific markers by devices facilitates communication without interference.

This is in contrast to VPN systems, which do not have a number of different functional components that transform data content as data is transferred between functional components.

Thus, the system enables airlines to operate in their own environment without the restrictions imposed by another airline sharing a common infrastructure. The invention provides cloud services, which reduces costs and provides an efficient deployment and operation model. The invention enables the airport environment to be segregated from the airline environment, thereby allowing all entities to evolve based on their business needs. The invention provides a timeless interface for airline applications based on substantial data exchange using the latest web technology. The interface eliminates the influence of client devices. The invention may include an easy-to-use portal that allows device vendors at an airport to set up an environment that is independent of airline users. The portal enables airlines to activate their application immediately at available airports and locations without relying on a third party.

The core functionality of the solution provides a common API that enables airline applications to dynamically subscribe to a shared or dedicated infrastructure at any location at any accessible airport on a global scale. Shared or dedicated infrastructure is not limited to airports and may include car parks, hotels, train stations, convention centers, city centers, cruise ships, and so on. The API may use the location identity to associate airline user sessions with the shared infrastructure. Location identification data is based on a simple naming convention that uniquely identifies any infrastructure at airports and non-airport locations. Client applications can obtain location identification data in a number of different ways, such as QR tags, radio beacons, NFC, and so on.

The architecture of the solution is based on the separation of the user interface from physical devices, which requires user interaction, such as receiving boarding passes, receiving baggage, scanning documents, paying and processing at the gates, etc. This can be achieved through 2 communication channels, and it can provide flexibility for user interface devices such as workstations, tablet computers, smartphones to be upgraded independently of devices such as passport scanner, payment card acceptor, automatic baggage claim device. etc.

Embodiments of the invention also provide a solution to the need for backward compatibility. The platform provides a means for airlines to continue using their existing software with minimal modification, while taking advantage of the flexibility the new platform offers them. This can be achieved through the functionality of the field gateway.

Embodiments of the invention may use an architecture that has the ability to provide access to a shared infrastructure in a distributed skeleton. This implementation is not limited to a particular version of Microsoft™ Windows™ or Linux™ applications, or Cisco™ IOx™, or Androd™.

Embodiments of the invention use an architecture that is capable of running on any of these systems. This can be achieved using an Internet browser. Typically, the browser contains the HTML 5 standard. It allows access to a distributed network or skeleton based on the Next Generation Portal (NGP) of devices according to the HTML 5 standard. This has the advantage that the only local resources are the resources required in order to execute browser. Accordingly, many processes requiring significant processing power may be pushed or executed in a host environment such as an airline backend system, open server system, departure control system, data center, or cloud. This means that the only local resources to be used are those used by the browser. This enables certain applications to run faster than known solutions, since, for example, the database does not have to be loaded locally.

According to a first aspect of the present invention, a data processing system is provided for providing user access to one or more devices (108). The system comprises processing means (103) configured to: determine a location identifier for a user; associate a location identifier with a user identifier for the user; and transmit (3013) the location identifier and the associated user identifier to the application (301).

According to a further aspect of the present invention, a computer processing device is provided for providing access to one or more electronic devices. The device comprises processing means (103) configured to: i. determine a location identifier associated with a user account login event; ii. associate a location identifier with a user session identifier; and iii. transmit (3013) the location identifier and the associated user session identifier to the application (109).

According to a further aspect of the present invention, an electronic device is provided that includes a field gateway component for facilitating authentication in a remote environment.

According to a further aspect of the present invention, a method is provided for providing access to one or more electronic devices. The method contains the following steps: a. determining a location identifier associated with a user account login event; b. associating a location identifier with a user session identifier; and s. transmitting (3013) the location identifier and the associated user session identifier to the application (109).

According to a further aspect of the present invention, a computer program product is provided for providing access to one or more electronic devices. The product, when executed, performs the steps of determining the location identifier associated with the user's login event; associating a location identifier with a user session identifier; and transmitting (3013) the location identifier and the associated user session identifier to the application (109).

The application may be provided in a remote data center and this allows additional resources to be provided in the data center. This makes it possible to improve performance in a desired manner. In other words, embodiments of the invention provide simple vertical scaling features, such as by adding additional storage or servers to a remote data center as needed.

An additional benefit of using an HTML 5-enabled browser is that no additional confirmation is required from any application. This provides a significant benefit to airlines as new functionality does not need to be certified as it is not deployed using a new application in an airport environment but instead delivered through an HTML 5 enabled browser. Additionally as there is no need for the application to share the environment with other applications manufacturer, the obligation to use other manufacturer's applications is excluded.

Additionally, it is easier for systems implementing embodiments of the invention to achieve PCI compatibility because the environment is not shared between a certain number of different applications.

Embodiments of the invention may separate the data required in order to print or read a document from features related to the convenience and ease of use of the peripheral. Communication is part of the application interface, with the usability part of the peripheral being controlled through configuration, allowing peripherals to add usability features without impacting applications, and thus maintaining the longevity of the interface.

Embodiments of the invention use a solution referred to as a "next generation portal (NGP) solution". The solution can be implemented by providing 2 different channels. These channels may be referred to as the device channel and the graphical user interface (GUI) channel. This, together with a web browser with HTML 5 support, allows you to provide many of the above benefits.

Thus, the solution is based on the exchange of pure data between different functional components. Another characteristic can be adjusted through configuration settings. Thus, if changes are to be made, these changes can be made through the configuration settings of the characteristics. Accordingly, in some embodiments, the application interface is driven by pure data only. The convenience and ease of use of the application is configured through the configuration settings.

On the device side, a similar architecture can be used. For example, it focuses on the logical separation of communication services and configuration services, which can be related to the appearance and functionality of the device interface.

For example, an airport environment can make services available or, in other words, publish services to an API environment used by users. Subscribers of an application environment, such as an airline, can view published services. This allows users to subscribe to any one or more of a specified number of published services. Publish and subscribe services may be provided independently.

Unlike known VPN systems, in the present invention, the content of the data is transformed through a certain number of functional components, also using bi-directional communication and end-to-end authentication. The data can be transformed based on the rules processing engine. Of course, the nature of the data conversion may differ for each user of the system, based on his needs.

Thus, embodiments of the invention may be based on a cloud platform such as Microsoft™ Azure™ technology, in particular using an IoT hub, service provisioning shell, API gateway, streaming analytics, and machine learning. The solution is built using multi-faceted security, in particular through the use of streaming analytics, machine learning and deep learning to profile user and system behavior in order to identify and adapt to anomalies.

According to an aspect of the present invention, a data processing system or device is provided for providing user access to one or more additional devices (108). The device comprises processing means (103) configured to: determine a location identifier associated with a user login event; associate a location identifier with a user session identifier, wherein the user session identifier is preferably associated with a user login event; and transmit (3013) the location identifier and the associated user session identifier to the application (301).

According to a further aspect of the present invention, a method is provided for providing access to one or more electronic devices. The method contains the following steps: a. determining a location identifier associated with a user account login event; b. associating a location identifier with a user session identifier; and s. transmitting (3013) the location identifier and the associated user session identifier to the application (109).

Brief description of the drawings

The following describes an embodiment of the invention by way of example only and with reference to the accompanying drawings, of which:

Fig. 1 is a schematic diagram of the main functional components implementing the invention;

Fig. 2 is a schematic diagram showing the system architecture of an embodiment of the invention; and

Fig. 3 is a flowchart showing the flow of various functional components according to an embodiment of the invention.

The following description relates to a system for use in the aviation industry, but this is exemplary and other applications of the invention are also explained. For example, the system can be used in any environment where the infrastructure is shared. The system may be implemented in a hosted system that may use API communication protocols to communicate with external systems such as reservation systems or departure control systems.

In this particular embodiment, application programming interface (API) services or modules are built on the Microsoft AZURE platform. However, other platforms known to those skilled in the art may be used, such as the Amazon Web Services (AWS) cloud platform, the IBM cloud platform, or the Google cloud platform.

Additionally, it should be appreciated that the functionality may be implemented in any programming language, such as HTML 5, C++™, JAVA™, and .xml, as well as other programming languages that are known to those skilled in the art, may be used. For example, embodiments of the invention may use one of these programming languages to provide a web service.

Referring now to FIG. 1, it can be seen as a schematic diagram showing the architecture of a system implementing the invention. This system may be provided as part of a Next Generation Protocol (NGP) system.

In this particular embodiment, the system contains three different zones: API environment 103, application environment 109, and airport environment 105.

Typically, one or more of these zones are in different physical locations. For example, the API environment 103 may be physically located in a particular state, such as California in the United States, while the local airport environment 105 may be located, for example, in Bohemia in the United States. The particular airline application environment 109 hosting one or more of the applications 141, 143, 145 may also be located in the United States. The application environment may be operably connected to a departure management system, which may be hosted in, for example, another region, location, or country, such as Germany.

In another specific example, the API environment 103 may be physically located in the Netherlands, while one or more user devices 107 and associated GUIs running on the devices may be located in Frankfurt, Germany, while one or more used devices 108 may be located in Bohemia, United States. The application environment and associated applications 141, 143, 145 may also be located in the United States while the flight control system or other internal interface system 102 is located in Germany.

Description of user devices 107, shared devices 108, and local and remote environments

Typically, an airport environment contains one or more computing devices 107, 108. These computing devices can be divided into 2 groups. The first group of computing devices 107 may include any one or more of a shared workstation or tablet computer that an airline agent may bring to an airport to perform one or more functions, such as check-in or boarding functions. The first group of computing devices may also include smartphones or tablet computers, or any other portable computing devices that passengers may bring to the airport environment to perform the function of printing boarding passes or baggage tags, or making payments such as overweight charges, etc. .d. These computing devices are referred to as user devices 107. In essence, these computing devices 107 provide a way to access a shared infrastructure, such as a second group of computing devices 108.

The second group of computing devices 108 may include any one or more of a printer or scanner or reader, a check-in desk device, a boarding desk device, a kiosk (for example, a boarding pass or baggage tag printing kiosk), a baggage claim device, devices for screening or devices for providing automatic boarding gates. In other words, the second group of computing devices 108 is associated with shared infrastructure computing devices. The scanner or reader is typically configured to read a boarding pass or baggage tag, a passport or identity card, or other machine-readable document. This is typically done using optical scanning of the boarding pass or baggage tag using optical character recognition (OCR) algorithms that are known to those skilled in the art.

Fig. 1 shows an airport environment as an example, but of course, it should be appreciated that this area 105 can be any environment where shared infrastructure can be provided, such as a train station, hotel, convention center, cruise ship, etc. d. This zone 105 is referred to as the local area 105.

The application environment 109 is commonly referred to as remote zone 109. The application environment may include a data center or one or more server computers used by, for example, an airline. Additionally, the application environment functionality may be provided in a hosted environment.

Description of the main functional components

System 100 may include any one or more of the following functional components: one or more modules or interfaces 111 for providing one or more services. The modules are typically operably connected to one or more applications 141, 143, 145, respectively. Additionally, each of the modules or interfaces can be operably connected to one or more devices 108. Any of the functional components in the API environment 103 can be referred to as a module to execute one or more different functional operations.

For example, the server or computer 101 may be configured to execute an application programming interface (API) in the API environment 103. The server computer is typically operatively connected, through a means of wired or wireless transmission, which should be known to those skilled in the art, with any one or more of the various functional components shown in FIG. 1, 2 and 3 from the drawings.

Application environments 109 and airport environments 105 may be provided by third parties, and each of these environments 105 and 109 typically operably connects to one or more API services through a published interface. As mentioned above, the application environment 109 typically resides on one or more computers or server computers.

Typically, local environment 105 is operatively connected to API environment 103 via wired or wireless communication protocols that are known to those skilled in the art. Likewise, remote environment 109 is typically operatively connected to API environment 103 via wired or wireless communication protocols that are known to those skilled in the art.

Description of the database 104 data and beacon 110

As shown in FIG. 1 of the drawings, the database 104 may be provided as part of the system. Typically, data associated with a database is stored in a storage medium or storage device such as read only memory or random access memory. However, it is not essential that the database is located in an API environment. For example, a database can be provisioned in any location as long as it connects functionally to an Azure API environment. The database is typically searched through API 106. The database typically contains one or more different beacon identifiers, such as a UUID, and one or more different location identifier(s). Association between each beacon identifier and each location identifier

provided, and the database, its structure, and interaction with other functional components shown in FIG. one.

The system typically further comprises one or more beacons 110. Each beacon is typically placed in close proximity to any one or more user devices 107 that may be used in an airport environment. For clarity, in Fig. 1, a single beacon 110 is shown. However, typically multiple beacons are provided at different locations. Each beacon is typically associated with one piece of shared infrastructure 108.

Multiple shared devices 108 may be provided in a particular location. Each shared device typically has a unique identifier, such as a device ID. The device ID is usually in the form of an alphanumeric string. One specific example of a device ID is:

deviceId: "413dc6c0a03d4d6a9cd2c1=".

Additionally, to distinguish between different

functionality of multiple shared devices 108 in a particular location, each shared device 108 may have an associated device type or a common device tag definition.

For example, the LSR device type may indicate the barcode scanner used to scan a boarding pass or baggage tag. The device type or MSR tag may indicate that the device is a swipe magnetic card reader used to read a loyalty or credit card. Other types of devices or tags may be an ATP indicating that the device is a baggage tag printer or a boarding pass printer referred to as "ATP (Automatic Ticketing and Boarding Pass Printer)", indicating that the device is a boarding pass printer. coupons. The combination of device type and location identifier provides the ability to uniquely identify a particular device in a particular area of the airport.

Description of User Session Credentials and Authentication Services 114

Authentication service module 114 may be provided in API environment 103. This allows users to subscribe to the system and also provides subsequent access to the system with a username and password to log in to the user's account.

After the user logs in to an account, an account login event is fired. It generates a location identifier (identifier) and a user session identifier (identifier). The location identifier may be determined by searching the database (112) for previously stored location identifiers associated with various users. The location identifier may be selected based on a match between the user's login to the account and the matching user's login to the account and the associated location identifier stored in the database (112). Additional information, such as the location (eg, longitude or latitude coordinates, country, state, or region) from which the user logs in, can also be used to uniquely determine the location identifier for the user from the database (112).

Description of published interfaces

One or more interfaces or functional components shown in FIG. 1 of the drawings may be interfaces that are published or made available to third parties outside of the API environment 103. For example, configuration portal 115, web proxy service 113 and API services 111, and specific device service interfaces 117 may treated as published interfaces. Published interfaces have 2 different responsibilities.

First, APIs or services 111 provide communication between one or more applications 141, 143, 145 running in a remote environment 109 and one or more devices 107, 108 running in a local airport environment.

Second, information related to specific device characteristics and end user experience is provided through the configuration portal 115 shown in FIG. 1. The configuration portal 115 can efficiently integrate API data with a device interface that connects the device service interface 117 to one or more shared devices 108 in the airport environment. This allows the system to use the full characteristics of the devices 108. The configuration portal 115 and the associated configuration settings associated with each shared device 108 are described in more detail below.

API 111 Functional Description: Acknowledgment and Routing Function

One or more APIs 111 provided in an API environment may have two main functions. First, they transmit acknowledgment messages in response to receiving message(s) 121, 122 from one or more applications 141, 143, 145 in the remote application environment 109. Secondly, they have the function of routing messages to the correct device service in the device service API 117 . Typically, this is necessary because a number of different device services are provided in the device services interface 117 . For example, the services in the device services interface 117 may be related to printing a boarding pass or printing a baggage tag, or scanning a boarding pass or baggage tag, or swiping a credit or loyalty card using a swipe magnetic card reader, or the like.

Thus, the API service(s) 111 can perform the function of both routing messages to the correct service at the device service interface 117 and sending an acknowledgment message to confirm that a request from one of the applications 141, 143, 145 is in environment of remote applications is correctly received by API service 111.

API 301 shell CUTE

API 301 shown in FIG. 3 of the drawings may also be provided and located in the API environment 103. It is referred to as the CUTE wrapper API. One of the functions of the application 301 is to translate between different protocols in use. Additionally, the application 301 can also broadcast commands between the API environment 103 and the remote application environment 109 . In addition, the API performs an authentication function to verify that messages 122 received from the remote application environment are associated with a genuine user. The CUTE wrapper API is particularly useful when integrating legacy airline applications for use in an NGP system. However, this is of course optional, and airline applications can be configured to directly receive messages from the NGP system, within the scope of the need from the CUTE wrapper API 301.

Description of data exchange between functional components

In FIG. 1, communication between the various functional components is represented by arrows labeled 121, 122, 123, 124, 125, 126, 127, 128, and 129. Of course, for the sake of transparency, not all communication between the various functional components is shown. However, this additional information is detailed below.

In one particular example, messaging 121, 122 between API services 111 and their respective and commonly associated applications 141, 143 in the remote application environment shown in FIG. 1 may be implemented using Java Script Object Notation (JSON™) XML messages. It is a data exchange format based on the Java™ Script programming language. It is described in more detail with reference to FIG. 3 of the attached drawings below. Of course, other messaging protocols known to those skilled in the art may be used.

Detailed description of the location and functionality of radio beacons

As described above, the beacon 110 is typically located in close proximity to a location where one of the user devices 107 may be used. Alternatively, a matrix barcode, such as a one-dimensional barcode, a quick response (QR) code, or a two-dimensional barcode, may be used. In this case, the location identifier is encoded in a QR code or a 2D barcode. These codes provide the ability to encode information in them. This is described in more detail below.

A beacon identifier value may be associated with each beacon. It can be set using a companion application such as the beacon manager tool. The user device 107 may use wireless signals such as Bluetooth to communicate with the beacon 110.

Typically, each of the user devices 107 includes an application for allowing access to a shared infrastructure. This application, which may take the form of an API, may be executed by a user, an airline agent, or a passenger as they approach the shared infrastructure 108.

The application is typically configured to discover one or more beacons 110 via wireless communication protocols such as Bluetooth. After the application discovers the UUID of the beacon, it is sent to API environment 103.

The beacon identifier or UUID data, for example, may be a 32-character alphanumeric code. The code, for example, may have the format 1 AE18C1 C-6C7B-4AED-B166-4462634DA855, which is associated with a beacon. The API may also return one or more of majorld = 14, minorld = 2. In another specific example, API 106 may return one or more of UUID = 1 14A4DD8-5B2F-4800-A079-BDCB21392BE9, majorld = 1100, minorld = 1292; majorld and minorld can be used to distinguish between beacons in a particular area sharing a common UUID. API 106 may return data associated with one or more beacons.

Description of how UUIDs stored in database 104 are converted to location identifiers

In API environment 103, the conversion of identifiers from beacon identifier 110 to location identifier may be performed as a service. Thus, as part of the initial configuration process, the beacon ID and location ID are passed to the API environment. The location identifier may be in the form of an alphanumeric string such as "JFKT5CK01", which indicates that the beacon is, and therefore, the user device 108 is located at John F Kennedy Airport, Terminal 5, check-in desk 01.

A transformation between each beacon identifier and location identifier is performed and the association or transformation is stored in a database.

Thus, the database contains at least one beacon identifier associated with a location identifier. This makes it possible to define a communication link between the beacon identifier and the user device 107.

The database may also include a map of the airport's local environment. This allows a visual representation of the physical location of the beacon(s) 110 as well as associated user devices 107 that are located near each beacon 110.

In one particular embodiment, the database 104 may include data defining a map of the airport, as well as the locations of beacons and associated shared devices 108 within the map.

Additional description of the location ID

As described above, the location identifier (ID) may be considered as an association or communication link between the interdevice communication channel 124 and the GUI communication channel 125 shown in FIG. one.

Additionally, a number of different associations can be provided between the communication channel 12 4 and the communication channel 12 5 and one of the applications 141, 143, 145 running in the remote application environment 109. This allows the user to use multiple locations.

As stated above, the location may be determined using a beacon, NFC, or a tag. The location identifier (ID) may be parsed by an internal interface service.

The following description focuses on additional details regarding the principle of the identifier (identifier) location. The location identifier can follow the format of any of the following examples:

1. BOH-PREPROD-T01-GATE01-WKS-001

2.JFK-T01-GATE03-WKS-002

3. MIA-ADM-FLR1-CONF1-WKS-001

Example 1

In this example, airport = WON, district = pilot plant, terminal = 1, exit = 1, and workstation = 1.

Example 2

In this example, airport = JFK, terminal = 1, gate = 03, and workstation = 2.

Example 3

In this example, airport = MIA, district = administration, floor = 1, conference room = 1, and workstation = 001.

These examples define a relative location, or a location that can be at any location within one or more predefined areas. Location identifiers can define districts, regions, or volumes in 2D or 3D space. A two- or three-dimensional space may be defined by one or more X, Y, or Z coordinates that are associated with each region or space. The coordinates defining each region or space may be stored in a database, such as database 112, along with an associated location identifier defining each region or space.

In the above examples, the location identifier may define different areas. Typically, at least some of the various regions overlap with one or the other, or may be contained entirely in another region. Thus, an airport may be considered as area 1, an administration area may be considered as sub-area 2, and a conference hall may be considered as sub-area 3 for sub-area 2. Sub-area 3 may be entirely contained within sub-area 2. Similarly, sub-area 2 may be completely contained in subarea 1.

The location identifier may specify the location of a particular device 107, such as a workstation, as part of a hierarchy. In a specific example, the actual workstation may be a kiosk or a workstation for receiving baggage from one or more of these.

This hierarchical structure is extremely flexible and provides a human readable text format.

Additionally, a database of area abbreviations and associated explanations of these abbreviations may be provided.

It should be appreciated that the location identifier does not specify a location relative to a single point of origin. This is in contrast to a coordinate system, such as a longitude-latitude coordinate system, in which all locations are relative to a single point of origin. Rather, each location identifier is associated with a predetermined location. A hierarchical tree is provided defining a location relative to each predefined location. This has the advantage that the location identifier can be interpreted by those skilled in the art and the hierarchical structure can be understood without having to consult an abbreviation database. This allows the hierarchical structure to be easily expanded as needed.

For example, suppose a registration kiosk is deployed in Times Square, New York.

The location identifier may be specified by NYC-TSQ-...

The location identifier may be passed between different functional components as a text string.

The string can be searched. The location identifier logical structure is usually bypassed only when the tree is created. The tree can be viewed through the GUI on the workstation. The GUI shows how a location identifier defines a nested structure.

Thus, a location identifier typically starts with an IATA-specified location code such as JFK, LGA, LAX, or a known location abbreviation such as NYC.

When the hierarchy is built, each stage is added to the location identifier (ID), which ensures its human readability and understandability. This provides a very accurate view of the workstation's physical location. When the location identifier is specified with sufficient precision such that the workstation is actually located, a marker may be added. The token may be referred to as a WKS token, and then an identifier may be added that specifies the workstation number. This diagram can be used to illustrate that virtually any location represents the world.

Description of the device type or generic device label to distinguish between different types of shared devices 108

If a location identifier is associated with multiple shared devices 108, then the device types described above can be used to distinguish between different devices at a particular location. Alternatively, a unique device identifier may be used to distinguish between different shared devices 108.

This can be done by associating one of the shared devices 108 with a specific location identifier and device type tag. An example of device type labels is ATP, BTP, LSR, MSR as described above.

Thus, each device 108, such as a baggage tag printer or a baggage tag scanner, for example, can be identified by its location ID and device type tag. As noted above, tags are usually shared, but the combination of a location identifier and a tag provides a way to identify one device from a number of different shared devices 108 that may be in a particular location.

The specific method of uniquely determining which shared device 108 a particular message is sent to can be performed in 2 different ways.

As a first option, the shared device 108 may be uniquely identified based on a location identifier and a device type tag, such as ATP, VTP LSR.

As a second option, the shared device 108 is uniquely identified using the beacon UUID, which is translated into a location identifier JFKT5CK01 and an ATP tag. This means that the location of the shared devices 108 is identical or similar to the location of the user devices 107. A beacon identifier, such as a beacon UUID, may provide a link or association between the shared device identifier or tag and the location identifier.

Fig. 2 of the drawings shows a schematic diagram of a particular embodiment in which an adapter 201 is provided. This adapter is provided for modern airport devices 107 that do not allow connection to the IoT hub cloud 203 directly. Thus, the adapter service is used to enable the legacy device to function as an IoT device. This adapter, along with a device interface, is published to allow device manufacturers to develop devices that have native IoT support. Adapter 2 01 shown in FIG. 2 may also be referred to as the field gateway (FG) shown in FIG. 1 from the drawings.

Location identifier abstracts position

devices to a logical location, such as a check-in counter, a hotel lobby, with no knowledge of connected workstations or IT layout. The location identifier is described in more detail below.

Message routing from devices to airline/airport applications and from airline/airport applications to devices is handled through unique internal routing engines and Azure routing engines. The routing mechanisms are described in more detail below with reference to FIG. 3 of the drawings, which shows a flowchart of the method of an embodiment of the invention.

IoT adapters, location abstraction, and feature-based services deliver a distinctive device management and operation solution on a global scale while limiting hardware complexity, device characteristics, and message routing in a cloud application.

Detailed description of API 117 for providing services to devices

Device service API 117 may be provided in an API environment.

The Device Services API 127 provides an interface to any one or more shared devices 108. This enables the enumeration and availability of services that can run any one or more shared local devices for use by any of the user devices 107.

For example, suppose shared device 108 is simply a printer connected to a networked workstation. Device service API 117 indicates that the device can print.

Additional information regarding the nature of printing may be provided through the Device Services API. For example, they may indicate that the printer is capable of printing a baggage tag that can be attached to a passenger's baggage. Similarly, the Device Services API may indicate that the printer has the ability to print a boarding pass in a specific format or size, or according to a sheet or table with a specific style. For example, a boarding pass printer may print a boarding pass using a RESTAV print control language. In this case, the data to be printed on the boarding pass is formatted according to one or more tables.

In either case, the configuration portal 115 is operatively connected to the device service interface 117 . This is schematically illustrated by the arrow labeled 128 in FIG. 1. Thus, the configuration portal 115 is also operatively connected to the performance-based service provisioning interface.

Configuration of workstations and associated peripherals

Before a detailed description of the flowchart of the method of FIG. 3, the following describes an optional configuration of workstations and associated peripherals such as baggage tag printers or boarding pass printers.

Workstations with peripherals connected to the workstation can be deployed using the following steps. This assumes that the workstation is running Windows 10, for example, and has the required device drivers preloaded into the image.

After the workstation or handheld device is launched in the DOY phase, the installer launches a browser and enters the NGP URL in order to connect to the NGP portal. The installer usually needs to enter security credentials to begin the installation process. The NGP Portal provides an intuitive GUI to guide the installer to connect and configure peripherals. This process automatically installs and configures all required software on the workstation based on the location ID provided by the installer during the ZON step. Typically, the NGP installation portal GUI requires the installer to test all peripherals to verify a successful installation. Peripherals can in principle be any shared device 108 such as a boarding pass printer or baggage tag printer.

The user then enters a specific URL in a browser running on the user device 107 to access the NGP system. Usually, each airline has a different URL to access the system.

Referring now to FIG. 1 and 3 of the drawings, the flow of the messaging will be described below. It should be appreciated that the specific order of the steps is exemplary, and that the steps may be performed in a different order than that shown in FIG. 3.

The following description assumes that the user has previously created an account with the NGP system, such that the user has a username and password stored on the system that provides access to the system. Additionally, it also assumes that device 107 is equipped with a browser in order to connect to an NGP portal that provides access to an API environment. Typically, the term "API environment 103" is used interchangeably with the term "NGP portal" or "system". It also assumes that one or more peripherals, such as a baggage tag printer or a boarding pass printer, are configured as described above.

Solution for portable devices

In some examples, an airline agent may bring a portable computing device, such as a tablet computer, to an airport counter, kiosk, or baggage drop location to perform check-in or boarding pass functionality, for example. Likewise, passengers using smartphones/tablets can approach kiosks or other locations to print boarding passes, baggage tags and make payments directly from their own devices. The passenger usually has to run a particular airline application in order to perform these functions. This enables the passenger to have an efficient working experience at the airport.

As noted above, beacons, using, for example, NFC technology, allow the device 107 to associate with shared devices 108 at counters and inside kiosks and baggage claim areas.

Described above is the association of specific beacons with shared computing devices, or in other words, location identifier(s) associated with shared computing devices 108.

The location identifier (ID) associates or associates the 2 channels 124, 125. It informs the platform as to which printer in the local environment 107 of the airport the application 141, 143, 145 in the remote environment should communicate with.

When a user logs into an account from a tablet computer or other device 107, a predetermined location identifier is sent to the API environment 103. Alternatively, when a user logs into an account, they can manually select their location. The location can be determined using a beacon, or using a near field communication (NFC) or QR tag, as described above. Thus, airline agents can bring their own tablet computers and simply approach airport counters, kiosks, baggage claim areas, and other locations to perform check-in and boarding functions.

The tablet computer may be associated with one of the devices at counters (eg, at a kiosk or baggage claim) using, for example, a beacon or NFC. This allows the device to receive a location identifier (identifier) and, for a portable device, to transmit the location identifier to the API environment 103.

Thus, the user may bring the portable computing device 107 to the airport local environment 105 to access the API environment 103.

The user runs an application on the device 107 that discovers a beacon 110 that is nearby to the user using wireless communication protocols such as NFC to discover the beacon's identifier, such as a UUID.

An application running on the user device 107 may wirelessly send a request to the search API 106 located in the API environment. The request includes a UUID, and the request includes a command that instructs the API 106 to search the database 104 for beacon identifiers stored in the database that match the beacon identifier discovered by the API running on the user device 107.

Once API 107 determines a match between the UUID associated with the detected beacon and the beacon identifier stored in the database, API 106 then searches the database for location data or, in other words, location identifier(s), associated with a matching beacon identifier stored in the database. The specific format of the location identifier (identifier) is described in more detail below.

Fixed Rack Solution

As an alternative to the portable solution, the user may use a workstation, also labeled 107 in FIG. 1 to access the API environment. This is referred to as a fixed rack solution. In this example, the location ID is passed transparently to the airline's backend service. The user does not have to take action in order to obtain a location identifier.

Thus, a fixed rack solution can perform the following steps.

1. When a workstation in a fixed location is installed and a field gateway is deployed, an identity is assigned to the workstation. Typically, this identification data is a location identifier.

2. When a user logs into an NGP system account to access their applications, the location ID is passed as part of the account login credentials.

3. The NGP system can then dynamically build an application icon menu that is displayed to the user, with each icon being a URL associated with backend services 141, 143, 145 based on airline applications. The URL has three associated parameters: LocationID, UserSessionID, and NGP URL.

These parameters provide all the information needed by the airline application based internal interface services 141, 143, 145 to subscribe to the location required by the user logged into the account.

Detailed steps and sequence messages

Unless otherwise noted, the various functional components shown in FIG. 1 and 3 may be implemented using an API call, such as a Representational State Transfer (REST) API call using the HTTP protocol.

Thus, the data within the messages shown in FIG. 3 are typically in the format of an alphanumeric string and an associated field specifying the data type, which may also be in the format of an alphanumeric string. Additionally, the various functional components shown in the API environment 103 and the application environment 109 may be implemented as various modules that connect to each other to communicate as needed between the various modules.

Referring now once more to the flowchart of the method of FIG. 3, the user is instructed to enter a username or user ID and password (UserLogin) to log in to an account on the NGP system. The user login message 3012 is therefore sent from the user device 107 to the API environment 103. The user login window is typically displayed in response to the user entering a specific URL in the browser as described above.

If the NGP API environment is provided as part of a cloud service, then any authentication steps required by the cloud service provider may be used. Typically, a certain number of users are granted access to the system, and user groups may be defined as belonging to particular associations or companies, such as a particular airline.

To access a particular URL, a security certificate may be provided to the user device. The security certificate can be provided through a separate channel and the certificate can be revoked at any point. Access to an NGP system is usually not granted unless an appropriate security certificate is provided.

Authentication services 114 then authenticate the user based on the credentials entered by the user.

After the user logs into the account, the configuration portal 115 or the authentication services application 114 determines whether or not the user is associated with a particular group of users, such as users who belong to a particular airline. This may be done by searching the database 112 for account security credentials, which may have a specific company or group identifier associated with them, such as an airline identifier.

If the user is using a portable device, the location of the portable device may be determined at this stage. This can be done by an application running on the client tablet computer or device 107 instructing a scanner or reader associated with the device to scan for or read the beacon identifier as described above, for example using near field wireless communication protocols. Alternatively, an application installed on a mobile device may be used in conjunction with a reader such as a camera to read or scan a QR barcode. The beacon or QR barcode is typically placed at predetermined positions within an airport where a user may desire a user's shared infrastructure. In the case of a QR barcode, the barcode contains data specifying a location identifier encoded in it. Alternatively, the user may simply enter the location identifier manually as soon as he is instructed to do so.

If the mobile device reads the beacon ID, the beacon ID is sent to the API environment from the user device 107 via a wired or wireless connection. The application 106 then searches the database 104 to find a beacon identifier that matches or matches the beacon identifier read from the beacon 110. API 106 then determines the location identifier stored in the database 104 that is associated with the location identifier that matches the beacon. Thus, API 106 is able to determine the location identifier associated with the beacon. Typically, all of the functional components shown in FIG. 1 of the drawings are able to access a location identifier (ID) associated with a particular beacon identifier, if necessary. The determined location identifier may then be transmitted back to the user device 107.

Thus, the NGP system and typically the API 10 6 running the application environment receives the location ID from the desktop workstation, or the API 10 6 running in the API environment 103 determines the location ID by searching the database 104 for the location ID , which matches the specific beacon ID. This is typically done in response to receiving, via API 106, a beacon identifier from user device 107.

In either case, an association is made between the location identifier and the particular user device 107 accessing the shared infrastructure 108. The user device 107 may have an associated identifier.

After the user successfully logs in to the account in the API environment 103, at step 3012, an account login event message 3013 is sent from the authentication services interface 114 in the NGP portal to the CUTE wrapper API 301. Typically, the account login event message 3013 contains the data user identification location in the form of a location identifier and a user session identifier called "user_session_ID". The user session ID may be generated by the Authentication Services API 114 . Those skilled in the art would be aware that a user session identifier identifies a user session and may be an alphanumeric string.

The account login event message can contain an optional airline ID or user group ID (ID). A region identifier such as "US", "US East Coast", "US West Coast", "Netherlands", "Ireland", and "Asia" may also be used. This is useful if, for example, several different instances of an API environment are to be provided in different locations, and therefore allows a global solution to be provided. The data in the event message can be in the format of an alphanumeric string.

In one specific example, the user_session_ID includes data specifying the user and data specifying the association or group with which the user is associated. For example, the data specifying the association may be a string such as "BA" or "AA", which may specify an airline as "British Airways™" or "American Airlines™", respectively. Other associations, such as those between ground operators, for example, may be associated with the user. Typically, the URL used to access the NGP system is used to translate, associate, or provide a connection between a location identifier, a user session identifier, and an airline identifier.

At 3014, the user is presented with a menu called "application menu" based on the login security credentials and the determined location ID. This can be done by sending, via one of the APIs in the API environment 103 (e.g., Authentication Services API 114), a call to the user device 107. Typically, the application menu is provided as a URL (which may be an alphanumeric line) that points to the corresponding application URL 141, 143, 145 in the airline's remote application environment 109. Thus, the menu may provide functionality that allows a user to perform one or more different functions, using a user device, in a particular airport local environment. Two specific examples of functions that can be performed by a user using user devices in an airport local environment 105 could be printing a baggage tag or boarding pass using one or more shared devices 108.

Thus, using one of the user devices 107, the user is able to click on one of the menu items, and this provides the ability to connect to the application in the airline's remote environment. A CITRIX™ application may be used to perform this step, although other applications may be used to remotely launch one of the applications 141, 143, 145 from one of the devices 107 in the airport's local environment 105.

The step of displaying the item menu and the functionality to enable one of the applications 141, 143, 145 to be launched remotely may be performed using an application in the API environment 103 (for example, using one of the APIs 111), which may be referred to as an NGP portal. - an application to search the database 112 for stored pre-configured settings specifying the types of applications available to the user at a particular location. This application may first authenticate the user and then determine which applications should be available to the user when logging into an account using the client device 107 in a particular local environment 105.

Thus, the NGP portal application 103 is able to determine which applications are pre-configured for that user based on location. Similarly, an airline may remove apps for a user based on the user's ID and location.

This is similar to the way in which specific devices, such as a baggage tag printer or a boarding pass printer, may initially be configured, at 3011, for a user in a particular location, such as using the configuration portal 115. This allows the configuration of specific devices 108 at local airport environment for specific users and for those devices and services to be published.

The airline may configure the desired applications 141, 143, 145 that are available to a particular user at a particular location by logging into an account on the configuration portal 115. A database 112 associated with the configuration portal API 115 may store settings that specify the type of application, which a particular user, identified by their user ID, has available when logging into an account at that particular location. For example, a user may have applications for printing a boarding pass or printing a baggage tag configured to be available when they log into an account. This can be done based on the user ID and location.

Thus, exemplary applications may be a boarding pass processing application or a baggage tag processing application that allows an agent or passenger to print or process a boarding pass or a baggage tag.

The application menu allows the user to select one of the available applications 141, 143, 145 in the remote application environment (LH application) 109 . This can be done through a published and signed communication between the NGP API system 103 and the CUTE wrapper application 301 shown in FIG. 3 from the drawings.

Typically, the CUTE shell application is located in the remote application environment 109, the CUTE shell client application 301 can act as an intermediary between the legacy airline applications 131, 134, 145 and the applications 111 in the AP I-environment.

One of the functions of the application 301 is to translate between different protocols in use. Additionally, the application 301 can also broadcast commands between the API environment 103 and the remote application environment 109 . Thus, the CUTE Shell Application 301 may be optional depending on the type of application used in the airline's remote environment. However, the underlying data exchanged between the NGP API environment 103 and the application in the remote airline environment 109 is generally identical whether or not a CUTE Shell Application is used.

In response to the selection, by the user, of one of the applications 141, 143, 145 indicated in the menu, the user device 107 then communicates with one of the applications 141, 143, 145 in the remote application environment 109 to run one of the applications 141, 143, 145 using message 3015. As indicated above, step 3015 is performed using a communication link with an application in the remote environment 109 of the airline. Thus, one of the applications 141, 143, 145 in the remote environment of the airport is started based on the information received in the message 3015, such as a client or user ID.

It should be noted that typically the link or message 3015 does not allow any associated parameters to be sent except for the URL. Thus, at step 3020, when a particular application 141, 143, 145 in the remote airline environment 109 is launched using a URL, one of the airline remote applications also typically makes a local call to the local CITRIX environment to determine a client identifier that can identify the device 107 that is running a particular user session.

Thus, when the CUTE wrapper functionality is used, typically, the previously determined location identifier is not sent to the application 141 in the remote application environment.

Conversely, when one of the applications 141, 143, 145 in the remote environment 109 starts, the application instance starts port forwarding. This allows one of the applications 141 to receive the client ID because the local CITRIX environment passes the client ID to the application 141 running in the remote application environment. It is typically sent from the user device 107 to the application 141 via the CITRIX interface in response to receiving, by the user device 107, such a request from the application or CITRIX interface in the remote application environment 109 .

For example, the client identifier may identify a particular user by name and identify the type of device used to run the remote application 141, 143, 145. Thus, the client identifier may be of the form "NAME_TABLET_1". The client or user device 107 transmits the client identifier to the CITRIX environment (which is typically located in the remote application environment), for example, via the communication means 129 . The above-described user login to an account is typically associated with specific customer identifier(s).

At step 3030, the application 141 sends a get device list message 3030 to the CUTE wrapper API 301. The device list message includes a specific client ID, usually as an alphanumeric string.

The CUTE wrapper API 301 then converts the received client ID to a previously determined location ID. Typically, the received client identifier is uniquely associated with a particular user and, therefore, with the device used by that user.

A get device list message 3030 sent by one of the applications 141, 143, 145 in the remote application environment to the CUTE shell API 301 instructs the CUTE shell API to provide the device list associated with the particular application 141 that is running.

Typically, message 3030 includes a specific customer identifier and data specifying the type of document to be processed, such as a boarding pass or baggage tag. Thus, message 3030 may contain text, such as alphanumeric text in the form "BP" or BT, which indicates that a boarding pass or a baggage tag should be processed, as appropriate.

After the CUTE wrapper API 301 receives the message 3030, it parses the content of the messages to determine the client ID and the type of document required. Additionally, the CUTE wrapper API 301 also has knowledge of the user session ID that is associated with that particular location ID, since the user session ID can be stored in a data store in the API environment for use by the CUTE wrapper API 301.

Client ID to Location ID CUTE Function The CUTE wrapper API can convert a client ID to a location ID.

To perform the conversion, the CUTE shell API 301 uses the information received in the account login event message 3013 . Thus, the CUTE can use the location ID and session ID received in message 3013 to map the received client ID to an associated location ID.

This may be done by performing a database lookup (eg, database 112 associated with the configuration portal) for a client ID that matches the client ID received in message 3030. The matching client ID stored in the database is associated with a location id or/and a user session id for a specific user. Similarly, converting a client ID to a location ID can be performed for a desktop workstation solution.

Thus, the CUTE wrapper API 301 translates the client identifier (which may be associated with a particular user or device) received in message 3030 into a location identifier (which may be associated with a particular user or device).

At step 3040, the CUTE wrapper API 301 sends a location subscription message 3040 to the configuration portal 115 in the API environment 103 to subscribe to a specific location via one of the API services 111 using the location identifier determined by the CUTE wrapper API 301 . Typically, a location subscription message contains parameters specifying a location ID and a user session ID.

The configuration portal API service 115 may send an acknowledgment in response to receiving a location subscription message 3040, although the message is not shown in FIG. 3 due to its optional nature.

Step 3040 is performed because typically the airline, and therefore users registered to use the system, must subscribe to a location before device operation can be requested. The following should be noted.

- The subscription is implicitly associated with the user's session. In other words, during the configuration process, when an airline application subscribes to or is associated with a location, it is assumed that the airline agent is using the application in question 141. Therefore, subscription requests are typically mandated to have a corresponding user session ID.

- One user can usually only have one active subscription per location; however, the user may initiate multiple subscriptions at different locations through the airline's application.

- One airline may have multiple users or agents subscribed to a location via the airline application(s) 141, 143, 145.

- The subscription is managed by the airline that has access to the location. The scheduler can be used to enforce this based on one or more rules.

The location subscription message 3040 typically contains a location identifier and user session identification information, and optionally an airport identifier parameter. As described above, the location identifier parameter specifies the location identifier of the workstation or portable device 107 being used, the user session identifier specifies the session identifier of the logged in user, the airline identifier may specify airline codes, such as an IATA member airline code, and is typically specified by alphanumeric strings. Optionally, the timestamp can also be included in the example 3040 location subscribe request JSON message shown below:

API service 111 in NGP API environment 103 receives message 3040 and communicates with device service interface 117 via messages 131 and 132 to determine the specific devices associated with a particular location, as well as the associated characteristics of each device. The information may be included in a message that allows it to be routed to one of the APIs 111 shown in FIG. 1 if more than one 1 API service 111 is provided.

Thus, the device service API 117 and the configuration portal 115 communicate with one of the API services 111 in the API environment 103 to determine the list of devices associated with a particular location identifier and their associated characteristics.

This can be done by performing a search on the database 112 using a particular application. The database 112 includes information about devices 108 that is associated with a particular user location, or more specifically, a location identifier.

The characteristics of the devices are returned in the CUTE wrapper API 301, which is usually part of the API environment 103.

The CUTE wrapper API 301 translates the received device characteristics into a JSON message type, shown as 121 and 122 in FIG. 1 and message 305 in FIG. 3.

The following is an example JSON message 3050 with a location subscription response:

Typically, device characteristics response message 3050 specifies the type of shared devices available, such as boarding pass reader (BPR), baggage tag printer (BTP), boarding pass printer (ATB), and each device has an associated location identifier.

The CUTE wrapper API 301 then uses the information received in the response message 3050 to generate a device list message 3060 that specifies devices available at a particular location.

The device list message 3060 may contain data specifying the type of document to be printed or, more commonly, the type of printer required to print the type of document. For example, ATP may indicate that a boarding pass printer is required in order to print a boarding pass. The BTP may indicate that a baggage tag printer is required in order to print the baggage tag printer. The LSR may indicate that a boarding pass reader is required in order to read the boarding pass.

Thus, an application running in the travel carrier environment 109 is able to receive a list of available devices at a remote location. This list of available devices is sent via the communication means 129 or 123 or 125, for example via the web proxy functionality 113 in the API environment. The user is able to select, using the user device 107, one of the available devices in order to print a particular type of document.

In response to the user's selection of one of the devices to print a particular type of document, the application 141 in the remote environment then sends a device open message 3070 to the CUTE shell Application 301 to open one of the devices in the device list. If only one device is returned in device list message 3060, then the CUTE wrapper API 301 generates one PM descriptor associated with the desired device. Typically, a PM handle uniquely identifies a particular device, during a particular user session.

The CUTE wrapper API 301 returns a PMHandle parameter to the application 141 in the remote application environment 109 .

If the device list message 3060 identifies more than one device 108, then typically a different PM descriptor parameter is generated for each individual device, and typically each parameter is unique to a particular session.

Thus, each device request originating from the LH application 109 is managed as a separate session, which is identified by the PM handle.

Message 3070 may take the form of a per-device XSPMOpen call based on the list of device configurations received (3060). It creates a session with the device, returns a PM handle. Call elements may include any one or more of the following:

PMRET PMENTRY XSPMOpen (PSZ DevName, PPMHANDLE, ULONG OpenOption, PSZ AirilinelD, SHORT DataWaitTime, ULONG Reserved).

The CUTE shell API 301 typically creates a PM handle, which may be unique for a particular session. The prrpm handle can uniquely identify one of the shared devices 108. The prrpm handle is typically returned to the remote API 109 using message 3080.

Message 3080 is typically sent in response to an XSPMOpen call.

The message can contain any one or more of the following code elements: PMSaveHandle, ChangedDataFlag, RequestType, Length, CRC, SequenceNumber, AppPMHandle, SaveAppBuffer, ChangedDataFlag, ActivityFlag, NotifySem, IPCHandle, AppBufferAddr, Command, PMHandle, ReturnCode, Status, LocalFlags, Version, DeviceName , AirlineD, UserName, OpenOption, WksName, ExtStatus, DevDwnFlushTime, DataWaitTime, Reserved

CUTE functionality for converting a specific PM descriptor into a device identifier (identifier)

When processing a specific print request, the CUTE shell API 301 includes functionality to translate a PM handle specifying a specific device that is configured to use the application 141 into a device identifier (ID). In one specific example, the device identifier may comprise a specific location identifier and an associated label. The transformation may be performed by comparing a stored PM descriptor associated with a particular device with stored data specifying a location identifier and a device tag.

As stated above, message sequences 3030, 3060, 3070, 3080 may be part of a single user session. Thus, the stored PM handle(s) is typically updated each time a new user session is initiated.

Messages 3081 and 3082 are schematic in that they indicate that the following subsequent steps are typically only performed in response to a specific request from user device 107 to print a specific boarding pass or baggage tag for a passenger or read a specific passenger boarding pass. Thus, the following steps can be triggered by a request, by the user, for a specific action to be taken.

Messages 3083 are also schematic and show how an application running in a remote airline environment can log into an account in a remote reservation or departure management system. This is optional since any passenger data, such as PNR data associated with a particular passenger, may be stored in system 100.

Example of printing a boarding pass or baggage tag

The following example focuses on a specific example of an agent or passenger using an application running on a device 107 to perform the function of printing a boarding pass or a baggage tag on a shared device 108 using an application 141, 143, 145 running in a remote application environment 109 that communicates with the local environment 105 of the airport via the API environment 103.

This assumes that certain passenger data, such as the name of a particular passenger, for example, is read from a passport or otherwise entered into an application running on one of the user's devices.

This information enables the reservation or departure control (DCS) system 102 to uniquely identify the passenger's booking and identify the data to be sent back to the application 141, 143, or 145.

Typically, to uniquely identify a particular booking, DCS 102 uses a combination of the credit card number used to make the booking and the passenger's name.

For example, the first four and last six digits of a credit card number, as well as an associated name, may be used to identify a particular booking. Alternatively, passport details such as name and date of birth may be used to uniquely identify a passenger's reservation. Additionally, a reservation locator, such as a reference number, may be used to uniquely identify a passenger's reservation.

Once a particular passenger's reservation has been identified in the internal interface DCS 102, it is possible to determine the data associated with the particular passenger's PNR. Thus, the system is able to determine which airport the passenger is flying to, for example, using the airport identifier, time spent in flight, flight number, and assigned seat. This data enables the issuance of a boarding pass for a particular passenger.

Additionally, if a passenger checks in baggage, DCS generates an identifier in the form of a registration number (LPN) for that baggage. The DCS returns the baggage information, airport ID and flight number, and any associated or linked baggage LPN to the airline's 109 application environment.

Thus, the remote application 141, 143, 145 can retrieve a reservation based on the Passenger Name Record (PNR) stored in the database. It is usually created when a passenger booking is created. Because a large number of PNRs may be stored in the database, each PNR is identified by a record locator.

Typically, each PNR contains any one or more of the passenger's name, ticket details such as the ticket number, the itinerary of at least one flight segment, and the name of the person providing the information or making the reservation. The route may be specified by the departure airport code (such as New York, NYC), the arrival airport code (such as London Heathrow, LHR), the scheduled departure date and time, and the scheduled arrival date and time.

This enables the issuance of a boarding pass or a baggage tag by the departure management system, for example using the scheduled departure time and the location of the departure airport.

Please note that baggage tags and boarding passes may be specified in IATA RPS documents such as IATA rules and RPs (practice guidelines) such as rule 740 as well as IATA RP1740a for processing baggage tags and rule 722e as well as IATA RP1723 processing boarding passes.

Typically, a GUI running on the user device 107 provides confirmation that an entry for a particular passenger has been found. Additionally, the data retrieved from the departure control system 102 is returned to one of the applications 141 in the application environment. The API service 111 provides one of the applications 141 with confirmation that the data has been successfully received and performs a routing function to route the data to the correct service in the device service interface.

At 3090, the particular application 141 selected for use by the user using the user device 107 sends a boarding pass or baggage tag print message 3090. This can be done using XSPMAPI messaging/communication. It specifies the libraries and links used by legacy applications.

Typically, the data included in the boarding pass or baggage tag print message 3090 is based on the AEA format.

Typically, message 3090 specifies the type of operation to be performed, such as printing a boarding pass or baggage tag. Additionally, the message contains data enabling the printing of a boarding pass or baggage tag. Usually, this data contains the name of the passenger, but may contain any one or more of the information specified above with reference to the assignment of the boarding pass or baggage tag.

Typically, message 3090 for printing a boarding pass or baggage tag uses a legacy RESTAV-based protocol to provide a layout for the boarding pass and baggage tag. Message 3090 is sent using TCP/IP socket communication based on the C language structure.

The message work data structure includes the data elements that are necessary in order to print a boarding pass or a baggage tag. For example, the message may include the passenger's name, flight number, exit, and seat number in alphanumeric format. The message is converted to a RESTAV template. The data message 3090 is structured such that the fields need not be identified. The message may include a field specifying the particular RESTAU template to be used.

Message 3090 may take the form of an XSPMWrite call. The call may include the details of a document to be printed, such as a boarding pass or baggage tag. The call may include one or more commands, such as the commands of the Association of European Airlines, for example:

PMRET PMENTRY XSPMWrite (PMHANDLE PMHandle, PPMDATABUFFER PPMBuf, ULONG WriteOption, HEV Semaphore, ULONG Reserved), which should be known to those skilled in the art.

The CUTE wrapper API then translates the 3090 message into a format that is suitable for processing by the NGP system to form the 3100 message.

The message 3100 is based on an HTML template, boarding pass or baggage tag data, and a template, and the CUTE shell API 301 generates, for example, an image print message 3100.

Message 3100 is typically JSON based using key/value pairs and sent using a web API. The CUTE wrapper parses message 3090 to identify specific fields, such as exit number or location, and is able to distinguish between these fields.

The CUTE wrapper API 301 shown in FIG. 3 converts the data from the legacy message log 3090 to the message log 3100. In other words, the CUTE wrapper API 301 translates the 3090 message into key/value pairs, and may also add information stored by the system 103. The CUTE wrapper API transforms the message 3090, for example, by using an HTML template for the boarding pass layout.

The CUTE wrapper service 301 then creates a boarding pass or baggage tag print message 3100, which is sent to the API environment 103, for example using a JSON message. This can be seen as a translation of the legacy print command into a new NGP print command and file.

The following is an exemplary format for a BP/BT print message 3100:

PrintDocumentRQ:

Thus, it should be taken into account that the message 3100 generated by the CUTE wrapper API may contain a location identifier (identifier)

(Locationld) and device tag. As described above, the location identifier may contain alphanumeric data such as "LAX-Tl-GateB21-WKS-001" or "JFK-T01-GATE03-WKS-002". In the exemplary print message 3100 shown above, the device tag is included in the "locator" field. From this, it can be seen that the shared printer device 108 is actually a baggage tag printer (BTR). However, a separate device label field and associated value may be provided in message 3100, for example, as key/value pairs. Additionally, message 3100 may contain any one or more of the fields shown in the above messages, such as any of the data required in order to print a baggage tag or boarding pass.

The following is an exemplary document print confirmation message 3130. An acknowledgment message 3130 may be sent by one of the applications in the API environment 103 to the CUTE wrapper API 301:

PrintDocumentAck:

An exemplary print document request message 3110 generated by one of 131 APIs, 132, 117 in API environment 103 is shown below. Message 3110 is generated based on information received in message 3100 by one of the applications in API environment 103. In the exemplary message 3110, a unique device identifier is provided that allows a particular device to be uniquely identified via the "DeviceId" field. The data associated with the print message 3110 is also included below as "CommandData" and may include any one or more of the data included in the message 3100 required in order to print or process the document in question, such as printing a boarding pass or baggage tag. The combination of a location identifier (ID) and a device tag can be used to uniquely identify a particular device to which a print request for a document is to be sent.

Request to print a document:

A globally unique identifier can be used as an alternative to using an identifier

locations and device tags in order to uniquely identify the shared device 108 to which the print message 311 is.

For example, during the initial system setup, the application in the configuration portal 115 generates a GUID (Globally Unique Identifier) or, in other words, deviceId: "413dc6c0a03d4d6a9cd2c1=". An API may be provided in the NGP system 103 that translates "413dc6c0a03d4d6a9cd2c1=" into a location ID and device label. The conversion of a device ID to a location ID and a device tag can be done by looking up, using an API, the data stored in the database.

An example JSON format for requests with file data and configuration:

Thus, alternatively or in addition to the GUID described above, a combination of location identifier and device tag is used to uniquely identify which shared device the boarding pass or baggage tag print message 3110 should be routed to. Thus, this message specifies the device to which the print request should be sent, in the form of a device ID. The location ID and label, such as ATP, can be mapped to a specific device ID.

The field gateway component, described in more detail below, can therefore store data specifying a device identifier, such as a location identifier and a tag. The field gateway component can also translate this information into a specific port number so that it can correctly determine which device the print message 3110 should be sent to.

The device services interface 117 selects a service for the correct devices, such as printing a boarding pass or a baggage tag. This is done based on information specifying the document to be printed. The selected service at 117 then selects the desired template required in order to print data according to a format such as a boarding pass or baggage tag specified by the RESTAV format and encodes the received data according to the format. Thus, an AMQP message sent to a shared device can be sent with PDF encoded data also specifying a document type such as a boarding pass or a baggage tag.

In the case of legacy boarding pass printers and baggage tag printers, the optional field gateway shown as FR in FIG. 1 that routes a message to one of the shared discovered devices based on a location ID and a device label such as ATP. The certificate is also used. It translates a location ID and a label, such as ATP, into a unique device ID.

In response to receiving a request message 3110 to print a boarding pass or baggage tag, the shared device 108 may send an optional acknowledgment message 3120. As indicated above, the API 111 may also provide an acknowledgment message 3130 back to one or more applications 141, 143, 145 running in the airline's shared environment, indicating that the request has been correctly received. Acknowledgment messages may be routed through a field gateway that receives an acknowledgment message 3130 from application 111 in the API environment.

As mentioned above, the API service(s) 111 perform the function of determining the type of request received from the application 141 in the application environment (for example, printing a boarding pass or baggage tag), determining which service in the device service interface 117 should process the request .

Finally, the document is printed on one of the shared devices 108 in response to receiving a message 3110 by the device. The passenger or agent then collects the document for later use.

This approach of having various device services in the device service interface 117 allows additional devices, such as payment devices, to be added without impacting the system.

In addition to boarding pass and baggage tag printing, other devices such as OCR, LSR, MSR and gate devices are supported using the same technology. In this example, the message structure is shown as 3150, 3160 and 3170 in FIG. 3 from the drawings.

Closing applications

The airline agent must log out of DCS and close the LH application. This should terminate the CITRIX LH application session with the CUTE wrapper service. The airline agent logs out of NGP and the client device returns to the account login screen. The NGP system then publishes an account logout event to the CUTE wrapper service, which allows the CUTE wrapper service to release all resources associated with the user session and the LH application.

Detailed Description of Router 118 and AMQP Protocol Messages

In the API environment 103, the router API 118 may be provided. It may perform a function similar to that of the API service 111. The router has the function of parsing a message received from one of the device service interface 117 . It has the function of routing messages 124 to the correct device 108 in the local environment.

The router 118 parses the message 124 received from the device service interface 117 . This may be done by parsing the message at the header information level, which specifies the device type. The header may uniquely identify which shared device 108 a particular message is to be sent to.

Each of the shared devices 108 undergoes a registration process in the API environment. As part of the registration process, each device 108 is issued a token. The token allows shared devices 108 to connect to cloud 119.

The token is included in the message header for message 124, and by parsing the token, the router API 118 can determine to which device in the airport local area 108 the message should be sent.

The device service interface 117 also processes the information received via the message 131, converts the data into a PDF message format. The specific device service interface 117 converts the received data into a PDF message format specifying a boarding pass or a baggage tag, defined, for example, according to the RESTAV format.

Additionally, in one specific example, the Advanced Message Queuing Protocol (AMQP) messaging protocol is used to send a message from the device provisioning interface 117 through the router 118 and typically also through the cloud interface 119 to the shared device 108. This is described in more detail with reference to FIG. 3 from the drawings. AMQP is an open standard for passing messages between applications. The AMQP data unit is referred to as a frame. Nine different frames are defined to initiate, manage, and terminate the message transfer. Messages are sent over the link using a data transfer frame. Messages on a communication link typically flow in only one direction.

In the example shown in FIG. 1 of the drawings, a web proxy service 113 is provided in an API environment. The web proxy service is typically operably connected to both the remote application environment 109 (and therefore one of the applications, such as 145 or 143 or 141 in the move application environment 109) and one or more user devices 107, shown in the local area 105 of the airport. Web proxy functionality can provide a GUI connection to airline applications. The web proxy service may also provide a GUI connection to a tablet computer, workstation, and kiosk display 107 in an airport environment.

However, the web proxy functionality 113 is actually optional, and in fact, user devices 107 can directly connect to the remote application environment 109 if the local airport can access, through the communication facility 129, the remote application 109 using wired or wireless internet. protocols that are known to those skilled in the art.

Description of the performance-based service provisioning interface

A capability-based service provisioning interface not shown in FIG. 1 from the drawings. Typically, this functionality is provided in the device service interface 117 . Alternatively, the performance-based service interface may be provided as a separate service API operably coupled to the device service API 117 .

Boarding pass scanners often include the ability to show light and emit sound. This provides an audiovisual indicator to the airline agents as to whether the boarding pass is validated or not. This can be done by any illumination means, such as a light emitting diode, and a speaker means arrangement. The specific choice as to whether or not the scanner emits light or sound, or both, also regarding the particular format of light or sound emitted, such as the number of intermittent beeps and flashes, is usually determined by the manufacturer of each device. In any case, these settings can be set and changed via the configuration portal.

Thus, airlines still have full control of settings for shared devices, but this is done through the configuration portal 115 rather than through the interface.

This allows the airline to perform remote configuration for a particular airport for a particular user so that he can control the number of acknowledgment beeps when a boarding pass is acknowledged. This provides for characterization of devices without characteristics passing through the interface. Thus, airlines have the ability to set configuration settings for the shared infrastructure through the configuration interface. This eliminates the need to put configuration settings in the interface, and also eliminates the need for applications to know how the shared infrastructure interface works.

In a further example, regarding the use of a shared infrastructure, when an airline agent scans a boarding pass, configuration settings may be selected such that the device is blocked until the scanning device receives a response from internal interface systems regarding the validity of the boarding pass.

Thus, configuration settings may be selected such that after a boarding pass is scanned, a visual indicator is provided to indicate that additional boarding pass scans may not be performed. For example, if an LED indicator is used, it may change to red to indicate that additional scans may not be performed.

The capability-based service interface determines the type of data and data configurations required by each of the shared devices 108. Typically, a database 112 is provided that stores the capability settings and configuration settings associated with each device.

Thus, the device interface 117 can be properly configured to interact with each of the shared devices by performing a database search for physical devices, or in other words, a basic list of physical devices 112 and their associated characteristics and configuration settings. Features and/or configuration settings may vary based on airline preferences and not necessarily based on location.

Subscriber airlines can view and modify the database of device characteristics through the configuration portal 115.

To illustrate the above, in one specific example, suppose an airline agent uses a shared boarding pass reader to scan or read a passenger's boarding pass when the passenger boards the aircraft.

Certain details are read from the boarding pass, such as the passenger's name. This data is referred to as boarding pass data. The passenger's name, in combination with any one or more of the current date and time and airport code, may be sufficient for one or more internal interface systems, such as the departures control system 102, to verify that the boarding pass includes the data that match the passenger in the Passenger Name Record (PNR) database.

If the boarding pass scanned by the agent is confirmed, the departure control system 102 sends a boarding pass confirmation message to the remote application environment 109 . It is received by one of the applications 141, 143, 145 in the remote application environment and transmitted via 121 to the API service 111 and then from the API service via 131 to the device service interface 117. The device service interface 117 then passes this message through 124 to the shared device scanner 108.

The scanner device may indicate that the scanned boarding pass is validated by the departure management system by providing one or more indicators. These indicators can in principle take any form, as device manufacturers and airlines can configure default settings based on their own preferences. However, for example, the scanner may indicate that a boarding pass is being validated by lighting a green LED and/or optionally generating a sequence of intermittent beeps or audio indicators.

It is the performance-based service API labeled CS in FIG. 1 obtains this device characteristic data from the database. The performance-based service API is typically located in device services 117 .

Typically, a list of devices is provided. The list may identify a particular device. Associated information specifying a device capability may be provided, such as indicating that the device can read a boarding pass or a baggage tag. Configuration settings are usually set for each device. They may refer to specific configuration settings that indicate whether or not a particular boarding pass is validated by the internal flight control interface. In one particular example, the settings may specify the number of blinks of an LED or the number of sounds emitted by the speaker device to confirm that a boarding pass has been validated. Typically, specific subscriber airlines must specify the specific configuration settings they wish to use.

Capability-based services are typically configured as part of the initial system configuration when shared devices 108 are configured to be shared. Part of the configuration process is to enumerate the physical shared devices 108 that are available in the local environment 105.

Once a determination has been made as to which shared devices 108 are available in the local environment 108, the physical characteristics of each device are then determined. Thus, for each device 108, a list of associated physical characteristics is defined. The performance settings and configuration settings associated with each device are typically stored in the database 112 .

For example, suppose shared device 108 is a DESCO™ VGR device. This device may have any one or more of the following: passport reader/scanner, boarding pass reader/scanner, credit or debit card reader/scanner, or exit boarding control function.

The exit boarding management function refers to a process that is typically performed by an airline agent to check a passenger's boarding pass by scanning it with a reader and sending the data associated with the boarding pass to an internal interface system, such as a departure management system. Thus, data such as name and seat number can be read from the DCS and sent back to the shared device. The agent can then manually verify that the information determined from the DCS matches the information on the boarding pass.

From the above, it should be taken into account that this VGR device has 4 configured characteristics.

Thus, for an application that subscribes to a particular location that has such a VGR device, all of the above characteristics are listed.

It should be appreciated that the exit boarding control function controls access to boarding the aircraft.

As part of the exit landing control function, the following steps may be performed.

- Scan or read your boarding pass.

- After that, the device is configured to light a red indicator, which indicates that the device is locked. This prevents others from scanning until the internal front-end DCS is able to access the database.

- Once the DCS has verified that the boarding pass read matches the boarding pass validly issued (for example, the passenger's name and seat number read from the boarding pass matches the data stored in the DCS), an acknowledgment command may be issued by the DCS and transferred to the device. Receipt of an acknowledgment command may be signaled by a green LED, or by one or more audio indicators.

- They can signal to the agent that DCS confirms that a valid boarding pass with the name and seat number of a particular passenger has been issued.

- The agent can also cross-check to confirm that the boarding pass information shown on the boarding pass matches the passenger details shown on the passport or ID card.

As a second example, the device may be an ACCESS™ VGR device. This device has only one characteristic, namely to function as an exit boarding control function, and it cannot read a passport or read a credit card. Thus, if a particular application in the remote application environment 141, 143, 145 is subscribed to that device at a particular location, then that one characteristic is listed next to that device.

For each device, configuration information associated with the shared device 108 is stored. For example, configuration settings may be associated with specific settings selected to provide audio or visual confirmation of the confirmation message, such as a specific selection regarding the number of short beeps, such as 1, 2, or 3, to indicate that the boarding pass is being validated. .

This configuration information is conveyed via message 124. This is in contrast to known systems where such device configuration information must pass through all functional components via messages 125, 123, 121 and 131.

The feature-based service provisioning interface provides individual services for devices that are defined by device features rather than device brands and models. This abstracts device management and any knowledge of physical devices from the airline/airport application. This involves enumeration and segmentation of a huge number of device characteristics and a separate assignment to a basic list of physical devices. Thus, a database or list of device characteristics (which may be deployed as one of the shared devices 108 in the airport environment) may be provided. The list or database may be stored in the storage device 112 . Similarly, the database 104 may be stored on a data storage device.

Thus, it should be appreciated that the key functionality provided is to integrate future devices with API data without having to change the applications and usage characteristics of future devices in order to provide a rich user experience.

The API 111 provides controlled and controlled access for devices 107, 108 at the airport to applications 141, 143, 145 in the remote environment of the airport 109 based on interface and configuration settings. Airport administrators can independently configure airport devices 107, 108 and applications 141, 143, 145 in the configuration portal API, thereby making them available to airlines, ground handlers, and other entities operating locally or remotely at the airport. Airline administrators can independently configure users and applications and assign them to devices at airports, ensuring they are immediately operational. Airlines and airport administrators can create additional administrators and delegate some or all areas of responsibility.

Description of sharing, by several different users in an identical location, identical shared infrastructure

Embodiments of the invention may handle multiple different users of different user devices that are in the same or similar location and who may want to use the same shared device. This is achieved by providing a set of rules on how devices are shared by more than one user. In the case of a printer, the rules may simply allow more than one different user to connect to the printer and print jobs are scheduled in the order in which they are received.

For shared infrastructure such as a scanner or a credit/debit card reader, the rules may need to be more precise. For example, an application requesting the use of such a scanner or reader may need to send a query to the reader to determine whether or not the device is available.

Several different users may share the data channel 124 and the graphical user interface (GUI) channel 125 shown in FIG. one.

Thus, it should be appreciated that the rules engine can be used to regulate device sharing rules between and between airlines, as well as between different users belonging to the same or different airlines. For example, it should be appreciated that check-in devices may be shared with different airlines, but the device must still be in an idle state in order for a user to access a shared kiosk.

Backward Compatibility Resolution

The unique feature of the above solution is the ability to accommodate legacy airline applications and the standards surrounding legacy devices, and still deliver many of the above benefits to consumers. This is achieved by delivering peripheral communications and airline applications through separate paths in the platform.

- Existing airline applications are delivered to the end station from the Microsoft™ Azure™ cloud using server computing technology, instead of requiring local installation.

- Calls from legacy applications to the legacy system's API are routed through the translation software layer, which injects messages into the new platform and delivers responses in the correct format. This allows legacy applications to be used without extensive modification.

- Peripheral traffic is therefore separated from the application that generates it, providing a more flexible delivery/deployment model.

- Legacy peripherals often require sophisticated PC hardware deployed at the Web site to keep them running. Our platform allows these endpoints to be managed from Azure-based systems instead of being based on additional hardware deployed at the point of service.

- Consumers can access their legacy applications either from a traditional fixed location at an airport or from a remote location with Internet access.

When this data is received, it can be parsed.

NGP interfaces

The platform presents core functionality from two logical perspectives: from a consumer (airline, airport, operator, etc.) perspective and from a device/location perspective. These interfaces are unique in that they provide full access for an object to perform all of its processes, although their operation and implementation are much simpler known systems.

Airline/Airport interface

Embodiments of the invention may have the following advantages: very simple airline interfaces, full device functionality available through this simple interface, roaming and mobile connectivity, simple ubiquitous web applications, extremely flexible and powerful configurations, directly connected smart devices, no workstations and high degree of security.

The airline and airport interface forms the core services that consumers can access and use. The interface, through abstraction, provides a simple layer through which airlines and airports access services for devices, for security, for configuration, and for monitoring. The platform services in turn implement many checks and balances, some of which are configured by the airline, airport, and others by the platform. The interface, while simple, hides several layers of complex interaction with the platform that provides authorization, authentication, and validation of users, requests, and data. The intelligent platform also tracks itself through machine learning technologies to understand expected behavior, monitors for any deviations, and has the ability to take corrective action.

Description of the machine learning module

In one particular embodiment, a machine learning or deep learning module may be provided in API environment 103. The machine learning module may perform streaming analytics. It can track communications between the remote application environment 109 or the local airport environment 105, or both. For example, specific behavior may be determined, such as the number of passport-shaped documents read by one of the shared devices 108, per minute. If the number exceeds a predetermined threshold, then a flag may be provided. This may allow the operator to analyze the behavior and determine whether or not the behavior should be allowed. Access to the API environment may be denied in response to a determination that the number of reads per minute exceeds a threshold. Likewise, the machine learning module may be configured to keep track of the number of readers or scanners receiving a message from the API environment. Likewise, if this value exceeds a predetermined threshold value, then this may indicate a security breach of the system. Because of this, access to the API environment 103 may be denied based on the definition. Thus, a library of acceptable behaviors can be generated for each shared device 108 and user device 107.

All functionality of the device is open to access through uniquely designed high-level interfaces. These interfaces are designed for industry-wide legacy devices that normally have legacy interfaces such as serial and stringent latency and message framing requirements (link layer).

Platform interface

The platform exposes several internal interfaces that are used to implement platform functionality such as: device services, location services, security services, monitoring services, account login logging services, management services, configuration services, etc. .d. The unique messaging framework is designed to move the required data to/from the platform in either direction, either cloud to device (airline to device) or device to cloud (device to airline). Built-in mechanisms are created to calculate the message transmission delay for performance measurements and provide corrective actions if the delays reach the performance limit. The platform interface also abstracts complex bottom-composed monitoring solutions that provide access to platform-wide information on operations, functionality, and business processes. This information is available in real time, on a global scale, to all partners and consumers using the platform. The platform allows airlines to continue to use their existing business processes, software and hardware while still being able to enjoy all the flexibility, management and service features that this environment has always required.

Field Gateway Service

The field gateway service shown as FG in FIG. 1 of the drawings, the download package is typically initiated in response to a connection to the configuration portal 115. As part of the package download, the associated security certificate is also downloaded with the package. One location identifier (ID) is defined as above, the location identifier is passed to the service based on the field gateway. The field gateway based service connects to the API environment 103. The field gateway uses the downloaded certificate and the previously defined location identifier. Thus, the field gateway uses a certificate and a specific location identifier in order to connect to the configuration portal. This allows the configuration portal to determine the specific configuration required for devices at that location.

The configuration service 115 receives the request from the field gateway and uses the specific location identifier to determine which devices are associated with a particular location and the particular configurations required for those devices.

All device tags are registered with the IoT hub and a token is associated with each tag and therefore device.

The field gateway service provides remote connectivity for legacy baggage tag printers and boarding pass printers. The port to which the printer is assigned determines whether the printer is a boarding pass printer or a baggage tag printer. For example, baggage tag printers are typically assigned to port 07.

Thus, a field gateway-based service can determine the type of printer based on which print port the printer is assigned to.

The field gateway is used for legacy devices such as a custom baggage tag and boarding pass.

The combination of the field gateway, device certificate, location ID, and device tag provides the ability to uniquely select one of the shared devices 108.

The following is a further description of how a particular device, such as, for example, a boarding pass or baggage tag printer, can be uniquely identified using a location identifier and a device label (LocationID.Device_Label). It has particular application to legacy legacy printers or devices that may need to be compatible with a system, method, and device in order to provide access to a shared infrastructure or devices.

In this example, the field gateway (FG) functionality shown in FIG. 1 of the drawings may include a module or API that may be installed on a workstation that may form part of, or connect to, one of the shared devices 108 shown in FIG. 1 from the drawings.

During configuration, an agent with the correct credentials launches a portal, usually on a workstation. The workstation is operatively connected to the API environment 103 via wired or wireless communication protocols. The list of possible location identifiers retrieved from the database 104 is transmitted to the portal. The list is usually returned in response to a request for location identifiers. Typically, location identifiers are associated with specific areas, regions, or more specifically zones at specific airports.

The user then selects a particular location identifier that matches his current location, for example, the location identifier "MUM-T1-SBD-001" may be recognized by the user as being associated with "Mumbai Airport Terminal 1 Auto Bag Drop Area 001".

Another example of a location identifier is "JFK-T1-GATE1-WKS-001", which may be recognized by the user as being associated with "USAirport, John F Kennedy Terminal 1 Gate 1 Workstation 001".

Alternatively, the user may scan beacon 110 that is located in close proximity to the location where the workstation and associated shared device 108 are positioned.

The device_label may take the form "MSR", which may indicate that the device is a swipe magnetic card reader used to read a loyalty or credit card. Other types of devices or tags may be an ATP indicating that the device is a baggage tag printer or a boarding pass printer referred to as "ATP (Automatic Ticketing and Boarding Pass Printer)", indicating that the device is a boarding pass printer. coupons as described above.

The selected location identifier is then passed to the API environment 103. The API environment then generates an initialization file, which may contain any one or more of the following fields:

Contents of the initialization file:

The initialization file may be encrypted using a PGP signature and stored in an Azure Blob storage container ("FglnitFile" container) or storage engine or database 104 . Within this container, a subcontainer for each location ["FgInitFile_<LocationId>.lck"] may be provided. This file is typically saved and accessible with a SAS token with a 4-hour expiration date.

The user is then instructed to load the initialization file. The initialization file is also usually copied to a USB flash drive manually. This must be done before the token expires.

Upon startup, the field gateway component searches for initialization for a file that may be named "FgInitFile_*.*.lck". If the field gateway component successfully locates the initialization file, it sends a request to the location service, which may be part of the API environment 103, to obtain a security certificate for each shared device 108 or service running on the workstation.

To obtain a security certificate, the field gateway component or service invokes a location configuration service, which may be part of the API environment 103, to obtain the certificate.

When the location service receives a request for a security certificate, it validates the token (to confirm, for example, that the token is valid and has not expired). The location service may also validate the LocationId, or in other words, verify that the received LocationId matches one of the previously stored LocationIds stored in the database 104.

Typically, if both the token and the LocationId are valid, then the Location Configuration Service contacts the CA server to obtain a security certificate. Then, the location service sends the public key to the field gateway component.

After the certificate is installed on the workstation, the Field Gateway component calls the Certificate Enrollment API to add the certificate to the Active Directory or database. The above process for downloading an initialization file and obtaining a certificate can be performed for each workstation service or shared device connected to the workstation.

Once the certificate is installed in the FG, it must call the configuration service GetDeviceConfiguration in order to get the device configuration. The device configuration initially only needs to have a workstation device ID and its key in order to communicate with the IoT, other device information is not provided because the device states are a "no configuration" state.

Typically, the field gateway functionality stores or caches the "LocationId" locally in memory for future calls to the configuration service.

From the above, it should be appreciated that the location identifier of the workstation (and therefore associated shared devices (108) connected to the workstation) as well as the Device_Label can be used to uniquely identify a particular shared device that should be be identified. Thus, this can be used to determine which device specific print requests should be sent to based on location.

In some implementations, shared devices such as baggage tag printers or boarding pass printers may be associated with specific workstation ports. For example, a boarding pass printer may be associated with "port 1" while a baggage tag printer may be associated with "port 2". In some implementations, specific device types are always associated with specific port numbers: for example, boarding pass printers may always be associated with port 1, while baggage tag printers may always be associated with port 2.

Thus, it should be appreciated that shared devices interact with the platform on IoT protocols, such as the messaging protocol for MQ telemetry transport or message queue telemetry transport (MQTT). To enable this, existing legacy devices, which may not have interfaces based on the Internet and high-level messaging protocols, have a field gateway interface. The field gateway implements device-level functionality and manages complex security interactions with the platform to ensure that verified devices begin to communicate by fetching encrypted tokens and applying them to device-to-device communication. The field gateway also takes several local actions based on device data to provide high speed performance based on predefined configurations.

From the above, it should be appreciated that a mobile communication or device may include a computing device such as a desktop computer, a laptop computer, a tablet computer, a personal digital assistant, a mobile phone, a smartphone, an Internet-enabled TV set, a TV set with Internet-enabled game console, Internet-enabled game console, or handheld gaming device.

It should also be appreciated that this invention finds use as a system for treating a user or consumer, a device such as a portable device for use by a consumer treatment agent, or a device such as a portable device for use by a passenger, as well as a method or computer programs for handling the consumer or passenger. In addition, this invention finds application as a system for providing services to a consumer or user, which can be used by an agent of an airline or other agent of a transport service provider.

The server may include a computer processor that runs one or more server processes to communicate with client devices. Server processes contain machine-readable program instructions for performing the operations of the present invention. Machine readable program instructions may be either source code or object code written in/in any combination of suitable programming languages, including procedural programming languages such as C, object oriented programming languages such as C#, C++, Java , scripting languages, assembly languages, machine code instructions, instructions based on instruction set architecture (ISA), and state data.

The wired or wireless networks described above may be a public, private, wired, or wireless network. The communications network may include one or more of a local area network (LAN), a wide area network (WAN), the Internet, a mobile telephone system, or a satellite communications system. The communications network may comprise any suitable infrastructure including copper cables, optical cables or fibers, routers, firewalls, switches, gateway computers, and edge servers.

The system described above may include a graphical user interface.

Embodiments of the invention may include an on-screen graphical user interface.

The user interface may be provided, for example, in the form of a widget embedded in a website, as a device application, or on a dedicated web landing page. Computer-readable program instructions for implementing a graphical user interface may be downloaded to a client device from a computer-readable storage medium over a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and/or a wireless network. The instructions may be stored on a computer-readable storage medium in the client device.

Those skilled in the art will appreciate that the invention described herein may be embodied in whole or in part as a method, data processing system, or computer program product including machine-readable instructions. Accordingly, the invention may take the form of an all-hardware embodiment, or an embodiment combining software, hardware, and any other suitable approach or equipment.

The computer-readable program instructions may be stored on a non-volatile tangible computer-readable medium. The computer-readable storage medium may include one or more of an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, a portable computer disk, a hard disk drive, random access memory (RAM) Read Only Memory (ROM), Erasable Programmable Read Only Memory (EPROM or Flash Memory), Static Random Access Memory (SRAM), Compact Disc Portable Read Only Memory (CD-ROM), Digital Versatile Disc (DVD), memory cards in Memory Stick format, floppy disk.

Exemplary embodiments of the invention may be implemented as a circuit board that may include a CPU, a bus, RAM, flash memory, one or more ports for operating connected input/output equipment such as printers, a display, keypads, sensors, and cameras, ROM, a communication subsystem such as a modem, and communication media.

The flowchart of the method according to FIG. 3 illustrates the operation of an exemplary implementation of systems, methods, and computer program products in accordance with various embodiments of the present invention. Each block in the flowcharts or block diagrams may represent a module containing one or more executable computer instructions or part of an instruction to implement the logical function indicated in the block. The order of the blocks in the diagram is for illustrative purposes only. In alternative implementations, the logic functions illustrated in particular blocks may occur out of the order shown in the drawings. For example, two blocks shown as adjacent to each other may be executed simultaneously or, depending on the functionality, in reverse order. Each block in the flowchart may be implemented in software, hardware, or a combination of software and hardware.

Claims (41)

1. A data processing system for providing user access to one or more devices (108), and the system contains a processing means (103) configured to: i. determine the location identifier for the user; ii. associate a location identifier with a user identifier for the user; and iii. transmit (3013) the location identifier and the associated user identifier to the application (301), wherein the location identifier specifies the location of the device according to a hierarchical structure stored in the database, where each location identifier is associated with a predefined location and a hierarchical tree is provided specifying the location relative to each predefined location. 2. The system of claim 1, wherein the processing means (103) is further configured to receive a message (3012) about a user account login event associated with the user, preferably the processing means (103) is further configured to generate an identifier of a user session for the user, wherein the user session identifier is preferably associated with the user's login event, further preferably the processing means (103) is operatively connected to the sending or receiving means for sending or receiving one or more messages or data. 3. The system of claim 1 or 2, wherein the processing means (103) is further configured to generate an account login event message (3013), preferably in response to receiving a user account login message (3012), wherein preferably, the processing means (103) is further configured to send a user account login event message to the application (301). 4. The system according to any of the preceding claims, wherein the location identifier comprises an alphanumeric string, wherein preferably the location identifier is machine readable and human readable, preferably the location identifier specifies a predefined area associated with said one or more devices, preferably the location identifier associated with a major transportation hub, in particular an airport, preferably the location identifier specifies a location at a location in a predefined region or area. 5. The system according to any one of the preceding claims, wherein the location identifier specifies each location of the device in a plurality of different areas, preferably at least some of these different areas define a sub-area that is contained in one or more of the other areas, and at the same time further preferably, each subregion defines a portion or part of said one or more of the regions. 6. The system according to any of the preceding claims, further comprising an application (101, 111) for receiving a message (3100) containing the first data specifying the data to be processed by one of the devices (108) in response to a request from the user, and when this preferably the first data contains this or any location identifier associated with the user or additional user. 7. The system of claim 6, wherein the first data further comprises any one or more of a device tag associated with the location identifier, wherein preferably the first data comprises an additional location identifier concatenated with the device tag, preferably the first data is associated with a user session identifier , wherein preferably the first data contains data specifying a document to be processed by one of the devices (108), wherein preferably the first data contains a location identifier associated with a user or additional user, while preferably the first data contains data specifying a boarding pass or baggage tag. 8. The system according to any one of the preceding claims, wherein the application (101, 111) is configured to generate an additional message (3110) for processing at least some of the first data. 9. The system of claim 8, wherein the additional message (3110) contains data for printing or processing a document such as a boarding pass or baggage tag, preferably the data for printing a boarding pass or baggage tag is encoded in the additional message (3110) according to the format files of portable documents, and additionally preferably additional message (3110) contains data associated with the boarding pass or baggage tag, including data specifying any one or more of flight number, departure date, class, origin, destination, boarding gate, seat number, passenger name and seat number, unique baggage identifier, and stopovers between origin and destination, and preferably the message contains a format associated with the boarding pass or baggage tag. 10. The system according to any one of the preceding claims, wherein the processing means (103) is operatively connected to the first communication channel (124) and the second communication channel (125), preferably the first communication channel (124) is connected or associated with the second channel using location identifier. 11. The system of claim 10, wherein only data specifying the document to be processed is transmitted over the first communication channel (124), and preferably only data specifying device characteristics associated with said one or more devices (108) , are transmitted over the second communication channel (125). 12. The system according to claim 10 or 11, in which the processing means (103) is communicatively connected to the third communication channel (121, 122) and the fourth communication channel (123), while preferably the third communication channel (124) is connected or associated with the fourth communication channel using a location identifier. 13. The system of claim 12, wherein only data specifying the document to be processed is transmitted over the third communication channel (121, 122), preferably only data specifying device characteristics associated with said one or more devices (108 ) are transmitted over the fourth communication channel (123). 14. The system of any one of the preceding claims, further comprising a field gateway (FG) module or application for uniquely identifying one of the plurality of devices (108) based on a location ID and device tag associated with the device, preferably the location ID and device tag being provided in concatenated field in the message (3100), preferably the system further comprises a module or application (117, 118) for uniquely determining which of the plurality of devices (108) the message should be sent to (3110) based on the unique device identifier associated with each device, and preferably the system further comprises one or more devices (108) for processing data or a document, and preferably the document is a boarding pass or baggage tag, and preferably these one or more devices (108) are additionally configured to print or read data or document. 15. A method for processing data to provide user access to one or more devices (108), the method preferably being carried out in a computer processor, the method comprising the steps of: i. determining a location identifier for the user; ii. associating a location identifier with a user identifier for the user; and iii. transmitting (3013) the location identifier and the associated user identifier to the application (301), wherein the location identifier specifies the location of the device according to a hierarchical structure stored in the database, where each location identifier is associated with a predefined location and a hierarchical tree is provided specifying the location relative to each predefined location. 16. The data processing method according to claim 15, further comprising the steps of: receiving a message (3012) about a user login event to an account associated with the user, and generating a user session identifier for the user, wherein the user session identifier is preferably associated with a user login event. 17. The data processing method according to claim 15 or 16, further comprising the steps of: generating an account logon event message (3013) in response to receiving the user account logon message (3012), and sending a user account login event message to the application (301). 18. The data processing method according to any one of claims 15-17, wherein the location identifier comprises an alphanumeric string, wherein preferably the location identifier is machine readable and human readable, wherein preferably the location identifier specifies a predefined area associated with said one or more devices, and preferably the location identifier is associated with a major transportation hub, in particular an airport, while preferably the location identifier specifies a location at a location in a predetermined area or area. 19. The data processing method according to any one of claims 15 to 18, wherein the location identifier specifies each device location in a plurality of different areas, preferably at least some of these different areas define a sub-area that is contained in one or more of other regions, and additionally preferably each sub-region defines a portion or part of said one or more of the regions. 20. The data processing method according to any one of claims 15 to 19, further comprising receiving by means of the application (101, 111) a message (3100) containing first data specifying data to be processed by one of the devices (108) in response to a request from the user, and preferably the first data contains this or any location identifier associated with the user or additional user. 21. The data processing method of claim 20, wherein the first data further comprises any one or more of a device tag associated with the location identifier, wherein preferably the first data comprises an additional location identifier concatenated with the device tag, preferably the first data is associated with the identifier user session, wherein preferably the first data contains data specifying a document to be processed by one of the devices (108), wherein preferably the first data contains a location identifier associated with a user or additional user, and preferably the first data contains data specifying a boarding pass or a baggage tag, wherein the application (101, 111) is configured to generate an additional message (3110) to process at least some of the first data. 22. The method of processing data according to claim 21, in which the additional message (3110) contains data for printing or processing a document, such as a boarding pass or baggage tag, and preferably the data for printing a boarding pass or baggage tag is encoded in an additional message (3110) according to the file format of portable documents, and additionally preferably additional message (3110) contains data associated with the boarding pass or baggage tag, including data specifying any one or more of flight number, date of departure, class, point of departure, point destination, boarding gate, seat number, passenger name and seat number, unique baggage identifier, and stopovers between origin and destination, and preferably the message contains a format associated with the boarding pass or baggage tag. 23. The data processing method according to any one of claims 15 to 22, wherein only data specifying the document to be processed is transmitted over the first communication channel (124), and wherein only data specifying device characteristics associated with said one or more devices (108) are transmitted over a second communication channel (125), wherein the first communication channel (124) is associated or associated with the second channel using a location identifier. 24. The data processing method according to claim 23, wherein only data specifying a document to be processed is transmitted over the third communication channel (121, 122), and wherein only data specifying device characteristics associated with said one or more devices (108) are transmitted over a fourth communication channel (123), wherein the third communication channel (124) is associated or associated with the fourth communication channel using a location identifier. 25. A data processing method according to any one of claims 15 to 24, further comprising the steps of: uniquely identifying one of the plurality of devices (108) based on the location ID and device tag associated with the device, the location ID and device tag being provided in a concatenated field in the message (3100), and uniquely determine which of the plurality of devices (108) the message should be sent to (3110) based on the unique device identifier associated with each device, wherein the document is a boarding pass or a baggage tag, wherein one or more devices (108) are further configured to print or read data or a document. 26. A computer-readable storage medium that stores computer-executable instructions that, when executed by a processor in a computing device, cause the computing device to perform the method of any one of claims 15-25.

Images