Secure communication system and method

Abstract

A method of secure communication between a device and a computer program running on a server is disclosed. The method comprises the steps of: transmitting generic user identification information based on a current user account logged in on the device from the device to the server; identifying, by the server, the generic user identification information as corresponding to an allowed entity pre-registered to the server; sending an identification token associated with the permission entity from the server to a remote management module, wherein a registry of registered equipment is stored on the remote management module; running, by the remote management module, a remote action on the device using registry entries stored for the device, where the remote action communicates the identification token to the device; sending the identification token from the device to the server; and allowing the device to access the computer program based at least in part on a match between the identification token sent by the server and the identification token received by the server from the device.

Description

Technical Field

[0001] This application relates to a secure communication system and method, and more particularly to a system and method for secure communication between a device and a computer program running on a server. In some embodiments, the computer program may be a virtual agent function running in an omnichannel system. Background Technology

[0002] Omnichannel customer engagement refers to a company's ability to provide its customers with access to its products and services through multiple communication channels, thereby delivering a seamless, integrated customer experience. It allows customers to reach you anytime, anywhere, and the conversation and its context are maintained as customers switch between different channels. They can initiate a contact with the company by phone, continue the conversation via email, and then interact with a support agent via chat, maintaining continuity throughout the conversation.

[0003] The company is also adding automated bots to these omnichannel systems to provide virtual agent functionality, enabling more immediate responses to its customers. Chatbots are a great way to get responses to common, frequently asked queries. Similarly, voice bots are replacing traditional interactive voice response (IVR) systems to deliver conversational customer experiences via voice.

[0004] Omnichannel solutions are already being offered by companies in enterprise-to-customer scenarios, typically in call center environments, such as airline or travel industry customers inquiring about their bookings or flights, or customers inquiring about their plans or devices through their telecommunications providers. In such cases, users typically authenticate by entering their username and password each time they access the omnichannel system.

[0005] These known omnichannel solutions have several limitations in their application across certain industries, particularly regarding user security and authentication. For example, the Air Transport Industry (ATI) and other transportation and passenger handling industries face a unique set of challenges in customer support. Particularly within ATI, the customers of companies providing omnichannel systems can include airlines and airport operators, rather than direct customers of the general public. Furthermore, customers may employ a range of third-party vendors (so-called “indirect customers”), such as ground service personnel, who need to interact with the omnichannel system to access customer and technical support. Such situations can lead to difficulties in authenticating individuals attempting to connect via communication channels.

[0006] Specifically, companies operating in industries that do not directly interact with end customers do not manage all specific user identities of their customers—that is, all specific employees of those customers. Specific user identity management is the responsibility of the organization employing them. Furthermore, all employees of external users (such as third-party vendors) are not registered in the omnichannel system. This creates problems when enabling self-service functionality through virtual agent features. Access to data and functionality should be limited to portions owned by or associated with a specific customer. Because specific user identities cannot be verified, it is impossible to securely authenticate users, and therefore impossible to securely provide access to data and actions associated with a specific customer. Controlled access to customer data and backend services to automate problem-solving without user authentication is not permissible, as there is a risk that one customer may access another customer's data. At most, only general public information should be provided in the response.

[0007] It should be understood that the expectation is to provide an omnichannel system that allows customers and their suppliers to securely access the omnichannel system without knowing the user's specific identity. Summary of the Invention

[0008] This invention is defined by the independent claims, which are now to be referenced. Advantageous features are set forth in the dependent claims.

[0009] According to a first aspect of the invention, a method is provided for secure communication between a device and a computer program running on a server. The method includes the steps of: sending general user identification information based on a current user account logged in on the device from the device to the server; having the server identify the general user identification information as corresponding to an authorized entity pre-registered with the server; sending an identification token associated with the authorized entity from the server to a remote management module, the remote management module storing a registry of registered devices; having the remote management module perform a remote action on the device using a registry entry stored for the device, wherein the remote action transmits the identification token to the device; sending the identification token from the device to the server; and allowing the device to access the computer program based at least in part on a match between the identification token sent by the server and the identification token received by the server from the device.

[0010] Optionally, the method further includes the following steps: generating a one-time authentication token by the server; sending the one-time authentication token and the identification token from the server to the remote management module; transmitting the one-time authentication token and the identification token to the device; sending the one-time authentication token and the identification token from the device to the server; and allowing the device to access the computer program based at least in part on a match between the one-time authentication token generated by the server and the one-time authentication token received by the server from the device.

[0011] Optionally, the one-time authentication token is a randomly generated code.

[0012] Optionally, the general user identification information includes one or both of the following: the organization name associated with the current user account logged in on the device, and / or the location associated with the device.

[0013] Optionally, the general user identifier does not include the identity of the specific person using the device.

[0014] Optionally, identifying the general user identification information as corresponding to an authorized entity includes: confirming that the organization name and / or the location appears in a list of authorized organizations and / or locations pre-registered with the server and having permission to access the computer program.

[0015] Optionally, the general user identification information includes both the organization name associated with the current user account logged in on the device and the location associated with the device; and identifying the general user identification information as corresponding to an authorized entity includes: confirming that the organization name and location pair appears in a list of authorized organization and location pairs pre-registered to the server and having permission to access the computer program.

[0016] Optionally, identifying the general user identification information as corresponding to an authorized entity is independent of the identity of the specific person using the device.

[0017] Optionally, the method further includes the step of: preventing the device from accessing, via the computer program, the organization name and / or data and / or functions for which the location lacks authorization in the general user identification information.

[0018] Optionally, data for multiple organizations is stored in a data storage unit, wherein data for each organization is stored in a different domain; and the method further includes the step of preventing the device from accessing any storage domain other than the storage domain containing data of the organization associated with the currently logged-in user account on the device via the computer program.

[0019] Optionally, the server includes an identification token stored on the server for each permitted entity pre-registered to the server.

[0020] Optionally, each allowed entity is an allowed organization name and / or location, preferably an allowed organization name and location pair.

[0021] Optionally, the identifier token is a digest code generated by performing a hash function on the allowed organization name and / or location.

[0022] The method as described in any of the preceding claims, wherein the device is installed in one of the following locations: an airport, a train station, a port, or a transportation hub.

[0023] Optionally, the general user identification information includes one or both of the following: the name of the airline or ground service provider associated with the user account logged in on the device, and / or the airport where the device is installed.

[0024] Optionally, the device is any of the following: a tablet computer; a smartphone; a mobile device; a CUTE (Common Terminal Equipment) device; a multi-tenant device; a connectivity device; an airport workstation; an information kiosk; a self-service baggage storage unit; or a biosafety device.

[0025] Optionally, the method further includes the following steps: sending at least one of the following, along with the general user identification information, from the workstation to the server: the hostname of the device; the device identifier for the device included in the registry of the registered device; and information indicating the node of the remote management module associated with the device.

[0026] Optionally, the method further includes the steps of sending at least one of the following, along with the identification token, from the server to the remote management module: the device identification code for the device included in the registry of the registered device; and information indicating the node of the remote management module associated with the device.

[0027] Optionally, the method further includes the step of: performing a check to see if the identity token passed from the remote management module to the device matches the current user account logged in on the device.

[0028] Optionally, the computer program is a virtual agent function.

[0029] Optionally, the method further includes the following steps: a user of the device inputs an input query to the virtual agent function; a Natural Language Understanding (NLU) module processes the input query to determine the intent of the input query; and the virtual agent function performs an automated action based on the determined intent.

[0030] Optionally, the virtual agent function is an automated chatbot, and the input query is a text command entered via the device.

[0031] Optionally, the virtual agent function is an automated voice robot; the input query is a voice command input via the device; and the method further includes converting the voice command into a text command via a speech-to-text module before processing by the NLU module.

[0032] Optionally, the method further includes the step of translating the input query from a first language into a second language before it is processed by the NLU module.

[0033] Optionally, the NLU module is trained using a dataset that includes air transport industry-specific terminology.

[0034] Optionally, the method further includes the following steps: selecting a first prompt from a plurality of prompts presented on the device by the virtual agent function through user input of the device; and performing an automated action by the virtual agent function based on the selected prompt.

[0035] Optionally, the automated action is at least one of the following: instructing the remote management module to perform a remote action on the device; instructing the remote management module to reboot the device or a peripheral device connected to the device; instructing the remote management module to restart a service running on the device; instructing the remote management module to perform a repair action on the device or a peripheral device connected to the device; instructing the remote management module to perform a health check on the device, and optionally displaying a report of the health check on the device; or recording the record in a central database.

[0036] Optionally, the device is a first device, and the automated action includes recording the failure of the second device in a central database.

[0037] Optionally, the automated action includes retrieving data from the data storage unit and outputting the data to the user of the device.

[0038] Optionally, the conditions for obtaining and / or outputting the data are the organization name associated with the current user account logged in on the device and / or the location associated with the device.

[0039] Optionally, the automated action includes initiating a communication channel with the real-time agent.

[0040] Optionally, the method further includes the following steps: receiving input in a first language from the user of the device; and having the input translated in real time into a second language set by the real-time agent by a dynamic translation module.

[0041] According to a second aspect of the present invention, a secure communication system is provided. The system includes: a device; a server on which a computer program runs; and a remote management module storing a registry of registered devices; wherein: the device is configured to send general user identification information based on a currently logged-in user account on the device to the server; the server is configured to identify the general user identification information as corresponding to an authorized entity, and subsequently send an identification token associated with the authorized entity to the remote management module; the remote management module is configured to perform a remote action on the device using registry entries stored for the device, wherein the remote action is configured to pass the identification token to the device; the device is configured to send the identification token to the server; and the server is configured to allow the device to access the computer program based at least in part on a match between the identification token sent by the server and the identification token received from the device.

[0042] The secure communication method and system according to the present invention offer several advantages. First, the authentication process provides secure, controlled access to customer data and services in the backend system, where access to data and functionality is limited to portions owned by or associated with a specific customer. Secure access can be enabled without the omnichannel operator needing to know the specific end-user (i.e., employee) of each customer operating the device. Conversely, access to computer programs on a server can be securely enabled solely based on generic user identification information (i.e., customer level (e.g., company and location / airline and airport)) rather than on individual users employed by the customer.

[0043] Furthermore, the secure communication method enables secure access without requiring each end-user (i.e., customer employee) to enter a personal username and password each time they access the omnichannel system. This is because the method allows authentication by passing an identity token to the device via a remote management module without any intervention from the user and without requiring the omnichannel operator to manage the specific identities of each customer's employees. Attached Figure Description

[0044] The embodiments of the present invention will now be described with reference to the accompanying drawings, wherein:

[0045] Figure 1 A secure communication system according to an embodiment of the present invention is shown;

[0046] Figure 2 The logical architecture of the secure communication system in an embodiment of the present invention is shown;

[0047] Figure 3a shows a flowchart of a secure communication method according to an embodiment of the present invention;

[0048] Figure 3b illustrates a secure communication method according to an embodiment of the present invention;

[0049] Figure 4a illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0050] Figure 4b illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0051] Figure 4c illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0052] Figure 5a illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0053] Figure 5b illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0054] Figure 6 The present invention illustrates an NLU processing method and a self-service interaction with a virtual agent function in an embodiment of the invention;

[0055] Figure 7a illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0056] Figure 7b illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0057] Figure 7c illustrates the self-service interaction with the virtual agent function in an embodiment of the present invention;

[0058] Figure 8a illustrates a proxy console with dynamic translation in an embodiment of the present invention;

[0059] Figure 8b illustrates a proxy console with dynamic translation in an embodiment of the present invention. Detailed Implementation

[0060] Omnichannel system

[0061] Figure 1 A secure communication system 1000 according to an embodiment of the present invention is illustrated. The secure communication system 1000 may be an omnichannel system that enables a user 100 to securely access customer support or technical assistance, or in some cases, to securely communicate with a real-time agent 200 of the omnichannel system's operator. Therefore, the secure communication system 1000 will also be referred to herein as an omnichannel system.

[0062] The secure communication system 1000 includes device 300 and server 400. Device 300 can be any suitable device through which user 100 can access the omnichannel system, such as a computer, smartphone, tablet, mobile device, etc. In some implementations, device 300 can be a Common Terminal Equipment (CUTE) device or a multi-tenant device shared among multiple customers. For example, in an ATI environment, these customers may include different airlines or ground service companies. Device 300 can also be any other connected device through which user 100 can access the omnichannel system, such as an airport workstation, kiosks (such as automated check-in kiosks), self-service baggage storage units, or airport biosecurity equipment.

[0063] exist Figure 1 In the illustrated embodiment, device 300 is an airport workstation. Therefore, device 300 will also be referred to herein as workstation 300, but is not limited thereto. Furthermore, although its use in an airport environment is described below, the security communication system 1000 can also be used for a variety of other applications. The security communication system 1000 can be specifically used in other passenger-related processing areas, such as at train stations, ports, transportation hubs, or hotels.

[0064] Device 300 can communicate with server 400, for example, via HTTPS. Server 400 acts as a service management system, thereby providing user 100 with access to data and functions via workstation 300. For example, computer programs that workstation 300 can access run on server 400. In this embodiment, the computer program is a virtual agent program 402, such as a chatbot or voice bot running on the server; however, other computer programs may also be used.

[0065] As part of the omnichannel system, user 100 may wish to access virtual agent program 402 to access data, ask questions and make technical inquiries, report problems or incidents or malfunctions, etc. For example, particularly in ATI, ground staff typically use CUTE workstations provided and managed by the omnichannel system operator for passenger and baggage check-in processes. These workstations 300 may also be equipped with peripheral devices such as printers and scanners. If any of these devices malfunctions, airline agents or baggage handlers may wish to seek support through the omnichannel system 1000 to resolve the issue.

[0066] Specifically, user 100 can log in to user profile 302 on workstation 300 and access virtual agent 402 via web client 304 on workstation 300. For example, the desktop of workstation 300 may include shortcut links to allow ground staff to connect to service support. The shortcut runs an app, which launches web client 304 to connect to virtual agent 402 running on the server.

[0067] In the case where the computer program is a virtual agent chatbot, user 100 can converse with virtual agent 402, for example, by typing on the keyboard of workstation 300. Virtual agent 402 can communicate with natural language understanding (NLU) module 404, which is capable of determining the user's intent from the user's input. Virtual agent 402 can then proceed with appropriate automated actions based on the determined intent. In this way, virtual agent 402 can assist user 100 of workstation 300 in answering any questions the user may have.

[0068] exist Figure 1 In some implementations, the NLU module 404 is shown separately from the server 400. For example, the NLU module 404 may be hosted in the cloud. However, in some implementations, the NLU module 404 may also be included in the server 400, or in some implementations, it may form part of the virtual agent computer program 402 itself.

[0069] In some cases, user 100 may wish to communicate with real-time agent 200. Therefore, in some implementations, a function of the computer program includes facilitating communication between user 100 and real-time agent 200. Figure 1 In a specific implementation, this could involve user 100 accessing virtual agent 402 via workstation 300, and virtual agent 402 passing the communication channel to an agent, i.e., server 400 can transfer the chat to real-time service desk agent 200. This transfer to real-time agent 300 could be an automated action performed by virtual agent 402 in response to NLU module 404 determining that user 100 wishes to speak with the real-time agent.

[0070] like Figure 1 As shown, agent 200 can communicate with the user via agent console 406. The agent console can be a computer program running on server 400, or alternatively, it can run on a separate device (such as an agent device / workstation located remotely from the user's workstation 300). After a connection is established between the user and the agent, both parties can type messages in their respective workstations to conduct a dialogue.

[0071] Alternatively, communication between user 100 and agent 200 can be facilitated via voice. For example, user 100 can input speech at workstation 300, for instance, via a head-mounted device. Alternatively, device 300 can be a mobile phone or smartphone, through which user 100 can input voice commands. A voice call module 408 may optionally be provided to facilitate voice calls from user 100. Similarly, voice call module 408 in... Figure 1 The voice call module 408 is shown separately from the server 400 and in some examples may be hosted in the cloud. However, in some implementations, the voice call module 408 may also be included in the server 400.

[0072] The voice call module 408 can transmit the voice input of user 100 to the speech-to-text module 410, which converts the voice input into text data. Similarly, the speech-to-text module 410 can be separate from the server (e.g., in the cloud) or included within the server. The text data from the speech-to-text module 410 can be passed to the NLU module 404 to determine the user's intent. The virtual agent 402 can then converse with the user, where, if the user initiates contact via voice call, the virtual agent is typically a voice robot that communicates via voice, for example, by responding to user 100 using speech synthesis software or pre-recorded audio clips. The virtual agent voice robot can then perform automated actions again based on the intent determined from the speech input.

[0073] In the event that a user requests to speak with the real-time agent 200, the virtual agent 402 can connect the user 100 to the agent 200 via the voice call module 408, and then the agent 200 can speak with the user 100, for example, via a head-mounted device at the agent device or via the agent 200's mobile phone.

[0074] In this way, user 100 can input chat or voice commands to server 400 via device 300, and virtual agent 402 running on server 400 can perform automated actions in response to the input, which may include enabling user 100 to chat or voice communicate with real-time agent 200.

[0075] The secure communication system 1000 also includes a remote management module 500 communicatively coupled to the server 400. The remote management module 500 includes a stored registry of all devices managed by the omnichannel system operator. In other words, all devices within the system operator's network that can be used to access the omnichannel system are registered in the remote management module 500. The remote management module 500 is used for user authentication, as will be described in more detail below with reference to Figures 3a and 3b.

[0076] The aforementioned secure communication system 1000 and omnichannel solution are technology-agnostic, and therefore can be implemented using a variety of different products and software. For example, server 400 may include products such as ServiceNow or Amazon Lex, voice call module 408 may include products such as Genesys Cloud or Amazon Connect, web client 304 may include products such as .NET or Python, remote management module 500 may include products such as Nexthink or N-able, and NLU module 404 may include products such as Google DialogFlow.

[0077] Figure 2 The logical architecture 2000 of a secure communication system (in this case, an omnichannel virtual proxy system) according to an exemplary embodiment of the present invention is shown. (As in...) Figure 2 As can be seen, the omnichannel solution supports a wide range of end-users (602), including staff working directly for the omnichannel operator's customers (e.g., airlines and airports), as well as contractors and subcontractors working on behalf of these customers (e.g., baggage handlers). The solution also supports the omnichannel operator's own suppliers, enterprise users, and field agents. These users (602) are equivalent to... Figure 1 100 users.

[0078] Box 604 illustrates the various interaction channels supported by an omnichannel system. As seen in box 604, end user 602 can interact via various communication channels, including voice, email, portals, chat, and mobile devices. Each of these channels can be accessed via several devices and client applications (such as...). Figure 1The system allows access via device 300. It also enables centralized management of all interactions, regardless of the channels through which they occur. This facilitates better reporting and analysis of how users contact omnichannel operators for support. Finally, identifying and authenticating users interacting with the system allows for the application of appropriate security and access controls when any services and data are exposed to users. Specifically, end users 602 accessing the omnichannel system typically request operational access permissions. Therefore, secure access is required to protect operational data in the end-user company's backend systems and to ensure privileged access to control device elements such as restarting services or rebooting devices. The authentication process will be described in more detail below with reference to Figures 3a and 3b.

[0079] The interactive session is converted into a dialogue and communicated by the natural language chatbot shown in box 606 (equivalent to...). Figure 1 The NLU module 404) processes the data. In some implementations, a cloud-based chatbot service can be used for box 606. Any voice interaction can be transcribed into text (e.g., via...). Figure 1 The system uses a voice call module 408 and a speech-to-text module 410, which are then processed by the chatbot, and the response is converted back into speech to be transmitted back to the user. Natural language understanding capabilities can be driven by machine learning models, which may include an enhanced vocabulary and ATI-specific trained models. The chatbot can also be capable of translating between various languages. These features will be discussed below. Figure 6 See Figure 8b for a more detailed discussion. Translation can be performed using cloud-based translation services such as Google Translate or Azure Cognitive Services Translator.

[0080] Box 608 illustrates the virtual agent function (equivalent to...) Figure 1 The virtual agent 402 includes an intelligent, automated dialogue process to fulfill customer requests for self-service based on intents identified by a natural language chatbot (i.e., NLU modules 404, 606). Common service requests and issues are resolved by the virtual agent without any human intervention. This may include contextual searches through service catalogs or knowledge bases. The automated process may also invoke other logging systems to obtain the data needed to fulfill the request. The virtual agent can also transfer the user to a real-time human agent 200 when the user makes a request or when the virtual agent cannot provide assistance.

[0081] Box 610 illustrates the fulfillment backend of the omnichannel system. Within Box 610, further workflows and integration with the backend system 612 are present to fulfill requests and provide responses to users.

[0082] When resolving customer issues, controlled access to a range of backend systems 612 is required. This may include a ticketing system for tracking events and requests, a customer relationship management (CRM) system containing information related to customers and their interests, and automated and remote management systems that manage workstations and other devices used by end users 602. Specifically, backend systems may include:

[0083] • A customer relationship management (CRM) system used to provide responses to customer account inquiries;

[0084] • A customer service management (CSM) system used to provide responses to customer care inquiries;

[0085] • An IT service management (ITSM) system used to provide responses to IT issues faced by customers;

[0086] • A remote management system used to remotely perform automated actions on devices to solve problems.

[0087] Finally, box 614 shows the agent auxiliary facility, which enables the omnichannel operator's service agent 618 (equivalent to Figure 1 The real-time agent 200 is capable of responding effectively when interactions are directed from virtual agents 402 and 608 to the service agent. The system ensures that the agent has access to the history of conversations between end users 100 and 602 and the virtual agent, as well as any classifications already performed. Various different agent consoles 616 (equivalent to...) can exist. Figure 1 The proxy console (406) is customized for different types of proxies, including help desk proxies, technical support proxies, CSM proxies, sales proxies, etc. Proxies can be organized into queues, where requests are automatically routed to available proxies based on their skills and availability.

[0088] In some implementations, each of blocks 606, 608, 610, and 614 may be included in Figure 1 The remote management backend system 612 can be included in server 400. Figure 1 The remote management module 500.

[0089] User authentication and access control

[0090] As mentioned above, omnichannel operators can store operational and service management data related to each of their customers and need to maintain the security and isolation of customer data for each customer. Therefore, when an employee of a specific customer (i.e., user 100) interacts with the omnichannel system (i.e., secure communication system 1000), the system must ensure that the user only has access to the data and services belonging to that customer.

[0091] To address this issue, the system maintains data isolation by storing customer data in a separate domain. Access to the data is controlled by the company (organization) to which end user 100 belongs. However, the omnichannel operator does not manage the identity of end user 100 because the end user is an employee of the customer organization. Authenticating each customer's end user against a registry stored by the omnichannel operator is impractical because each customer's end user (i.e., employee) is managed by the customer organization, not the omnichannel operator. Therefore, the omnichannel system cannot identify and authenticate users based on their personal identities. Instead, the secure communication method 3000 shown in Figure 3a is used.

[0092] Figure 3a shows a flowchart of a secure communication method 3000 according to an embodiment of the present invention. The secure communication method 3000 can... Figure 1 The process is executed between device 300 and server 400.

[0093] In step 702, generic user identification information based on the current user account 302 logged in on device 300 is sent from device 300 to server 400. The generic user identification information is information sufficient to identify a specific organization of a customer of an omnichannel operator, but does not depend on the identity of the specific end user (i.e., employee) currently using device 300.

[0094] In some implementations, the generic user identification information may include the organization name associated with the current end-user account 302 logged in on the device. Additionally or alternatively, the generic user identification information may include the location associated with the device 300. For example, in an implementation where the secure communication method 3000 is applied to an ATI scenario, the generic user identification information may include an airline name or ground service organization name as the organization name. Further, in some implementations, the generic user identification information may also include the specific airport where the device 300 is installed as the location.

[0095] In step 704, server 400 identifies whether the general user identification information corresponds to an authorized entity pre-registered with the server. An authorized entity is an entity pre-registered with the server that has permission to access computer program 402. Server 400 can check the general user identification information against a list of authorized entities to perform the identification. Server 400's identification of the general user identification information against authorized entities is independent of the identity of the specific end user 100 using device 300.

[0096] Specifically, the permitted entities pre-registered in server 400 can be any of the following: the name of an organization with access to computer program 402, the location of device 300 with access to computer program 402, or both the specific organization name and device location with access to computer program 402. For example, in an implementation of the secure communication method 3000 applied to an ATI scenario, in addition to the specific airport where the device is installed, the general user identification information may also include either the airline name or the ground service provider name. The server can then check the airline / ground service provider name and airport location pairs against a list of permitted airline / ground service provider name and airport location pairs.

[0097] If the generic user identification information is identified as corresponding to an authorized entity, method 3000 proceeds to step 706. In step 706, server 400 sends an identification token associated with the identified authorized entity to remote management module 500. The identification token is a unique token for that authorized entity user that is not stored on device 300, and is accessible to device 300 only by server 400 (via remote management module 500).

[0098] In some implementations, the identification token is a digest generated by performing a hash function on the organization name, device location, or organization name and location of the allowed entity. In some implementations, the hash function may use SHA256 encoding. Using the digest as the identification token allows for obfuscation of the user's identity when transmitting the identification token in the following steps.

[0099] In some implementations, server 400 may include a stored list of identity tokens pre-registered with each permitted entity. These identity tokens may be generated for each permitted entity during pre-registration with server 400. Server 400 may select from this list the identity token of the permitted entity for which general user identification information is identified, and send the identity token to remote management module 500. Alternatively, server 400 may generate the identity token on the fly in response to the identification of general user identification information corresponding to a permitted entity.

[0100] In step 708, upon receiving the identification token, the remote management module 500 executes the remote action performed in step 702 on device 300, which sent the general user identification information to server 400. The remote management module 500 stores a registry of all devices registered with the omnichannel operator and uses the registry entries stored for device 300 to execute the remote action on device 300.

[0101] A remote action performed by the remote management module 500 transmits the identification token to the device 300. In this way, if the device 300, which initially sent the generic user identification information to the server 400 in step 702, is registered with the remote management module 500 (i.e., registered with the omnichannel system operator), the identification token is only transmitted to that device. This prevents unauthorized devices (i.e., any devices not pre-registered with the omnichannel system operator) from receiving identification tokens from the server 400.

[0102] In step 710, after receiving the identification token from the remote management module 500, the device 300 sends the identification token back to the server 400.

[0103] In step 712, server 400 compares the identification token received from device 300 in step 710 with the identification token sent by server to remote management module 500 in step 706. If server finds that the identification token sent in step 706 matches the identification token received in step 710, server 400 allows device 300 to access computer program 402. If the identification token sent in step 706 does not match the identification token received in step 710, server will not allow device 300 to access computer program 402.

[0104] Therefore, the secure communication method 300 allows the server 400 to control access to the computer program 402 (such as the virtual agent function discussed above). This authentication is performed without knowing the identity of the specific end-user (i.e., person) operating the device 300, nor the specific password of the current user account 302 logged in on the device, but only using generic user identification information based on the current user account 302 logged in on the device 300. The current user account 302 can be a specific user account unique to the end-user operating the device 300, or it can be a shared account that allows access to various end-users within an entity's organization. In either case, only the abstract generic user identification information affects whether the device 300 is allowed access to the computer program 402.

[0105] Furthermore, using generic user identification information and identity tokens to authenticate access to computer programs advantageously avoids the need for interactive authentication. For example, if authentication were to be performed at the specific end-user level of the operating device, the end-user would be prompted to enter a username and password each time they wanted to access the computer program. In contrast, authentication via generic user identification information and identity tokens can be performed without any specific end-user input.

[0106] In the above method, server 400 can check whether the general user identification information corresponds to the organization authorized to access computer program 402 or whether it corresponds to the device location authorized to access computer program 402, and only allow access to computer program 402 when a match is detected. Furthermore, if the pre-registered allowed entities include both organization name and device location pairs, server 400 can only allow access if the general user identification information corresponds to both the organization name and location pair. This can be particularly advantageous in ATI scenarios, where access to a specific organization at one airport can be allowed while access to the same organization at another airport is blocked because the relevant organization-airport pair does not appear in the list of allowed entities.

[0107] Furthermore, when device 300 requests access to computer program 402, authentication is performed based on the identity token sent in step 710, rather than on the generic user identification information initially sent by device 300. The identity token is not stored locally on device 300 but is obtained from server 400 via remote management module 500. Only devices registered with remote management module 500 can receive the identity token from server 400, thus enhancing security because the identity token is sent via remote management module 500 using the device registry. Specifically, if a malicious third party attempts to access computer program 402 with an unregistered device (i.e., the omnichannel system), authentication will inevitably fail because the unregistered device will be unable to obtain the correct identity token from server 400 via remote management module 500.

[0108] While allowing device 300 to access computer program 402, the server can still prevent device 300 from accessing other functions or data for which the allowed entity lacks permissions, based on a successful match between the sent and received identification tokens. For example, computer program 402 may include multiple functions, for which the allowed entity has different levels of access. The specific affiliation (i.e., organization name and / or location) of the user of device 300 is known via the authentication method 3000 of Figure 3a, and therefore the server can only allow that allowed entity to access the functions it is authorized to use. Similarly, the server can only allow access to data for which the identified allowed entity has permissions. Thus, server 400 allows authenticated users to access certain applications and data using role-based authorization.

[0109] Specifically, in one implementation, data for multiple organizations can be stored in a data storage unit, with each organization's data stored in a different domain. Server 400 can store a list of all identification tokens and the corresponding storage domains that each identification token is authorized to access. Therefore, server 400 can prevent device 300 from accessing any storage domain other than the domain containing the data of the authorized entity corresponding to the identification token. Thus, only the data of the organization associated with the currently logged-in user account on the device can be accessed. In this way, the security of each organization's (i.e., the customer's) data can be ensured.

[0110] Figure 3b shows a flowchart of a secure communication method 4000 according to an embodiment of the present invention. Except for including several further optional steps, the method 4000 of Figure 3b is the same as the method 3000 of Figure 3a. In Figure 3b, method 4000 is applied to a scenario where general user identification information includes airline names and airport pairs.

[0111] The method begins at step 802, where end user 100 using device 300 (in this case, a workstation) clicks a shortcut to initiate a connection with computer program 402. In this implementation, computer program 402 is a virtual agent chatbot; however, other computer programs may also be used. The user clicking the shortcut on workstation 300 triggers a script to initiate a REST call to server 400.

[0112] In step 804, a REST call is initiated to the user-authentication scripted API endpoint of server 400. An example of the details of the REST call is shown below:

[0113]

[0114] The REST call sends generic user identification information to server 400 based on the current user account logged in on workstation 300. In this case, the generic user identification information includes the airline name and the airport location of the workstation, such as AA:LHR. Therefore, in this implementation, authentication for accessing the virtual agent function is performed based on a combination of the airline code and airport code associated with the current user account logged in on workstation 300.

[0115] Furthermore, a REST call may optionally include one or more of the following query parameters:

[0116] • hostname: The computer name of the workstation, such as MIAGCKB090;

[0117] • device_id: A unique ID for the workstation when registered in the remote management module, such as 1ab7cf04a94ed7e6071aee0;

[0118] • remote_management_module_engine_name: The remote management module manager (engine) node for the management workstation.

[0119] These query parameters provide server 400 with details about how to reach the workstation via remote management module 500 (as done in steps 814 and 816 below).

[0120] OAuth can be used to authenticate inbound REST API requests in step 804. This improves security by passing a token instead of credentials in each request.

[0121] Then, workstation 300 waits for a response from server 400 on named pipe 806, and the method proceeds to step 808, where the scripted API service obtains an identifier token (in this case, a SHA256 digest) associated with the permitted entity corresponding to the generic user identification information. Again, here, the permitted entity is an airline name and airport location pair, such as AA:LHR, pre-registered with server 400 and authorized to access virtual proxy function 402.

[0122] The following JavaScript code snippet provides an example of how to generate a digest token using the SHA256 security algorithm. The digest can be generated on-the-fly. Alternatively, the digest can be generated during the pre-registration of allowed entities to the server and retrieved in step 808 from a lookup table of all allowed entities and their corresponding digest tokens.

[0123]

[0124] Using a hash function to generate the identification token means passing the hashed identification token in the following HTTP call, instead of passing the generic user identification information (e.g., AA:LHR) in plaintext. In other words, applying a hash function to the airline and airport code pairs (i.e., the authorized entities corresponding to the generic user identification information) to generate a digest code before sending it over the network improves security.

[0125] If the generic user identification information does not correspond to any authorized entity, a digest code will not be obtained, the initial REST call will time out, and no access to the virtual proxy functionality will be granted by the server with a 400 Allowed response.

[0126] Next, at step 810, if the digest code is successfully obtained, the server 400 generates a one-time authentication token. This one-time authentication token is an optional additional security layer for each session, which can be used in conjunction with an identity token, and will be discussed in more detail below. The one-time authentication token can be stored in memory 812 for a predetermined period of time, for example, 24 hours. In some implementations, the one-time authentication token can be, for example, a random six-digit authentication code created using the following Javascript code:

[0127]

[0128] At step 814, both the identity token (i.e., the digest code) and the one-time authentication token are passed to remote action 816 running on the remote management module 500 via an outbound REST API call. An example of the details of the REST call is shown below:

[0129]

[0130] As shown above, a REST call may optionally include one or more of the following query parameters:

[0131] raUID: Remote Action ID

[0132] • deviceUid: Workstation device ID, i.e., device_id in step 804

[0133] • Portal: The address of the remote management module

[0134] • engineUID: The remote management module engine (node) ID of the management workstation, i.e., remote_management_module_engine_name in step 804.

[0135] • Script: The name of the remote action script

[0136] Remote action 816 on remote management module 500 is directed to the desired workstation 300 and runs a local script on workstation 300, passing an identification token and a one-time authentication token to workstation 300 in step 818. Here, the desired workstation 300 is the specific workstation for which the general user identification information was initially sent to server 400 in step 804. To target the desired workstation, remote management module 500 uses a registry stored on remote management module 500 that is registered to all devices in the omnichannel operator. Further, remote management module 500 can identify the desired workstation based on one or more of the query parameters sent to the server via a REST call in step 804 (the query parameters are passed to remote management module 500 via the query parameters listed in the REST call above in step 814).

[0137] Once the identity token and one-time authentication token have been passed to the workstation, the local script writes to the waiting named pipe 806. Then, workstation 300 can proceed, that is, at step 820, start the web client chatbot 304 on the workstation and pass the identity token and one-time authentication token to the virtual agent 402 running on server 400.

[0138] Next, in steps 822 and 824, the virtual agent 402 on server 400 executes a script action to match the received identification token with the identification code obtained in step 808 and sent by the server in step 814. Further, the script action matches the received one-time authentication token with the one-time authentication token generated in step 810 (stored in code log 812) and sent by the server in step 814.

[0139] If both the identity token and the one-time authentication token are found to match correctly, a virtual agent chatbot session is established in step 826. User 100 is granted access via workstation 300, and the chatbot begins a conversation and proceeds to topic discovery. If either the identity token or the one-time authentication token does not match correctly with the token previously sent in step 814, the request to access the chatbot is denied in step 828, meaning user 100 is denied access and exits the conversation.

[0140] Method 4000 in Figure 3b again allows authentication using only general user identification information without knowing the identity of the specific end user (i.e., personnel) operating the device 300.

[0141] Furthermore, an identification token (digest code) is sent to workstation 300, enabling client applications on the workstation to use the identification token to log in to the server and access the virtual proxy functionality. Server 400 identifies users solely by their digest codes; however, workstation 300 does not store digest codes and must obtain them from the server first. Sending tokens (both the identification token and the one-time authentication token) from server 400 to workstation 300 via remote management module 500 allows server 400 to confirm that it is communicating with the specific workstation 300 requested in the REST call of step 804.

[0142] In other words, in method 4000, steps 814, 816, and 818 provide functionality to send the token (required to log in to server 400) to the user via an alternative channel. This alternative channel is via remote management module 500. Therefore, this method prevents malicious parties from spoofing workstation device IDs using devices not registered with remote management module 500, because remote management module 500 will only send the token required to log in to the server to the actual workstation that initiated the initial REST call.

[0143] Additionally, step 820 performs the function of sending a token back to server 400 to verify the user and allow the transaction / authentication to complete (i.e., log in to the server). This method replaces the need for the user to enter a password every time they wish to access the virtual proxy functionality, thus enabling authentication to be performed without the user's active involvement.

[0144] In addition to providing the same advantages as method 3000 of Figure 3a, method 4000 of Figure 3b offers several further advantages. Specifically, in method 4000 of Figure 3b, both the identification token and the one-time authentication token must match to allow access to computer program 402 (virtual agent function). This introduces another round of verification, where workstation 300 then needs to send both tokens to server 400 to initiate the virtual agent. Server 400 will only allow the request to access the virtual agent function if, in addition to receiving the correct identification token, the incoming one-time authentication token matches a one-time authentication token previously generated by server 400 and awaiting a connection.

[0145] A one-time authentication token is generated each time user 100 accesses the system, thus enabling additional session-based security. Workstation 300 can only access the virtual proxy and establish a session if it possesses a specific one-time authentication token for the session. In other words, after a predetermined period of time following its generation, the one-time authentication token expires, and the server will not allow access to the virtual proxy functionality using that token. After the one-time authentication token expires, the entire process 4000 must be repeated to re-authenticate the user. In this way, the session duration is prevented from exceeding the intended time, meaning that a malicious party knowing only the authentication token is insufficient to access the omnichannel system. In some implementations, the predetermined validity period of the one-time authentication token can be the same as the length of time the one-time authentication token is stored in memory 812.

[0146] Finally, even if a malicious third party somehow gains access to workstation 300 registered in the remote management module 500, this method still prevents the third party from accessing the virtual agent. The workstation generates generic user identification information from the current user account logged in on workstation 300. Access to the user account corresponding to the generic user identification information and the authorized entity is limited to employees within the authorized entity's organization. Therefore, a third party will not be able to access the virtual agent without obtaining a user account to generate a generic user identification.

[0147] Furthermore, in some implementations, the method can also prevent access to the virtual proxy functionality by spoofing generic user identification information. To prevent a malicious third party from sending spoofed generic user identification information from the registered workstation 300, a check can be performed in step 818 (or step 708 of method 3000 in Figure 3a) to match the identification token passed from the remote management module 500 to the workstation 300 with the currently logged-in user account. The request will only proceed if the generic user identification information in the initial request (used by the server 400 to obtain the identification token) corresponds to the generic user identification information the user is already logged in with. Therefore, a malicious third party will need to obtain the user account corresponding to the authorized entity and the workstation 300 registered to the remote management module 500 to access the virtual proxy functionality.

[0148] Virtual proxy function

[0149] Previously, when ground service staff at ATI encountered equipment problems, they had to request assistance by submitting a work order to the service desk or calling a field engineer. These options could result in slow response times and be time-consuming, increasing the workload for those needing help. Failure to resolve issues promptly could lead to delays in passenger and baggage handling. Therefore, self-service via virtual agent functionality is desirable for all parties involved.

[0150] Now regarding Figures 4A to 8B Various features that can be used as the virtual agent functionality of computer program 402 in the above embodiments are described. Similarly, the following description is based on the ATI scenario; however, it should be understood that the following embodiments are not limited thereto.

[0151] Return to Figure 1 When computer program 402 is a virtual agent function, user 100 of device 300 can input queries into virtual agent function 402. For example, if the virtual agent function is an automated chatbot, the input query is a text command entered via device 300 (e.g., via keyboard). If the virtual agent function is an automated voice robot, the input query is a voice command entered via device 300 (e.g., via head-mounted device).

[0152] In either case, the NLU module 404 processes the input query to determine its intent. If the virtual agent function is a voice robot, the input voice command is converted into a text command via the speech-to-text module 410 before being processed by the NLU module 404. The virtual agent function 402 then performs an automated action based on the determined intent.

[0153] In some implementations, in addition to user input of a query and the virtual agent using NLU module 404 to determine the intent of the query, or as an alternative, the virtual agent function can present multiple prompts to user 100 on device 300. For example, if the virtual agent is a chatbot, it can display multiple clickable options on the device. If the virtual agent is a voice robot, it can read multiple prompts aloud to user 100 via device 300, for example, using an interactive voice response (IVR) method. In either case, user 100 can input a selection of one of the prompts, and the virtual agent function 402 can perform a predetermined automated action based on the selected prompt.

[0154] Self-service automation using virtual agents

[0155] Figures 4a and 4c illustrate example self-service interactions with the virtual agent function 402 in embodiments of the present invention. In the embodiments of Figures 4a and 4c, the virtual agent is a chatbot, wherein user input is obtained via clickable prompts. Figures 4a and 4c show screenshots of chatbot conversations visible to user 100 on workstation 300.

[0156] In step 902 of Figure 4a, virtual agent 402 presents a list of prompts related to automated actions that the virtual agent can perform. User 100 selects "Check workstation health" as the automated action. The virtual agent then performs a health check on workstation 300 and proceeds to step 904 shown in Figure 4b, where a summary report card is displayed, containing the status of key performance indicators and critical services. Based on the results of the health check, the virtual agent recommends further automated repair actions, such as rebooting workstation 300, and user 100 can select a response to the automated repair action via a yes or no prompt.

[0157] As shown in step 906 of Figure 4c, the user can select "Yes" to allow the virtual agent to resolve problems with peripheral devices (such as a scanner connected to workstation 300). This automated repair action is performed on workstation 300 via the remote management module 500. If the automated repair action is unsuccessful, the virtual agent can prompt the user whether they wish to log the event or communicate with the real-time agent 200.

[0158] Figures 5a and 5b illustrate another example of self-service interaction with the virtual agent function 402 in an embodiment of the present invention. In the embodiment of Figures 5a and 5b, the virtual agent is a chatbot whose user input is obtained through both text input processed by the NLU module 404 and clickable prompts. Figures 5a and 5b show screenshots of the chatbot conversation visible to user 100 on workstation 300.

[0159] In step 912 of Figure 5a, user 100 selects "ask a question" as the automated action. In step 914 of Figure 5b, the virtual agent then automatically logs the event to the central database, collects various information from the user, and processes the user's response using NLU module 404.

[0160] Typically, various other automated actions can be performed by the virtual agent function 402. These automated actions include, but are not limited to:

[0161] • Instruct the remote management module 500 to perform remote actions on the device 300;

[0162] • Instruct the remote management module 500 to reboot the device or a peripheral device connected to the device 300;

[0163] • Instruct the remote management module 500 to restart the service running on device 300;

[0164] • Instruct the remote management module 500 to perform repair actions on the device or peripheral devices connected to the device 300;

[0165] • Instruct the remote management module 500 to perform a health check on the device, and optionally display a health check report on the device 300;

[0166] • Records will be entered into a central database;

[0167] • Create incident reports through a central database;

[0168] • View the status of existing event reports or logs.

[0169] In some implementations, these automated remote actions can be triggered by a virtual agent when a user is conversing with a chatbot / voice bot.

[0170] Virtual agent 402 can work with various backend systems (such as...) Figure 2 Integration with the backend system shown in box 612. In some implementations, the virtual agent 402 can fulfill requests and update the integration service management system via REST API calls.

[0171] In some implementations, automated actions may include retrieving data from a data storage unit (such as a central database) and outputting the data to user 100 on device 300. User 100 may query data related to a specific authorized entity. Such data may be private data of the authorized entity, such as account data or billing data. Therefore, the virtual agent is only allowed to retrieve data for that authorized entity if the authentication method of Figure 3a or Figure 3b has been successfully executed and it has been confirmed that the current user account 302 logged in on device 300 corresponds to that authorized entity. In this way, the conditions for the virtual agent to retrieve data are the organization name associated with the current user account 302 logged in on device 300 and / or the location associated with device 300.

[0172] In some implementations, automated actions may include initiating communication channels with real-time agent 200, as described above regarding... Figure 1 As described.

[0173] In some implementations, automation may include a virtual agent 402 accessed on the first device 300 logging faults occurring on the second device to a central database. For example, if a second user's device (the second device) malfunctions, they can notify user 100 of the first device 300, who can then log the fault on behalf of the second user. This can be particularly useful when the second user encounters a problem, meaning they are unable to log in to their workstation (the second device) or they are unable to launch the virtual agent web client on their workstation. In this case, they can request a colleague on another workstation (the first device) to log the event on their behalf or contact the real-time agent 200.

[0174] Using an omnichannel system with 402 access via a virtual agent allows end-users such as airline agents or ground staff to quickly resolve common issues themselves through automated actions. Automation and rapid problem-solving are crucial because airport ground staff often need to address issues promptly to avoid delays in passenger and baggage handling. Furthermore, such self-service reduces the workload of field engineers, enabling them to address more complex issues earlier.

[0175] Natural Language Understanding (NLU)

[0176] As described above, the virtual agent functionality of the omnichannel system uses NLU module 404 to determine the user's intent from the input. NLU module 404 can use a machine learning-based NLU service, which in some implementations may be a cloud-based service. The NLU-based virtual agent allows the user to interact with the virtual agent in a conversational mode, rather than navigating through clickable prompts or interactive voice response (IVR) options.

[0177] Figure 6 This illustrates another example of self-service interaction with the virtual agent function 402 in an embodiment of the present invention. Figure 6 In the implementation scheme, the virtual agent is a chatbot whose user input is obtained from text input processed by the NLU module 404. Figure 6 A screenshot 922 of a chatbot conversation visible to user 100 on workstation 300 is shown, along with a flowchart 924 of the processing performed by the NLU model of NLU module 404.

[0178] like Figure 6As shown, user 100 inputs a query into the virtual agent chatbot, in this example, asking "What is the current status of my request?" This input query is an example of natural language utterance; in other words, users can express their intent (i.e., make a question) in different ways. For example, a user might not ask "What is the current status of my request?" but rather "What is the current status of my ticket?" or "Has my problem been resolved?" In step 926, the NLU model identifies the utterance input by the user.

[0179] Next, at step 928, the NLU model identifies entities in the utterance. For example, an entity is the object or context of an action, such as a specific device, case number, or employee name. In the example above, the entities are "request," "work order," and "issue," respectively.

[0180] At step 930, the NLU model determines the user's intent based on the utterance and one or more entities. The user's intent is the action the user wishes to perform, such as submitting a service request or obtaining an order update. Figure 6 In the example, the intent is determined to be a user's request for the virtual agent to view the status of their IT ticket. In this way, the NLU model translates the user's natural language utterance into intent.

[0181] The virtual agent can then execute relevant automated actions in response to the intent. The virtual agent runs actions mapped to the determined intent and the recognized utterance. For example, in Figure 6 In the middle, the virtual agent chatbot displays the user's existing IT ticket RSTM0000001.

[0182] As mentioned above, the NLU model can be a machine learning-based model. Particularly in ATI, omnichannel operators and their customers frequently use a large number of ATI-specific terms not covered by traditional machine learning NLU datasets. Furthermore, users may input acronyms instead of full phrases. Therefore, in some embodiments of the invention, the NLU model can be extended to include a vocabulary containing ATI-specific terms and phrases. In other words, the NLU machine learning model of NLU module 404 can be trained using a vocabulary containing ATI-specific terms and phrases. Training based on this vocabulary helps the NLU model understand the words and phrases used by users it may encounter.

[0183] For example, sample discourse using ATI terminology could be:

[0184] WorldTracer baggage management did not receive the BSM message.

[0185] Therefore, the term "WorldTracer" and the acronym "BSM" were added to the vocabulary, and the NLU model was retrained. The NLU model was then able to make correct predictions about user intent based on utterances.

[0186] In some implementations, the training data can be expanded to include the following vocabulary types:

[0187] • Fixed: Uncommon words or phrases, such as ATI terminology

[0188] • Pattern: Regular expressions that can capture specific formats (such as email addresses).

[0189] Dynamic translation

[0190] In some implementations, the end user 100 of the omnichannel system can be global, and different users can enter queries into the virtual agent function in various different languages. Furthermore, the real-time agent 200 using the omnichannel system can also have its own preferred language. Finally, the virtual agent program 402 and the NLU module 404 will use a default language, such as English.

[0191] In some implementations, the virtual agent functionality can provide real-time dynamic language translation. Specifically, a virtual agent chatbot or voice bot can translate in real-time conversations between a user 100 speaking their first language and a virtual agent 402 or real-time agent 200 speaking their second language. The virtual agent can also translate ticket and transaction data provided by the user in their preferred language into a second language, enabling support agents (such as...) to process these tickets. Figure 2 The service agent (618) can understand the user's query / question and take appropriate action.

[0192] Figures 7a and 7c illustrate example self-service interactions with the virtual agent function 402 in embodiments of the present invention. In the embodiments of Figures 7a and 7c, the virtual agent is a chatbot. Figures 7a and 7c show screenshots of chatbot conversations visible to user 100 on workstation 300.

[0193] In step 952 shown in Figure 7a, user 100 is prompted to select their preferred language. In this example, user 100 selects Spanish. In this example, the default language of the virtual agent function 402 is English.

[0194] In step 954 shown in Figure 7b, the virtual agent 402 then continues the dialogue with the user 100 in Spanish. If the language used for the user's input differs from the language the NLU model is trained to process (the default language), the input query can be translated from the input language to the language of the NLU model before being processed by the NLU module 404. Furthermore, any output from the virtual agent (e.g., for the user's follow-up questions or automated actions based on determined intent) can be translated from the default language of the virtual agent and the NLU model back to the user's preferred language. The translation can be performed by a dynamic translation module (not shown), which in some embodiments may reside on server 400 or in the cloud.

[0195] In step 956 shown in Figure 7c, user 100 (in Spanish) requests the virtual agent to connect the user to the live agent. The dynamic translation module translates this request into English, and then the NLU module 404 determines the user's intent based on the English translation. The virtual agent then performs the automated actions to connect user 100 to the live chat with the live agent 200 in Figure 7c.

[0196] In this implementation, the preferred language of the real-time agent is English, while the user's preferred language is Spanish. The omnichannel system 1000 can perform real-time dynamic translation to translate chat conversations into both the user's preferred language and the real-time agent's preferred language. For example, the dynamic translation module can translate user 100's Spanish input into English before displaying it on the real-time agent's workstation. Similarly, the real-time agent's English responses can be translated back into Spanish before being displayed to user 100 at workstation 300.

[0197] Figure 8a shows an example of this dynamic translation, illustrating an agent console 406 in one implementation where the dialogue in Figure 7c has been dynamically translated into English in real time for agent 200.

[0198] Furthermore, Figure 8b illustrates an example of the agent console 406 in another embodiment, where a conversation with end user 100, who is messaging in French, has been dynamically translated into English in real time for the real-time agent 200. In the embodiment of Figure 8b, a notification at the top of the real-time agent's chat window indicates the source language of user 100. The real-time agent 200 can enable and disable dynamic translation in its chat window for each chat session.

[0199] In each of the above implementations, the omnichannel system 1000 can translate conversations between the user and the real-time / virtual agent in real time and dynamically. Cloud translation services (e.g., Google Translate) can be used for translation. In addition to translating user-agent conversations, interaction and event data can also be translated. This enables the real-time agent 200 and the virtual agent 402 to freely converse with the user 100.

[0200] Finally, in some implementations, the virtual agent may be able to perform language detection, so that conversations with users who have already selected their preferred language can be routed to a real-time agent equipped with the ability to handle that language.

[0201] Although the features of the embodiments outlined above have been described individually, these features may be combined in different ways where appropriate. Various modifications to the above embodiments are possible and will be apparent to those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. A method for secure communication between a device and a computer program running on a server, the method comprising the following steps: Generic user identification information based on the current user account logged in on the device is sent from the device to the server; The server identifies the general user identification information as corresponding to an authorized entity pre-registered with the server; The server sends an identification token associated with the permitted entity to the remote management module, which stores a registry of registered devices. The remote management module uses registry entries stored for the device to perform a remote action on the device, wherein the remote action transmits the identification token to the device; Send the identification token from the device to the server; and Access to the computer program is granted to the device based at least in part on a match between the identification token sent by the server and the identification token received by the server from the device.

2. The method of claim 1, further comprising the following steps: The server generates a one-time authentication token; The server sends the one-time authentication token and the identification token to the remote management module; The one-time authentication token and the identification token are transmitted to the device; The device sends the one-time authentication token and the identification token to the server; The device is allowed access to the computer program based at least in part on a match between the one-time authentication token generated by the server and the one-time authentication token received by the server from the device.

3. The method as described in claim 2, wherein, The one-time authentication token is a randomly generated code.

4. The method as described in any of the preceding claims, wherein, The general user identification information includes one or both of the following: the organization name associated with the current user account logged in on the device, and / or the location associated with the device.

5. The method of claim 4, wherein, The general user identifier does not include the identity of the specific person using the device.

6. The method as described in claim 4 or 5, wherein, The step of identifying the general user identification information as corresponding to an authorized entity includes: confirming that the organization name and / or the location appears in a list of authorized organizations and / or locations that are pre-registered with the server and have permission to access the computer program.

7. The method according to any one of claims 4 to 6, wherein: The general user identification information includes both the organization name associated with the current user account logged in on the device and the location associated with the device; and Identifying the general user identification information as corresponding to an authorized entity includes: confirming that the organization name and location pair appears in a list of authorized organization and location pairs pre-registered with the server and having permission to access the computer program.

8. The method of claim 6 or 7, wherein, The identification of the general user identification information as corresponding to an authorized entity is independent of the identity of the specific person using the device.

9. The method of any one of claims 4 to 8, further comprising the following steps: Prevent the device from accessing, via the computer program, the organization name and / or location for which it lacks authorization regarding the general user identification information, data, and / or functions.

10. The method of claim 4 or 9, wherein: Data for multiple organizations is stored in a data storage unit, where data for each organization is stored in a different domain; and The method further includes the step of: preventing the device from accessing any storage domain other than the storage domain containing data of the organization associated with the current user account logged in on the device via the computer program.

11. The method as claimed in any of the preceding claims, wherein, The server includes an identifier token stored on the server for each permitted entity that has been pre-registered to the server.

12. The method as described in any of the preceding claims, wherein, Each allowed entity is an allowed organization name and / or location, preferably an allowed organization name and location pair.

13. The method of claim 12, wherein, The identification token is a digest code generated by performing a hash function on the allowed organization name and / or location.

14. The method as claimed in any of the preceding claims, wherein, The device is installed in one of the following locations: an airport, a train station, a port, or a transportation hub.

15. The method according to any one of claims 1 to 13, wherein, The general user identification information includes one or both of the following: the name of the airline or ground service provider associated with the user account logged in on the device, and / or the airport where the device is installed.

16. The method as claimed in any of the preceding claims, wherein, The device is any of the following: tablet computer; smartphone; mobile device; CUTE device; multi-tenant device; connectivity device; airport workstation; kiosk; self-service baggage storage unit; biosafety equipment.

17. The method of any of the preceding claims, further comprising the steps of: Send at least one of the following, along with the general user identification information, from the workstation to the server: the hostname of the device; the device identifier for the device included in the registry of the registered device; and information indicating the node of the remote management module associated with the device.

18. The method of claim 17, further comprising the following steps: Send at least one of the following, along with the identification token, from the server to the remote management module: the device identification code for the device included in the registry of the registered device; and information indicating the node of the remote management module associated with the device.

19. The method of any of the preceding claims, further comprising the following steps: Perform a check to see if the identification token passed from the remote management module to the device matches the current user account logged in on the device.

20. The method as claimed in any of the preceding claims, wherein, The computer program is a virtual agent function.

21. The method of claim 20, further comprising the following steps: The user of the device inputs a query into the virtual agent function; The input query is processed using a Natural Language Understanding (NLU) module to determine the intent of the input query; as well as The virtual agent function performs automated actions based on the determined intent.

22. The method of claim 21, wherein, The virtual agent function is an automated chatbot, and the input query is a text command entered via the device.

23. The method of claim 21, wherein: The virtual agent function is an automated voice robot; The input query is a voice command input via the device; and The method further includes converting the speech command into a text command via a speech-to-text module before processing by the NLU module.

24. The method of any one of claims 21 to 23, further comprising the following steps: The input query is translated from the first language into the second language before being processed by the NLU module.

25. The method according to any one of claims 21 to 24, wherein, The NLU module is trained using a dataset that includes air transport industry-specific terminology.

26. The method of any one of claims 20 to 25, further comprising the following steps: The user input of the device selects a first prompt from a plurality of prompts presented on the device by the virtual agent function; The virtual agent function performs automated actions based on the selected prompts.

27. The method according to any one of claims 21 to 26, wherein, The automated action is at least one of the following: - Instruct the remote management module to perform remote actions on the device; - Instruct the remote management module to reboot the device or peripheral devices connected to the device; - Instruct the remote management module to restart the service running on the device; - Instruct the remote management module to perform repair actions on the device or peripheral devices connected to the device; - Instruct the remote management module to perform a health check on the device, and optionally display a report of the health check on the device; - Records will be entered into a central database.

28. The method according to any one of claims 21 to 26, wherein, The device is the first device, and the automated action includes recording the failure of the second device in a central database.

29. The method according to any one of claims 21 to 26, wherein, The automated actions include retrieving data from the data storage unit and outputting the data to the user of the device.

30. The method of claim 29, wherein, The conditions for obtaining and / or outputting the data are the organization name associated with the current user account logged in on the device and / or the location associated with the device.

31. The method according to any one of claims 21 to 26, wherein, The automated actions include initiating communication channels with the real-time agent.

32. The method of claim 31, further comprising the following steps: Receive input in a first language from the user of the device; The input is translated in real time into a second language set by the real-time agent by the dynamic translation module.

33. A secure communication system, the system comprising: equipment; A server, on which computer programs run; as well as A remote management module, which stores the registry of registered devices; in: The device is configured to send general user identification information based on the current user account logged in on the device to the server; The server is configured to identify the general user identification information as corresponding to an authorized entity, and then send an identification token associated with the authorized entity to the remote management module; The remote management module is configured to perform a remote action on the device using registry entries stored for the device, wherein the remote action is configured to pass the identity token to the device; The device is configured to send the identification token to the server; and The server is configured to allow the device to access the computer program based at least in part on a match between the identity token sent by the server and the identity token received from the device.

Images