Patent Description:
Hardware devices are manufactured and shipped to customers. A hardware device is installed at a customer site and connected to a network (e.g., the Internet). Typically, the hardware device is indirectly connected to the Internet via a firewall. The hardware device then needs to establish a communication session with a manager node so that the manager node can onboard the hardware device. There are two ways to establish the communication session between the manager node and the hardware device.

The first way is to configure the manager node with the necessary information for establishing the communication session with the hardware device. The necessary information may include a domain name or public Internet Protocol (IP) address and a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) endpoint for the hardware device. Using the information for establishing the communication session with the hardware device, the manager node can contact the hardware device and establish a communication session.

The second way is to configure the hardware device with the necessary information (e.g., domain name or public IP-address and TCP/UDP endpoint for the manager node) for establishing the communication session with the manager node. Using the information for establishing the communication session with the manager node, the hardware device can contact the manager node and establish a communication session.

The configuration of the hardware device typically occurs in one of two ways. The first configuration method is to preconfigure the information into the hardware device during the manufacturing or shipping process as soon as it is clear which customer will receive the hardware device. The second configuration method is to configure the information at the customer site either by a technician or the customer itself.

The prior art document <CIT> presents a discoverable peer-to-peer (P2P) service to remotely "onboard" devices over a Wi-Fi network, wherein an onboardee device may enter an onboarding mode in which the onboardee device becomes a Wi-Fi access point (AP) and an onboarder device connected to a private Wi-Fi network may discover the onboardee device and establish a secured session to engage with the P2P services running thereon.

Certain challenges presently exist with respect to the known ways of setting up the communication session between the manager node and the hardware device. For example, the first known way (i.e., configuring the manager node with the necessary contact information for establishing the communication session with the hardware device) suffers from a problem related to the customer networks. In order to protect their networks, customers usually use a firewall, which typically only permits outgoing communication session establishment. This means that the manager (even if configured with the necessary information) is not able to connect to the hardware device. Therefore, the first known way will not work in the usual situation where there is a firewall. Instead, when there is a firewall, the hardware device needs to initiate the communication session between hardware device and manager node.

The second known way (i.e., configuring the hardware device with the necessary contact information for establishing the communication session with the manager node) also suffers from problems. First, all hardware devices should not be preconfigured with contact information for the same manager node. This is because individual customers have different latency and data protection requirements, and a single manager node is generally not able to fulfill all requirements for all customers at the same time. Therefore, multiple manager nodes are needed, and which manager node is responsible for a given hardware device depends on the customer using the hardware device. Accordingly, all hardware devices should not be preconfigured to establish a communication session with the same manager node.

Second, hardware devices typically receive their initial configurations and are placed in storage before a customer order is received. The manager node contact information is customer specific, and it is not known which hardware device goes to which customer at the time the hardware device is initially configured. Accordingly, in this scenario, the manager information should not be configured during manufacturing or initial configuration.

Third, the warehousing and shipping company typically does not have access to configure the hardware devices and, therefore, cannot configure the hardware devices with customer-specific manager node contact information when the shipping process is initiated and the hardware device-customer relation is established.

Fourth, some business models and/or some customer requirements forbid a technician from the hardware device manufacturer from being at the customer site. In this case, a technician from the hardware device manufacturer may not be able to configure the manager node contact information at installation time on the customer site.

Aspects of the invention overcome one or more of these problems by providing a handover node to which hardware devices initially establish a communication session. In some embodiments, hardware devices may be preconfigured during initial configuration of the hardware devices with the contact information for the handover node. In some embodiments, the handover node may "handover" a hardware device to a manager node by transmitting to the hardware device contact information for the manager node, which the hardware device can then use to establish a communication session with the manager node.

In some embodiments, after physical installation of a hardware device at the customer site, the hardware device may automatically establish a communication session with the handover node. For example, a hardware device that has not yet been onboarded by a manager node may be configured such that when the hardware device is powered on the hardware device automatically executes a computer program (e.g., a daemon) that attempts to establish a communication session with the handover node. In some embodiments, the handover node may perform one or more checks on the hardware device once the communication session is established. In some embodiments, the one or more checks may include one or more of identifying physical installation errors, identifying software installation errors, and validity checks to make sure no third-party hardware is used and no malicious third-party can intrude into the system. In some embodiments, the handover node may provide one or more updates to the hardware device.

The manager node is informed of a hardware device identifier that identifies the hardware device. The manager node sends to the handover node one or more of the hardware device identifier and contact information for the manager node. In some embodiments, the contact information for the manager node may include, for example and without limitation, a domain name or an Internet Protocol (IP) address and port number (e.g., a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP)). In some embodiments, the contact information for the manager node may additionally or alternatively include virtual private network (VPN) contact information for a VPN. The VPN contact information may include: a domain name or a public Internet Protocol (IP) address of a VPN server, a TCP or UDP port number, a VPN certificate, etc. The handover node forwards the contact information for the manager node to the hardware device (e.g., using the established communication session between the handover node and the hardware device). The handover node instructs the hardware device to release the communication session established between the hardware device and the handover node and setup a new communication session with the manager node.

One aspect of the invention may provide a method performed by a handover node. The method may include receiving a first hardware device identifier transmitted by a hardware device. The first hardware device identifier may identify the hardware device. The method may include receiving a second hardware device identifier transmitted by a manager node. The second hardware device identifier may identify the hardware device. The method may include determining that the second hardware device identifier matches the first hardware device identifier. The method may include, as a result of determining that the second hardware device identifier matches the first hardware device identifier, transmitting contact information for the manager node to the hardware device. Another aspect may provide a handover node adapted to perform the method.

Yet another aspect of the invention may provide a method performed by a manager node. The method may include receiving a hardware device identifier that identifies a hardware device. The method may include transmitting the hardware device identifier to a handover node. The method may include transmitting contact information for the manager node to the handover node. The contact information may include a port number of the manager node different than a port number of the manager node used to communicate with the handover node. The method may include receiving a request to establish a communication session between the hardware device and the manager node. The request may been transmitted by the hardware device. Another aspect may provide a manager node adapted to perform the method.

Aspects of the invention may provide one or more of the following benefits. With respect to commercial benefits, the invention may provide the benefit of ease of installation of the hardware device for the customer. In some embodiments, the customer may not need to have technical knowledge for configuring the handover node with the correct contact information for a manager node. In some embodiments, this may reduce the amount of training needed for the customer and/or may reduce the amount of errors during installation. Also, the customer may be able to choose its own time plan for installation of the hardware device and does not need to wait on a technician or a specific time window.

With respect to technical benefits, in some embodiments, the manager node contact information, which the hardware device uses to establish a communication session with the manager node, originates on the manager node. Accordingly, in these embodiments, neither the handover node nor the hardware device needs to be pre-configured with a customer-specific configuration for establishing the communication with the manager node. This makes it possible to introduce or delete managers when needed without changes on the handover node or the hardware device.

Some embodiments may provide the technical benefit of establishing a communication session between the hardware device and a customer-specific manager node without the need for a manual configuration at the customer site (either by a technician or the customer itself). In some embodiments, due to the establishment of a communication session between the hardware device and a customer-specific manager node, customer-specific requirements (e.g., very low latency requirements and/or very strict data protection requirements) may be fulfilled (e.g., the hardware device may establish a communication session with the customer-specific manager node that is in the same geographical region as the hardware device).

Some embodiments may provide a technical benefit with respect to the nature of the handover node, which may function as a so-called demilitarized zone. In some embodiments, the handover node may check the validity of the hardware device before the hardware device gains access to the manager node and may thereby prevent intruders from gaining access to the manager node. In some embodiments, the handover node may additionally or alternatively provide updates of the software on the hardware device (e.g., to increase security or make an older hardware device compatible with a newer manager node).

<FIG> is a block diagram of a system including a handover node <NUM>, one or more hardware devices <NUM> (e.g., hardware devices 104A, 104B, and 104C), and one or more cloud environments <NUM> (e.g., cloud environments 106A, 106B, and 106C). In some embodiments, one or more of the cloud environments <NUM> may be customer-specific cloud environments. In some embodiments, the cloud environments <NUM> may be for different customers. In some embodiments, each of the one or more cloud environments <NUM> may include a manager node <NUM> (e.g., manager node 108A, 108B, or 108C) that manages the hardware associated with the cloud environment <NUM>. In some embodiments, the manager nodes <NUM> may include, for example, any available configuration management tool or self-created tools or scripts. In some embodiments, a manager node <NUM> consists of one or more computer programs that run on a virtual machine (VM) that runs on a server of a cloud computing environment. Similarly, in one embodiment, handover node <NUM> consists of one or more computer programs that run on a virtual machine (VM) that runs on a server of a cloud computing environment.

In some embodiments, each of the manager nodes <NUM> may have the ability to communicate with the handover node <NUM>. In some embodiments, the handover node <NUM> may assist in the establishment of communication sessions between hardware devices <NUM> and respective manager nodes <NUM>. In some embodiments, the handover node <NUM> may include, for example, any available configuration management tool or self-created tools or scripts. In some embodiments, the handover node <NUM> may enable automatic onboarding of a hardware device <NUM> (e.g., hardware device 104A) into a customer-specific cloud environment <NUM> (e.g., cloud environment 106A). In some embodiments, the automatic onboarding may occur without the need for any manual configuration of the hardware device <NUM> specific to the cloud environment <NUM>. For example, the handover node <NUM> enables a manager node <NUM> for a specific customer to onboard a hardware device provided to the customer (e.g., the manager node can onboard the hardware device by, for example, authenticating the hardware device, providing necessary configuration parameters to the hardware device, and/or performing other onboarding functions).

In some embodiments, a hardware device <NUM> may be, for example and without limitation, a server, a router, an access point, a switch, a gateway, etc. In some embodiments, the hardware device <NUM> may be purchased by a customer and shipped to a customer site. In some embodiments, the hardware device <NUM> may need to be connected to a manager node <NUM> of a cloud environment <NUM> dedicated to the customer so that the manager node <NUM> can onboard the hardware device (e.g., providing configuration parameters to the hardware device and/or obtaining configuration parameters from the hardware device). For example, as shown in <FIG>, a hardware device 104A has been shipped to a site of customer <NUM>, and the hardware device 104A needs to be connected to a manager node 108A of a cloud environment 106A dedicated to the customer <NUM>. Also, as shown in <FIG>, hardware devices 104B and 104C have been delivered to different customers. <FIG> shows steps of a handover process to establish a communication session between the hardware device 104A and the manager node 108A. <FIG> shows an intermediate point in the performance of the handover process with respect to the hardware device 104B, with the hardware device 104B having establishing a communication session with the handover node <NUM>. <FIG> also shows completion of performance of the handover process with respect to the hardware device 104C, with the hardware device 104C having established a communication session with the manager node 108C.

<FIG>, <FIG>, and <FIG> are handshake and state transition diagrams illustrating performance of the handover process with respect to the hardware device 104A according to some embodiments. In some embodiments, as shown in <FIG>, <FIG>, and <FIG>, the customer <NUM> may perform a step (<NUM>) in which the customer installs physically the hardware device 104A and connects the hardware device 104A to the customer's network infrastructure. As shown in <FIG>, after step (<NUM>), the hardware device 104A may be in the in an "unconnected" state <NUM> in which there is no established communication between the hardware device 104A and any of the handover node <NUM> and the manager nodes <NUM>.

In some embodiments, as shown by step (<NUM>) in <FIG>, the hardware device 104A may initiate a communication session with the handover node <NUM>. In some embodiments, the hardware device <NUM> may execute step (<NUM>) by transmitting a request (e.g., a TCP connection request) to establish a communication session between the hardware device 104A and the handover node <NUM>, and the handover node <NUM> may receive the request. In some embodiments, the hardware device 104A may transmit the request automatically (e.g., during boot). In some embodiments, the one or more hardware devices <NUM> including hardware device 104A may preconfigured with contact information for the handover node <NUM> (e.g., during an initial configuration of the hardware device <NUM> during manufacturing). In some embodiments, the hardware device 104A may initiate the communication session with the handover node <NUM> because customer networks typically use firewalls, such as the firewall <NUM> illustrated in <FIG> and <FIG>. The firewalls allow outgoing communication session establishment (e.g., communication sessions initiated by the hardware device 104A) but would not allow incoming communication session establishment (e.g., communication sessions initiated by the handover node <NUM>).

Step (<NUM>) of <FIG> shows a communication session established between the hardware device 104A and the handover node <NUM>. In some embodiments, the communication session may be established using, for example and without limitation, proprietary protocols (e.g., from the configuration management tools), well-known virtual private network (VPN) protocols, or other well-known protocols (e.g., the Secure Shell (SSH) protocol, the HyperText Transfer Protocol (HTTP), the HyperText Transfer Protocol Secure (HTTPS), the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), or other protocols). As shown in <FIG>, when the communication session between the hardware device 104A and the handover node <NUM> is established in step (<NUM>), the hardware device 104A may be in a state <NUM>. In some embodiments, one or more hardware devices <NUM> in addition to the hardware device 104A may establish a communication session with the handover node <NUM>. For example, as shown in <FIG>, the hardware device 104B may also establish a communication session with the handover node <NUM>.

In some embodiments, using the communication session between the hardware device 104A and the handover node <NUM>, the handover node <NUM> may perform one or more checks on the hardware device 104A. In some embodiments, the one or more checks may include identifying whether the hardware device 104A is a valid hardware device (e.g., as opposed to an intruder). In some embodiments, the validity check may be performed using one or more encryption keys. In some embodiments, the hardware device 104A may comprise a trusted platform model (TPM) that stores the one or more encryption keys. In such an embodiment, the hardware device 104A may use a private encryption key to generate a digital signature and then provide the digital signature to the handover node <NUM> to enable the handover node <NUM> to use a corresponding public key to confirm that the hardware device 104A has the appropriate private encryption key, thereby authenticating the hardware device 104A. However, it is not necessary that the hardware device 104A include a TPM, and, in some alternative embodiments, the hardware device 104A may not include a TPM.

In some embodiments, the one or more checks may additionally or alternatively include checking the physical and/or software installation of the hardware device 104A. In some embodiments, using the communication session between the hardware device 104A and the handover node <NUM>, the handover node <NUM> may perform one or more updates of the software of the hardware device 104A. In some embodiments, the handover node <NUM> act as a gatekeeper between the hardware devices <NUM> and the one or more manager nodes <NUM>. In some embodiments, the handover node <NUM> may establish a demilitarized zone, which makes it harder for intruders to gain access to the manager nodes <NUM>.

In some embodiments, as shown in <FIG>, the customer <NUM> may perform a step (3a) including reading a hardware device identifier that identifies the hardware device 104A. In some embodiments, the customer <NUM> may read the hardware device identifier from a printed label on the hardware device 104A and/or the packaging thereof. In some alternative embodiments, the hardware device identifier may be additionally or alternatively readable through software in an operating system on the hardware device 104A.

In some embodiments, as shown in <FIG>, <FIG>, and <FIG>, the customer <NUM> may perform a step (3b) in which the customer <NUM> provides the hardware device identifier to the manager node 108A of the cloud environment 106A dedicated to the customer <NUM>. In some embodiments, the customer <NUM> may transmit the hardware device identifier using a customer node, which may be operated by the customer <NUM> that managers the hardware device 104A. In some embodiments, the manager node 108A may receive the hardware device identifier.

In some embodiments, as shown in <FIG>, a customer portal <NUM> (e.g., an HTTP portal) may be used in step (3b) to provide the hardware device identifier to the manager node 108A. In these embodiments, as shown in <FIG>, step (3b) may include sub-step (3b-<NUM>) and sub-step (3b-i). In sub-step (3b-i), the customer <NUM> may transmit the hardware device identifier using the customer node (e.g., a web browser), and the customer portal <NUM> may receive the hardware device identifier. For example, prior to step 3b-i, the customer's web browser may receive from the portal <NUM> one or more web objects (e.g., HTML document, Javascript script, etc.) that cause the browser to display to the customer a web page that either enables the customer to input the hardware device identifier into the web page or select the hardware device identifier from one or more hardware device identifiers included in the web page and then cause the browser to transmit the input/selected hardware device identifier to the portal <NUM>.

In sub-step (3b-ii), the customer portal <NUM> may transmit the hardware device identifier, and the manager node 108A may receive the hardware device identifier. In some embodiments, the customer portal <NUM> may determine to which of the manager nodes <NUM> the hardware device identifier should be sent based on an identification of the customer <NUM> that transmitted the hardware device identifier. In some embodiments, the customer <NUM> may be identified based on information transmitted by the customer node of the customer <NUM> (e.g., login information for gaining access to the customer portal). In some embodiments, the customer portal <NUM> may include a lookup table for that associates customer identifications and/or login information with manager nodes.

In some embodiments, as shown by step (<NUM>) in <FIG>, the manager node 108A may transmit the hardware device identifier to the handover node <NUM>, and the handover node <NUM> may receive the hardware device identifier, which identifies the hardware device 104A. In some embodiments, the transmission of the hardware device identifier by the manager node 108A and the receipt thereof by the handover node <NUM> may be unseen from the point of view of the hardware device 104A. In some embodiments, in step (<NUM>), the manager node 108A may additionally transmit contact information for the manager node 108A, and the handover node <NUM> may receive the contact information. In some embodiments, the contact information may include, for example, a domain name or an Internet Protocol (IP) address of the manager node 108A and a port number (e.g., a TCP or UDP port) for the hardware device 104A to use in establishing a communication session with the manager node 108A. In some embodiments, the contact information may additionally or alternatively include VPN contact information (i.e., information that enables the hardware device 104A to contact and establish a session with a VPN server). Thus, the VPN contact information may include a domain name or a public Internet Protocol (IP) address of a VPN server, a TCP or UDP port number, a VPN certificate, etc..

In some embodiments, the hardware device 104A may transmit the hardware device identifier that identifies the hardware device 104A, and the handover node <NUM> may receive the hardware device identifier transmitted by hardware device 104A. In some embodiments, the handover node <NUM> may receive the hardware device identifier using the communication session between the hardware device 104A and the handover node <NUM>. In some embodiments, handover node <NUM> may retrieve the hardware device identifier using the established communication session with the hardware device 104A and the operating system of the hardware device 104A.

In some embodiments, the handover node <NUM> uses the received hardware device identifiers to determine to which of the hardware devices <NUM> the manager node 108A wants to connect. In some embodiments, the handover node <NUM> may determine whether the hardware device identifier transmitted by the manager node 108A matches the hardware device identifier transmitted by the hardware device 104A. In some embodiments, as a result of determining that the hardware device identifier matches the first hardware device identifier, the handover node <NUM> may transmit the contact information for the manager node 108A, which is shown as step (<NUM>) in <FIG>, and the hardware device 104A may receive contact information for the manager node 108A. In some embodiments, in response to receiving the contact information for the manager node 108A, the hardware device 104A may perform a handover. That is, for example, the hardware device 104A disconnects from the handover node <NUM> and uses the contact information for the manager node to transmit a message (e.g., TCP connection request) to the manager node 108A. In embodiments in which the contact information for the manager node includes VPN contact information, the hardware device 104A transmits the message to the manager node 108A via a VPN server.

In some alternative embodiments, in step (<NUM>), the handover node <NUM> may transmit one more signals in addition to the contact information for the manager node 108A. In these alternative embodiments, the hardware device 104A may receive the one or more signals, and the one or more signals may cause the hardware device 104A to initiate performance of the handover. In some other alternative embodiments, in step (<NUM>), the handover node <NUM> may transmit one more signals commands or scripts (e.g., in a JavaScript Object Notation (JSON) object) in addition to the contact information for the manager node 108A. In these other alternative embodiments, the hardware device 104A may receive and execute the one or more one more commands or scripts, and execution of the one or more received commands or scripts may cause the hardware device 104A to perform the handover.

In some embodiments, as shown in <FIG>, the handover may include a step (<NUM>) in which the hardware device 104A disables (e.g., tear down) the communication session with the handover node <NUM>. In some embodiments, as shown in <FIG>, disabling the communication session with the handover node <NUM> may leave the hardware device 104A in a state <NUM> in which there is no established communication between the hardware device 104A and any of the handover node <NUM> and the manager nodes <NUM>. However, in state <NUM>, the hardware device 104A has the contact information for the manager node 108A, which the hardware device 104A may use to establish a communication session with the manager node 108A of the cloud environment 106a associated with the customer <NUM>.

In some embodiments, as shown in <FIG>, the handover may include a step (<NUM>) in which the hardware device 104A may initiate a communication session with the manager node 108A. In some embodiments, the hardware device <NUM> may execute step (<NUM>) by transmitting a request to establish a communication session between the hardware device 104A and the manager node 108A, and the manager node 108A may receive the request. In some embodiments, the hardware device 104A may initiate the communication session with the manager node 108A because, as noted above, customer networks typically use firewalls, such as the firewall <NUM> illustrated in <FIG> and <FIG>. The firewalls allow outgoing communication session establishment (e.g., communication sessions initiated by the hardware device 104A) but would not allow incoming communication session establishment (e.g., communication sessions initiated by the manager node 108A). Step (<NUM>) of <FIG> shows a communication session established between the hardware device 104A and the manager node 108A. In some embodiments, the communication session may be established using, for example and without limitation, proprietary protocols (e.g., from the configuration management tools), well-known VPN protocols, or other well-known protocols (e.g., the SSH protocol, the HTTP, the HTTPS, the TCP, the UDP, or other protocols). As shown in <FIG>, when the communication session between the hardware device 104A and the manager node 108A is established in step (<NUM>), the hardware device 104A may be in the in a state <NUM>.

In embodiments where the contact information for the manager node 108A includes VPN contact information, the hardware device 104A may establish the communication session with manager node 108A through a VPN server. In some embodiments, the VPN server may allow communications transmitted by the hardware device 104A inside the cloud environment 106A so that they may reach the manager node 108A. In some embodiments, the hardware device 104A may communicate with the manager node 108A by transmitting one or more IP packets that (i) are addressed to the VPN server and (ii) including in its payload an IP packet that is addressed to the manager node 108A. In some embodiments, the VPN server may receive the IP packets addressed to the VPN server and transmit the IP packets addressed to the manager node 108A. The manager node 108A may receive the IP packets addressed to the manager node 108A, which were transmitted hardware device 104A through the VPN server.

In some embodiments, the handover node <NUM> may act as a mediator between the different cloud environments <NUM> and their managers <NUM>, enabling the hardware devices <NUM> to connect to a preconfigured central node (i.e., the handover node <NUM>). However, through the handover, it is possible to still have dedicated manager nodes <NUM>, which can be placed geographically close to the respective hardware devices <NUM>, and for establishment of a direct or indirect connection between the manager nodes <NUM> and the hardware devices <NUM>. In some embodiments, the information flow, which may go from a manager node <NUM> through the handover node <NUM> to a hardware device <NUM>, may enable the solution to scale easily without the need to reprogram either of the handover node <NUM> and the hardware devices <NUM>.

<FIG> illustrates a process <NUM> performed by a handover node <NUM> according to some embodiments. Although the process <NUM> is illustrated in <FIG> for one hardware device <NUM> and one manager node <NUM>, the process <NUM> may be performed simultaneously for multiple hardware devices <NUM> and/or multiple manager nodes <NUM>. In some embodiments, one or more of the steps of the process <NUM> shown in <FIG> with dashed lines may be optional steps.

In some embodiments, the process <NUM> may optionally include a step s402 in which the handover node <NUM> receives a request to establish a communication session between a hardware device 104A and the handover node <NUM>. In some embodiments, the request may be transmitted by hardware device 104A.

In some embodiments, the process <NUM> may optionally include a step s404 in which, after the session is established, the handover node <NUM> performs one or more checks on the hardware device 104A. In some embodiments, performing the one or more checks on the hardware device 104A may include identifying whether the hardware device 104A is valid. In some embodiments, performing the one or more checks on the hardware device may additionally or alternatively include checking the physical and/or software installation of the hardware device 104A.

The processs <NUM> includes a step s406 in which the handover node <NUM> receives a first hardware device identifier transmitted by the hardware device 104A. The first hardware device identifier identifies the hardware device 104A. In some embodiments, the handover node <NUM> receives the first hardware device identifier using the communication session between the hardware device 104A and the handover node <NUM>.

The process <NUM> includes a step s408 in which the handover node <NUM> receives a second hardware device identifier transmitted by a manager node 108A. The second hardware device identifier identifies the hardware device 104A. In some embodiments, the handover node <NUM> may perform steps s406 and s408 sequentially or simultaneously. In some embodiments, the handover node <NUM> may perform step s406 before or after step s408.

The process <NUM> includes a step s410 in which the handover node <NUM> receives contact information for the manager node 108A. The contact information is transmitted by the manager mode 108A. In some embodiments, the handover node <NUM> may perform steps s408 and s410 sequentially or simultaneously. In some embodiments, the handover node <NUM> may perform step s408 before or after step s410. In some embodiments, the handover node <NUM> may receive the second hardware device identifier and the contact information for the manager node 108A in a single message. In some alternative embodiments, the handover node <NUM> may receive a first message including the second hardware device identifier and a second message including the contact information for the manager node 108A.

The process <NUM> includes a step s412 in which the handover node <NUM> determines that the second hardware device identifier matches the first hardware device identifier. In some embodiments, the process <NUM> may include a step s414 in which the handover node <NUM>, as a result of determining that the second hardware device identifier matches the first hardware device identifier, transmits contact information for the manager node 108A to the hardware device 104A. In some embodiments, the handover node <NUM> transmits the contact information using the communication session between the hardware device 104A and the handover node <NUM>.

<FIG> illustrates a process <NUM> performed by a manager node 104A according to some embodiments. In some embodiments, the process <NUM> may include a step s502 in which the manager node 108A receives a hardware device identifier that identifies a hardware device 104A. In some embodiments, the received hardware device identifier is transmitted by a node (e.g., a web browser) operated by a customer <NUM> managing the hardware device 104A.

In some embodiments, the process <NUM> may include a step s504 in which the manager node 108A transmits the hardware device identifier to a handover node <NUM>.

In some embodiments, the process <NUM> may include a step s506 in which the manager node 108A transmits contact information for the manager node to the handover node 104A. In some embodiments, the contact information may include a port number of the manager node 108A different than a port number of the manager node 108A used to communicate with the handover node <NUM>. In some embodiments, transmitting the contact information may include transmitting a network layer protocol data unit (PDU) that includes a network layer header and a transport layer PDU. In some embodiments, the transport layer PDU may include a transport layer header and a transport layer payload. In some embodiments, the transport layer payload may include the contact information. In some embodiments, the network layer header may include a domain name or an Internet Protocol (IP) address of the manager node. In some embodiments, the transport layer header may include the port number of the manager node 108A used to communicate with the handover node <NUM>, and the transport layer payload comprises the port number of the manager node 108A that is different than the port number of the manager node 108A used to communicate with the handover node <NUM>.

In some embodiments, the manager node 108A may perform step s504 before, after, or simultaneously with the step s506. In some embodiments, the manager node 108A may transmit the hardware device identifier and the contact information is a single message. In some embodiments, the transport layer payload of a transport layer PDU of a network layer PDU may include (i) hardware device identifier and (ii) the port number of the manager node 108A that is different than the port number of the manager node 108A used to communicate with the handover node <NUM>. In some alternative embodiments, the manager node 108A may transmit the hardware device identifier and the contact information in first and second messages, respectively.

In some embodiments, the process <NUM> may include a step s508 in which the manager node 108A receives a request to establish a communication session between the hardware device and the manager node. In some embodiments, the request may have been transmitted by the hardware device 104A.

<FIG> is a block diagram of a handover node <NUM>, a hardware device <NUM> (e.g., hardware device 104A), or a manager node <NUM> (e.g., manager node 108A) according to some embodiments. As shown in <FIG>, one or more of the handover node <NUM>, hardware device <NUM>, and manager node <NUM> may comprise: processing circuitry (PC) <NUM>, which may include one or more processors (P) <NUM> (e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed; a network interface <NUM> comprising a transmitter (Tx) <NUM> and a receiver (Rx) <NUM> for enabling the handover node <NUM>, hardware device <NUM>, or manager node <NUM> to transmit data to and receive data from other nodes connected to a network <NUM> (e.g., an Internet Protocol (IP) network) to which network interface <NUM> is connected; and a local storage unit (a. , "data storage system") <NUM>, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments where PC <NUM> includes a programmable processor, a computer program product (CPP) <NUM> may be provided. CPP <NUM> includes a computer readable medium (CRM) <NUM> storing a computer program (CP) <NUM> comprising computer readable instructions (CRI) <NUM>. CRM <NUM> may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI <NUM> of computer program <NUM> is configured such that when executed by PC <NUM>, the CRI causes handover node <NUM>, hardware device <NUM>, or manager node <NUM> to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, the handover node <NUM>, hardware device <NUM>, or manager node <NUM> may be configured to perform steps described herein without the need for code. That is, for example, PC <NUM> may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

<FIG> is a block diagram of a handover node <NUM> according to some embodiments. As shown in <FIG>, in some embodiments, the handover node <NUM> may include a receiving module <NUM> for receiving a first hardware device identifier transmitted by a hardware device 104A. In some embodiments, the first hardware device identifier may identify the hardware device 104A. In some embodiments, the handover node <NUM> may include a receiving module <NUM> for receiving a second hardware device identifier transmitted by a manager node 108A. In some embodiments, the second hardware device identifier identifies the hardware device. In some embodiments, the handover node <NUM> may include a determining module <NUM> for determining that the second hardware device identifier matches the first hardware device identifier. In some embodiments, the handover node <NUM> may include a transmitting module <NUM> for, as a result of determining that the second hardware device identifier matches the first hardware device identifier, transmitting contact information for the manager node 108A to the hardware device 104A.

<FIG> is a block diagram of manager node <NUM> according to some embodiments. As shown in <FIG>, in some embodiments, the manager node <NUM> may include a receiving module <NUM> for receiving a hardware device identifier that identifies a hardware device <NUM>. In some embodiments, the manager node <NUM> may include a transmitting module <NUM> for transmitting the hardware device identifier to a handover node <NUM>. In some embodiments, the manager node <NUM> may include a transmitting module <NUM> for transmitting contact information for the manager node <NUM> to the hardware device <NUM>. In some embodiments, the contact information may include a port number of the manager node <NUM> that is different than a port number of the manager node <NUM> used to communicate with the handover node <NUM>. In some embodiments, the manager node <NUM> may include a receiving module <NUM> for receiving a request to establish a communication session between the hardware device <NUM> and the manager node <NUM>. In some embodiments, the request may have been transmitted by the hardware device 104A.

While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the scope of this disclosure should not be limited by any of the above-described exemplary cases but is solely defined by the appended claims.

Claim 1:
A method (<NUM>) performed by a handover node (<NUM>), the method comprising:
receiving (s406) a first hardware device identifier transmitted by a hardware device (104A), which is separate and distinct from the handover node, the first hardware device identifier identifying the hardware device;
receiving (s408) a second hardware device identifier transmitted by a manager node (108A), which is separate and distinct from the handover node and the hardware device, the second hardware device identifier identifying the hardware device;
determining (s412) that the second hardware device identifier matches the first hardware device identifier; and
as a result of determining that the second hardware device identifier matches the first hardware device identifier, transmitting (s414) contact information for the manager node to the hardware device, wherein the handover node instructs the hardware device to release the communication session established between the hardware device and the handover node and setup a new communication session with the manager node using the said contact information.