Method and device for realizing secure data transmission between input / output device processors

Abstract

There is suggested a method of an IODH managing a first set of IODs comprising at least one first IOD, the first set of IODs providing an ongoing session between a user tag (UT) and a server, the method comprising: receiving, from a second IODH managing a second IOD in a second set of IODs, information received by the second IOD about a beacon signal, wherein the information comprises IOD specific information about the second IOD and session specific information about the ongoing session; based at least in part on the received information, a determination is initiated as to whether participation of at least a portion of an IOD managed by the second IODH in the ongoing session is allowed or prohibited, and in response to having known that participation of at least a portion of the second IOD in the ongoing session is allowed, the second IODH is activated. And manage participation of at least a portion of the second IOD in the ongoing session based at least in part on information about the beacon signal received from the second IODH.

Description

Technical Field

[0001] The disclosed embodiments relate to methods for enabling secure transmission of data associated with an ongoing session between two input / output handlers, and input / output handlers adapted to perform such methods. Background Art

[0002] There are various solutions on the market that enable wireless access, sharing, and use of hardware resources available in a specific environment, room, or network, such as Apple TV, Sun stateless terminals, or video conferencing systems. However, all of these solutions have one thing in common: the user logs in to the corresponding communication system in some way, and the devices owned by this communication system are defined by the system itself.

[0003] A flexible scheme and method are known that implement a secure association between cloud-based services and available devices present in the user's vicinity. A user who registers and authenticates with the cloud service carries a user device associated with the cloud service, such as a user tag (UT) or dongle, which can be anything from a constrained device to a smart device. Such services can be provided via one or more input / output devices (IODs) located in the vicinity of the user device. These IODs are associated with, registered with, and managed by an input / output device handler (IODH) capable of controlling or managing the IODs. However, current schemes for changing the IODs involved in an ongoing session do not consider that these IODs may be controlled by different IODDHs. Summary of the Invention

[0004] To further improve the above scheme, a mechanism for handling transmission and cooperation between IODHs is proposed.

[0005] According to a first aspect, a method is proposed for an IOD (herein referred to as a first IOD) to manage a first set of IODs, including at least one first IOD, that provides an ongoing session between a user tag (UT) and a server. The method comprises: receiving information regarding a beacon signal received by a second IOD from another IOD (herein referred to as a second IOD), wherein the second IOD manages a second IOD in a second set of IODs, wherein the information comprises IOD-specific information regarding the second IOD and session-specific information regarding the ongoing session. The method further comprises: initiating a determination, based at least in part on the received information, as to whether to allow or disallow at least some of the second IODs managed by the second IOD to participate in the ongoing session; and, in response to knowing that at least some of the second IOD's participation in the ongoing session is allowed and based at least in part on the information regarding the beacon signal received from the second IOD, managing at least some of the second IOD's participation in the ongoing session. By applying the proposed method, it is possible to expand the geographic area in which a user can access services, as described herein.

[0006] According to another aspect, a method is provided for a second IODH to process information about a second IOD managed by the second IODH, wherein the method comprises: receiving information about a beacon signal from the second IOD, wherein the information comprises IOD-specific information about the second IOD and session-specific information about a session ongoing via at least a portion of a first IOD managed by the first IODH, and forwarding at least a portion of the information about the beacon signal and an identity of the second IODH to the first IODH. By applying the proposed method, the second IODH enables the first IODDH to collaborate with the second IODDH regarding a particular ongoing session, thereby enhancing the area in which users can access services, as described herein.

[0007] According to yet another aspect, a first IODH is provided, wherein the first IODH comprises a processor circuit and a memory, the memory comprising computer-readable instructions that, when executed by the processor circuit, cause the first IODH to receive information regarding a beacon signal received by a second IOD from a second IOD managing the second IOD in a second set of IODs, wherein the received information comprises IOD-specific information about the second IOD and session-specific information about an ongoing session, cause the first IODH to initiate a determination based at least in part on the received information regarding whether to allow or disallow at least a portion of the IOD managed by the second IOD to participate in the ongoing session, and cause the first IODH to manage at least a portion of the second IOD's participation in the ongoing session in response to learning that at least a portion of the second IOD's participation in the ongoing session is allowed and based at least in part on the information regarding the beacon signal received from the second IODH.

[0008] According to another aspect, a second IODH is provided, wherein the second IODH comprises a processor circuit and a memory, the memory comprising computer-readable instructions that, when executed by the processor circuit, cause the second IODH to receive information regarding a beacon signal from a second IOD, wherein the received information comprises IOD-specific information regarding the second IOD and session-specific information regarding a session ongoing via at least a portion of the first IOD managed by the first IODH, and further cause the second IODH to forward at least a portion of the information regarding the beacon signal and an identity of the second IODH to the first IODH.

[0009] In general, unless otherwise expressly defined herein, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field. Unless otherwise expressly stated, all references to "an / the element, device, component, means, step, etc." should be broadly interpreted as referring to at least one instance of the element, device, component, means, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein do not have to be performed in the exact order disclosed. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated herein and constitute a part of the specification, illustrate various embodiments.

[0011] Figure 1 An exemplary signaling diagram according to one embodiment configured as suggested herein is shown, illustrating how a session may be established in the system.

[0012] Figure 2 A method of managing an ongoing session at an IODH and receiving information about a beacon signal associated with the ongoing session from another IODH is shown.

[0013] Figure 3 In more detail, the embodiment of the present invention is shown Figure 2 Part of the method shown.

[0014] Figure 4 A method of providing, at an IODH, information about beacon signals associated with an ongoing session to another IODH that manages the ongoing session is shown.

[0015] Figure 5 Shown Figures 2 to 4 Signaling diagram of the illustrated method.

[0016] Figure 6 is a block diagram illustrating managing an IODH according to one embodiment.

[0017] Figure 7 is a block diagram illustrating managing an IODH according to another embodiment.

[0018] Figure 8 is a block diagram illustrating an IODH that receives information about a beacon signal from another IODH, according to one embodiment.

[0019] Figure 9 is a block diagram illustrating an IODH that receives information about a beacon signal from another IODH according to another embodiment. DETAILED DESCRIPTION

[0020] While the flexible wireless access concept described above can be implemented with just one IODH, a possible network configuration could include multiple IODHs, each covering a different geographic region or jurisdiction, with each of these IODHs managing a different IOD domain. In one scenario, a company might, for example, have an IODH operating as a management node, covering all IODs, forming a private IOD domain within the company's premises, while a city or local area might control public IODs within the public IOD domain. In another scenario, a user might deploy an IODH in their home, which could be referred to as a smart home, to control IODs in the private IOD domain, while a transportation infrastructure company might have multiple IODs capable of managing IODs in a vehicular environment. Other IODHs might involve operating IODs for, for example, National Security and Public Safety (NSPS) purposes.

[0021] The present disclosure focuses on a scenario where a user of a UT begins in a first geographic region, utilizing a first set of IODs handled or managed by one IODH (referred to herein as the first IODH). The UT then moves from the first geographic region to a second geographic region where both the first set of IODs and a second set of IODs handled or managed by another IODH (referred to herein as the second IODH) exist, and both sets of IODs are now able to receive beacon signals associated with an ongoing session from the UT and are able to provide capabilities to the UT.

[0022] When an IOD handled by a second IODH receives and recognizes a beacon signal from a UT, the second IODH notifies the first IODH that it has recognized a beacon signal received from an IOD that the first IODH is not currently managing. The second IODH notifies the first IODH of IOD-specific information, such as the signal strength of the beacon signal when received by the IOD, and may also notify the capabilities available at the IOD, as well as session-related information in the form of a session identity, allowing the second IODH to associate the IOD with the ongoing session. An IODH typically knows the capabilities available at the IODs it manages from internal memory or memory accessible to the IODH, but needs to be informed of the capabilities of IODs managed by another IODH. Signal strength is required to determine whether an IOD, or certain capabilities of the IOD, are preferred for provisioning the ongoing session.

[0023] When handling an ongoing session, a first IODH responds to such information by determining whether an IOD controlled by a second IODH can be included in the ongoing session currently being handled by the first IODH—that is, whether the two IODHs are allowed to collaborate. This is typically accomplished by consulting a policy that defines one or more criteria for making such a determination. If collaboration between the IODHs is allowed, signaling associated with the ongoing session will be forwarded from the second IODH to the first IODH from this point forward. Within the first IODH, this forwarded information will be processed similarly to information associated with the ongoing session and forwarded from the IOD managed by the first IODH to the first IODH. That is, if the signal strength of the beacon signal associated with the ongoing session and received by the IOD managed by the second IODH indicates that the IOD should be included in the set of IODs provided to the UT for the ongoing session, either by adding the IOD to the session or by replacing the currently used IOD with the IOD, the first IODH will consider that IOD for updating the active set of IODs, even if the IODs in that set will be managed by a different IODH from this point forward.

[0024] As an extension to the above method, a scenario can also be assumed in which all IODs providing an ongoing session are managed by a second IODH, i.e., all IODs previously managed by a first IODH when providing the ongoing session have now been deleted from the session or replaced by other IODs not managed by the first IODH, such that the first IODH now only handles IODs managed by the second IODH, and wherein the IODs and session-related information are forwarded from the second IODH to the first IODH. In the mentioned scenario, it can be determined that transferring the session from the first IODH to the second IODH results in the second IODH handling the session without any further involvement of the first IODH.

[0025] Now refer to Figure 1 The signaling scheme of the present invention further describes in detail the basic scenario showing how to establish a session in the system according to the configuration proposed in this article. Figure 1 In a scenario, a user using or carrying a user tag (UT) 110 (e.g., a dongle) wants to utilize a nearby I / O user device (IOD) (here represented by IOD A) that forms part of the IOD domain 100 in order to be able to access services provided by the server 120. The user may trigger this process, for example, by pressing a button on the UT 110 or by activating the UT 110 in any other way, thereby initiating the bootstrapping process 501.

[0026] UT 110 sends 502 an attach request to the system connected to IOD A through IOD A. IOD A forwards 503 the attach request to EAP authenticator 140 in the system. Alternatively, EAP authenticator 140 may be a local process within IOD A or the I / O user device handler (IODH) 130 that manages IOD domain 100, or may reside as a separate entity within IOD domain 100. Therefore, when EAP authenticator 140 is mentioned below, it can be interpreted as referring to IODH 130 if IODH 130 also has EAP authentication capabilities. Depending on the relevant configuration, either IODH 130 or EAP authenticator 140 processes the attach request.

[0027] The EAP authenticator 140 or IODH 130 responds 504 to the attach request with an EAP Identity Request, which is typically communicated back to the UT 110 via an EAP Response. The UT 110 responds to such a request by providing its identity identifying the UT 110 or the holder of the UT 110 and directing it to a user terminal emulation server (herein referred to as server 120) that can provide services to the user of the UT 110 via one or more IODs (herein represented by IOD A).

[0028] The server 120 and other system components may correspond to one or more networked physical computers, or may correspond to application server operating functions collectively provided by any number of networked physical computers operating in accordance with one or more embodiments disclosed herein (e.g., in a cloud computing environment). In some embodiments, because mobile phone functionality can be virtualized into a cloud computing environment, the user terminal emulation server (generally referred to herein as a server) and other system components may be referred to as a cloud phone.

[0029] The UT identity mentioned above may be configured as:

[0030] < hash(user_pub_key)>@<user_terminal emulation application_address> .

[0031] The hash of the public key provides a more compact identity of the public key of the UT 110 and can be included with the network address of the server 120. As described above, whenever the UT 110 is within the range of the IOD domain 100 connected to the described system, the server 120 can provide communication service functionality accessible to the user of the UT 110, which corresponds to, for example, an over-the-top Voice over Internet Protocol (VoIP) service, a Netflix service, a Facebook service, a Microsoft Teams conferencing service, a video streaming service, a DRM content viewing service, a social media service, a video conferencing service, an Internet browser service, or a cellular communication service.

[0032] When the UT 110 has been issued to the user, it may also have been associated with the corresponding server 120, which means that in addition to its own certificate (e.g., a private / public key pair), the UT 110 may also be configured with reachability information of the server 120 (e.g., in the form of a fully qualified domain name (FQDN)) and a certificate for authentication of the server 120 (e.g., in the form of a public key of the server 120). Likewise, the server 120 may have been configured with the certificate of the UT 110, such as the public key of the UT 110, so that the server 120 knows that the UT 110 is an entity authorized to request data flows and services from the server 120.

[0033] The EAP authenticator 140 identifies the server 120 based on the realm portion of the identifier and forwards the request to the server 120 , which here acts as an EAP server.

[0034] The EAP authenticator 140 first establishes a secure connection 506a between itself and the server 120. EAP messages are communicated over the secure channel between the authenticator 140 and the server 120. The secure connection may be, for example, a Transport Layer Security (TLS) session. The EAP authenticator 140 knows that it needs to communicate with the server 120 based on the identity (the domain portion of the identity) received in the EAP Identity Response 506b. The EAP authenticator 140 also knows that it needs to maintain a secure channel with the server 120. Therefore, if an existing secure session (typically TLS) does not exist, the EAP authenticator 140 creates one and then forwards the Identity Response 506b to the server 120. When using EAP messages, communication between the EAP authenticator 140 and the server 120 may be carried, for example, by the DIAMETER or RADIUS protocols.

[0035] The server 120 and UT 110 will perform an EAP exchange 507 to authenticate UT 110 to the server 120. The server 120 may also authenticate UT 110. This authentication may require multiple messages to be exchanged between UT 110 and server 120 via EAP authenticator 140.

[0036] Once the UT 110 and possibly the server 120 are successfully authenticated, the server 120 sends 508 a final EAP success message to the EAP authenticator 140. The EAP success message also carries a master key (e.g., a pairwise master key (PMK)) and a session-ID (session-ID), where the PMK key can be referred to as the master key for the session-ID. The PMK key can be used to derive further keys for an IOD (e.g., IOD X) (if the IOD needs to be added to the session as well).

[0037] In optional operation, UT 110 may derive a master key (e.g., a PMK key) at this stage, but it will not (necessarily) be used by UT 110. Assuming the user wants more control over which IODs are added to the session by having to actively (perhaps even physically) add more IODs to the session, the master key can be used if the user wants to authorize additional IODs (e.g., IOD X). The beacon protection key can also be derived from the PMK, from which the EAP authenticator 140 also derives the beacon protection key for its own use or for provision to the associated IODH, thereby allowing the IODH 130 to use this key to authenticate received beacons.

[0038] The EAP authenticator 140 generates 509 an IOD-specific key K_iodA from the received key material for use in streaming data between the server 120 and IOD A. Generating the IOD-specific key K_iodA may include using the received key material as is, or may include performing a computational operation on the received key material based on the PMK and the IOD-specific information, such as by hashing a concatenation of the key material and an identifier of IOD A and / or using another key derivation function (KDF).

[0039] The EAP authenticator 140 provides 510 the IOD-specific key K_iodA, directly or through the IODH 130, to IOD A, as well as the session-ID output by the server 120 and the address (e.g., FQDN) of the server 120. IOD A can use the received data to establish 511 a secure channel (e.g., TLS) between itself and the server 120. It should be noted that in some embodiments, in order to establish a secure channel between the IOD and the server 120, a shared secret (which is the first IOD-specific key K_iodA), an identifier for identifying who is connecting to the server 120 and for deriving the IOD-specific key, and an identifier (session-ID) that the server 120 can use to look up the context from which the corresponding K_iodA can be derived are required.

[0040] In operation 511, IOD A can use the session ID to indicate to server 120 the session / key material / authentication context to which the connection request relates. Server 120 locates the context and associated key material based on the received session ID. By way of background, IOD A will connect to server 120 using a secure channel so that server 120 can stream data to or receive data from IOD A. Therefore, IOD A needs to have key material available to establish a secure connection, and server 120 needs to verify that IOD A is authorized to send data in the session. Therefore, the session ID sent in operation 508 is something IOD A can send to server 120, so that server 120 knows that the request relates to an authentication session established for that session ID and can then locate its copy of the PMK and any other keys negotiated during authentication.

[0041] The IOD uses its own identifier (e.g., IOD A) as a username. IOD A thus tells server 120 who it is. EAP authenticator 140 has already derived an IOD A-specific key based on the PMK (e.g., by concatenating the IOD A ID and the PMK and then hashing the concatenated string), and may have truncated the hash value to a defined length. Server 120 needs to know IOD A's ID so that it can derive the same IOD A-specific key provided to IOD A, for example, in step 510.

[0042] Server 120 uses the IOD identifier to derive an IOD-specific key (K_iodA). IOD A uses the received key K_iodA as a password / authentication credential to authenticate with server 120. In this operation, IOD A and server 120 share the same IOD A-specific key, which is used as a shared secret by server 120 and IOD A to authenticate each other and establish a secure channel between them. Server 120 verifies through PSK-based authentication that the IOD possesses a valid session key (K_iodA) and is therefore authorized to connect to and exchange data with server 120. A secure channel is established between IOD A and server 120.

[0043] After successful authentication, IOD A may indicate 512 its UI capabilities (e.g., display, speaker, microphone, etc.) to IODH 130, which enables streaming data to and / or from IOD A based on the UI capabilities. The user may have defined policies for IODH 130 or server 120 regarding which operations are automatically enabled (e.g., streaming video to a display device for communication services) and which operations require explicit user consent before execution (e.g., enabling microphone use for communication services), or pre-configured policies may be applied. In a parallel, optional operation, IODH 130 may determine whether other IODs in the user's vicinity with UI capabilities that can be used to provide communication services to the user should be included in the ongoing session. These operations may provide server 120 with information about the capabilities of the IODs available to the user for the service in the ongoing session. Whether IODH 130 allows a change of IOD to participate in the ongoing session may depend, for example, on the services and / or applications running on server 120 or other policies applied by IODH 130.

[0044] Alternatively, as described above, the IODH 130 itself can also act as the EAP authenticator 140, in which case much of the "communication" between the authenticator and the IODH 130 is simplified, e.g., the PMK is used directly by the IODH 130 to securely communicate with the server 120, or an already established secure session is reused.

[0045] When the IODH 130, independently or triggered by the server 120, determines that some other IOD (e.g., IOD X) should join the ongoing session established between the user and the IOD domain 100, the IODH 130 may request 514 a EAP authenticator 140 to also generate credentials for IOD X, e.g., K_iodx, session-ID, server 110 FQDN, and provide these credentials to the other IOD.

[0046] The decision to require another IOD may depend on one or more of: the application and / or service activated by the user; the application and / or service in progress; the available devices and / or their respective UI capabilities; and / or a user-defined configuration to always attempt to find an IOD with specific UI capabilities. If the IOD receives 514c from the EAP authenticator 140 a trigger to connect to the server 110 (e.g., where the trigger is a certificate, etc.), the IOD X performs operations similar to those described above in operations 511 to 512.

[0047] Now refer to Figure 2 A method that may be performed on an IODH (referred to herein as a first IODH) is described in greater detail. The first IODH is managing one or more IODs that are currently providing a session between a server and a UT, wherein a beacon signal associated with the session is notified to the first IODH and received by an IOD managed by an IOD different from the first IODH (referred to herein as a second IODH).

[0048] In a first step 2:10, a first IODH receives information regarding beacon signals received by a second IOD managed by a second IODH, wherein the received information, including IOD and session-specific information, has been sent from or forwarded by the second IODH. In another step 2:20, a determination is initiated regarding whether to allow or disallow at least a portion of the second IOD to participate in the ongoing session. This initiation may involve the first IODH making the decision based on a policy applicable to the first IODH, or the initiation may involve requesting a decision from an external entity (e.g., a server) providing services through the ongoing session. The result of this determination is obtained, according to steps 2:30 and 2:40, indicating whether the two IODHs are allowed to collaborate in managing the ongoing session, or whether such collaboration is disallowed.

[0049] According to the "yes" branch of step 2:40, if the first IODH obtains a positive result, then according to step 2:70, the process can be performed by managing the second IOD when participating in the ongoing session. According to step 2:70, the first IODH manages at least part of the second IOD, wherein the management particularly relates to the second IOD participating in the ongoing session if it is determined in step 2:40 that at least part of the second IOD is allowed to participate in the ongoing session, and further based at least in part on information about beacon signals received from the second IODH, i.e., if the received information proves that the second IOD will participate in the ongoing session.

[0050] More specifically, the IOD-specific information includes at least an identity of the second IOD and an indication of the signal strength of the beacon signal when received by the second IOD, wherein the identity of the second IOD allows the first IODH to know that the IOD is being considered, and the indication of the signal strength of the beacon signal when received by the second IOD allows: once the first IODH has learned that the IOD is allowed to participate in the session and that the two IODHs are allowed to collaborate with each other when providing the same session, the first IOD can evaluate whether the second IOD is part of the set of IODs that are providing the ongoing session to the UT. The session-specific information includes at least a session identifier that allows the first IODH to identify the session associated with the beacon signal.

[0051] Unless the first IODH is not already aware of the capabilities of the second IOD, the IOD-specific information will also include at least one capability available at the IOD, requested by the UT, or both. In scenarios where each IOD includes only one capability, this information can be retrieved, for example, from a memory available to the first IODH once the identity of the second IOD becomes available to the first IODH, and thus will not need to be included in the received information. On the other hand, in situations where multiple capabilities are available at the IOD, this information will need to be included in the received information, where the availability of different capabilities may depend, for example, on whether they are currently being used by another session, whether they are allowed to be used in the current context, such as by the UT, at a relevant time of day, or in the current geographic area.

[0052] Determining step 2:20 may only be initiated if the first IODH has first authenticated the beacon signal as a legitimate beacon signal, specifically by verifying the content of the beacon signal. As described above, determining step 2:20 may be performed based on a policy applicable to the first IODH, wherein the policy may be based on one rule or a combination of rules. These rules may be IOD-specific, such that, for example, only certain IODs are allowed in a session at the same time. Other rules may be IOD-domain-specific, allowing only certain IOD groups to provide sessions. Alternatively, rules may be IODH-specific, allowing only certain IODHs to collaborate with each other, while service-specific rules may allow or deny a second IOD from forming part of an IOD set, for example, based on a specific service being provided through an ongoing session. Thus, security-critical services, such as services involving monetary transactions or login procedures, may only be accepted when handled by one or more specific IODHs, and only when the IODH is solely handling the corresponding service without involving any other IODHs, or only when coordinating with one or more specific IODHs.

[0053] Alternatively or additionally, the aforementioned policies may be based on security classifications, meaning that a certain service provided via an ongoing session may require a certain level of security from the infrastructure in order to provide the service to the UT. For example, a service involving monetary transactions may allow some capabilities and / or some IODs to participate in such a session, while not allowing other IODs to participate in the session. According to another example, the combination of IOD parts may be determined based on certain security levels that may be associated with, for example, the communication service being applied, such as how certain capabilities of different IODs are allowed to be combined within a certain IOD set or a combination of IOD sets.

[0054] The determination according to step 2:20 may result in a permission or rejection according to step 2:40, without causing the second IODH to be notified of the determination, but rather only causing the information forwarded from the other IODH to be simply processed accordingly in the case of permission, or discarded in the case of rejection. Alternatively, the aforementioned decision may result in providing an acceptance message to the second IODH according to step 2:50a if it is determined that the second IODH is allowed to participate in the ongoing session, or providing a rejection message according to step 2:50b if it is determined that the second IODH is prohibited from participating in the ongoing session.

[0055] Once the first IODH knows that the second IODH can participate in the ongoing session, according to optional step 2:60, the first IODH can establish a joint session with the second IODH and use the joint session for ongoing signaling between the two IODHs. Figure 2It is not shown, but it is known that a positive result of the mentioned determination may also lead to a session key update procedure, which includes the generation of an IOD-specific session key by the first IODH or EAP authenticator, after which the key is sent to the second IODH, wherein the IOD-specific session key is usually also provided with a pointer to a server providing related services through the ongoing session, and a session ID identifying the ongoing session.

[0056] In step 2:70, the first IODH can manage the second IOD's full participation in the ongoing session, or only partial participation in the ongoing session, for example, allowing only one or more capabilities of the second IOD to participate in the ongoing session. In addition to managing the second IOD's participation in the ongoing session, according to step 2:70, the first IODH can also manage the second IOD to replace all or part of the second IOD's capabilities with all or part of the capabilities of another IOD. According to another embodiment, for example, once it is determined that some or all of the second IOD's capabilities are no longer needed, some or all of the second IOD's capabilities can be removed from the session. Alternatively, during the ongoing session, an IOD or part of an IOD (e.g., certain capabilities of the IOD) can be replaced by a second IOD or part of the second IOD. Alternatively, the second IOD can be allowed to participate in the ongoing session only under certain conditions. Management of the second IOD according to step 2:70 can continue until the ongoing session is terminated, or until it is determined that the second IOD is no longer allowed or preferred to participate in the ongoing session, whereby the method is replaced by managing one or more IODs in a conventional manner.

[0057] In the case where the second IOD is not allowed to participate in the ongoing session, the first IODH will ignore the information provided about the second IOD according to step 2:80, and no message indicating rejection is necessarily required. However, if a message indicating rejection is provided to the second IODH, a rejection message can be sent to the second IODH as shown in step 2:50b.

[0058] In addition to what was said above about step 2:70, we will now refer to Figure 3 A more detailed description of the management of the second IOD can be found in Figure 2

[0066] The present invention provides some possible events that may be performed in step 2:70 of FIG. According to optional step 3:10, at any time during the ongoing management, the first IODH may determine that the ongoing session should be managed by the second IODH rather than the first IODH, as indicated by the "yes" branch of step 3:10, followed by another step 3:20 in which the ongoing session is transferred to the second IODH. The transfer may be permanent, such that once transferred, the ongoing session is managed by the second IODH until the session is terminated, or the transfer may be temporary, such that the session can be later transferred back to the first IODH if needed. The temporary transfer may be performed, for example, based on the current majority of IODs or capabilities used by the ongoing session, such that the transfer remains as long as the corresponding IODH is managing the majority of the used IODs or capabilities, or the transfer may be performed only during a certain portion of a day or week, or during a certain time interval.

[0059] Steps 3:10 and 3:20 are presented as unconditional steps, in which the second IODH is instructed to take over management of the ongoing session (and thus, the IOD used by the session) prior to the transfer. Alternatively, however, a request for the transfer may be provided from the first IODH to the second IODH, with the transfer only being performed if the second IODH accepts the requested transfer. If the requested transfer is not accepted, the ongoing session will continue to be managed by the first IODH.

[0060] The reason for this transfer may, for example, be a determination that the IOD managed by the first IODH is no longer participating in the ongoing session, i.e., all IODs providing the ongoing session are now managed by another IODH, in this example, the second IODH. During this management period, while the first IODH is still managing the session, new information regarding beacon signals received by the second IOD may be received from the second IODH, as shown in step 3:30. In a subsequent step 3:40, a determination is made as to whether the received information warrants a change in the IOD set, i.e., whether the second IOD is to be included in the current IOD set for the ongoing session. If so, the IOD set is changed such that the second IOD or a portion of the second IOD, i.e., one or more capabilities of the second IOD, are added to, removed from, or replace another IOD or a portion of the capabilities of another IOD, as shown in step 3:50. If not, the process is repeated, possibly by executing optional step 3:10, possibly followed by optional step 3:20, and then awaiting receipt of additional information according to step 3:30.

[0061] Now refer to Figure 4The method performed in an IODH (referred to herein as a second IODH) that has received a beacon signal related to an ongoing session from an IOD managed by an IODH different from the second IODH (referred to herein as a first IODH) is described in more detail as described above.

[0062] exist Figure 4 In the first step 4:10 of the protocol, the second IODH is receiving information regarding a beacon signal from a second IOD. As described above, the second IODH identifies the second IOD as an IOD managed by another IODH (here, the first IODH) that belongs to or provides an ongoing session. This identification can be based on IOD-specific information and session-specific information. The IOD-specific information can include an IOD identity that uniquely identifies the second IOD, and the session-specific information can include a session identity that uniquely identifies the ongoing session. The IOD-specific information can also include an indication of the signal strength of the beacon signal when received by the second IOD, and optionally also an indication of at least one capability requested by the UT and available at the second IOD, or both types of capability information can be provided. As shown in step 4:20, the second IODH typically responds to receipt of the received information by forwarding it to another IODH (here, the first IODH). Alternatively, the second IODH may determine not to forward any information to the second IODH, for example because a policy known to the second IODH prohibits such collaboration between the two IODHs.

[0063] The forwarding of information to the first IODH may be performed without the second IODH receiving any indication to stop forwarding by the first IODH (as indicated by the "No" branch of step 4:30). Alternatively, the first IODH that does not agree to the second IOD's participation in the ongoing session may provide a rejection message to the second IODH, resulting in the second IODH receiving the rejection message according to optional step 4:40b as confirmation to stop forwarding information about the second IOD to the first IODH according to optional step 4:50b, after which the proposed method is terminated. Figure 4 If the "no" branch of the preceding instruction does not apply, forwarding will continue, but the forwarded information may be considered or discarded by the first IODH without the knowledge of the second IODH. If the determination of the first IODH is confirmed, then according to optional step 4:40a, the second IODH may receive an acceptance message notifying the first IODH that the information forwarded by the second IODH will be considered by the first IODH. The acceptance message may indicate unconditional or conditional acceptance of the second IODH.

[0064] According to another optional step 4:60, the second IODH may receive a notification, such as a command, from the first IODH to transfer the ongoing session from the first IODH to the second IODH, after which the session may be managed by the second IODH according to optional step 4:70. As an alternative to the unconditional transfer described above, the second IODH may receive a transfer request from the first IODH, thereby allowing the second IODH to accept or reject the request. In the case of acceptance, the requested transfer is performed and the ongoing session is managed by the second IODH, while in the case of rejection, the first IODH and the second IODH continue to manage their respective IODs in an unchanged manner.

[0065] Before performing the transfer, the IOD-specific session key associated with the ongoing session needs to be updated at the second IOD according to the session key procedure already described herein. Thus, the second IODH may receive the IOD-specific session key from the first IODH, which is then forwarded to the second IOD. The session key may be forwarded along with one or more of: an indication of the capabilities allowed to participate in the ongoing session, thereby identifying the capabilities that may be considered for the session of the second IODH; a pointer to a server, thereby identifying the server providing the ongoing session; and a session ID identifying the ongoing session to the second IODH.

[0066] Information forwarding to the first IODH may continue until a reason arises to interrupt forwarding. This reason may be, for example, that the second IODH no longer receives a beacon signal containing IOD-specific information about the ongoing session. This may be determined, for example, based on no information being received from the start of a timer until it times out. According to another embodiment, after some content has been received and processed by the second IODH, the second IODH may receive a rejection message associated with the second IOD and the ongoing session, or may terminate forwarding based on the ongoing session being terminated.

[0067] Figure 5This is a signaling scheme according to some embodiments, illustrating how two IODHs—IODH 1 (or first IODH) and IODH 2 (or second IODH)—interact to maintain an ongoing session in the most efficient manner. As a prerequisite, the presented scenario assumes UT 101 accessing a service via an ongoing session provided by server 120. Initially, the service is provided from server 110 to UT 110 via IOD 1, which has received a beacon signal from UT 110, as shown in step 5:10, and has forwarded relevant information regarding the received beacon signal to IODH 1, which manages IOD 1, as shown in step 5:20. Although the two steps are shown as corresponding single steps, it should be understood that in a typical scenario, these steps are typically repeated at specific intervals as long as IODH 1 is able to receive a beacon signal.

[0068] In the given example, another IOD (herein referred to as IOD 2) also receives the transmitted beacon signal at a later point in time, as shown here in step 5:10′. One reason why IOD 2 is now also able to receive the beacon signal may be that UT 101 has moved, so that both IOD 1 and IOD 2 are now within range of UT 101. IOD 2 responds by forwarding IOD and session-specific information based on the information in the beacon signal to the IODH managing it (in this example, an IODH different from IODH 1, namely IODH 2), as shown in step 5:20′. It should be understood that IOD 1 may or may not have received the same beacon signal at this point. If the beacon signal is received, corresponding to the previous step 5:20, IOD 1 also forwards the information to IODH 1.

[0069] As shown in step 5:30, at IODH 2, the received information about the beacon signal is evaluated to determine how to process the information. In the given example, this determination is performed internally. At this stage, IODH 2 may determine whether to allow or disallow IODH 1 and IODH 2 to interact with each other. In the latter case, the present disclosure will not be able to be implemented, which may result in the forwarded information being ignored by the second IODH. However, in this example, it is assumed that IODH 2 determines that the information about IOD 2 is to be forwarded to the relevant IODH, which is identified at least in part based on the acquired information, possibly in combination with additional information available, for example, from a memory of IODH 2 or a memory accessible to IODH 2.

[0070] In the next step 5:40, the IOD and session-specific information are forwarded to the IODH managing the ongoing session in question, namely, IODH 1. As shown in step 5:50, IODH 1 responds to receiving information about an IOD not managed by itself by initiating a determination as to how to handle the information. According to one embodiment, initiating this determination means that IODH 1 itself makes the required decision based on the information obtained, possibly in conjunction with policies or rules available to IODH 1. According to an alternative embodiment, the request for the decision or assistance in making the decision is provided to an external entity that can provide the decision or information. In this example, step 5:50 also includes requesting a decision from server 110, as shown in optional step 5:55.

[0071] Once IODH 1 has made a decision, it can proceed by processing the forwarded information accordingly. In the event that the decision is a rejection, i.e., IOD 2 is not allowed to participate in the ongoing session currently managed by IODH 1, the forwarded information will be ignored by IODH 1. This scenario can be performed without notifying IODH 2, meaning that IODH 2 can continue to forward information that is not considered by IODH 1, or IODH 1 can provide a message to IODH 2, such as a rejection message, to make IODH 2 aware of the rejection, as shown in optional step 5:60, so that IODH 2 can stop forwarding the information to IODH 1. In a similar manner, allowing the forwarding of information, and therefore allowing the IODH to cooperate, so that IOD 2 can participate in the ongoing session, allows IODH 1 to process the forwarded information without notifying IODH 2 of the permission, or a message indicating the permission can be provided in step 5:60.

[0072] As indicated in another optional step 5:70, after IODH 1 establishes a joint session between IODH 1 and IODH 2, it may also perform a permissible decision so that the joint session can then be used for continued signaling between the IODHs related to the ongoing session. As indicated in step 5:80, IODH 1 then temporarily manages IOD 2 accordingly, such that IOD 2 can be temporarily or permanently included in the IOD set used by the ongoing session, either by adding IOD 2 or replacing another IOD with IOD 2, as desired. Furthermore, this management may later include removing IOD 2 from the IOD set, if desired. In a corresponding manner, only portions of IOD 2, typically in the form of one or more capabilities, rather than the entire IOD, may be managed. It should be understood that temporary management of IOD 1 will be dependent on the progress of the ongoing session, such that management will continue as long as the ongoing session remains active, while termination of the ongoing session will cause each IOD set to be managed again by the IODH originally assigned to the corresponding IOD set.

[0073] According to another embodiment, which can be initiated at any time, as shown in step 5:90, a desire to change the management of the IODH may arise, for example, because the IOD managed by IODH 1 is no longer actively participating in an ongoing session. This scenario (where at least one IOD or at least a portion of at least one IOD is still actively providing ongoing sessions, where at least these portions of the IODs are managed by IODH 2) may lead to a determination that a change of IODH will occur. This decision may result in an instruction to IODH 2 to take over management of the set of IODs (here represented as IOD 2), or a request or query to IODH 2 to accept the transfer and, if IODH 2 accepts the request, to execute the transfer. This notification is indicated in step 5:100, and the actual change is executed by IODH 2 in step 5:110, unless the transfer is generally rejected by IODH 2, which provides a message indicating such rejection to IODH 1.

[0074] Now refer to Figure 6 An IODH configured to execute the method disclosed in any of the above embodiments (referring to a first IODH, ie, an IODH capable of accepting forwarding information about an IOD managed by another IODH) is described in more detail. Figure 6A first IODH 130a is disclosed that is capable of managing a first set of IODs that provide ongoing sessions between a UT and a server, the first set of IODs including at least one first IOD. The IODH 130a includes a receiving unit 600 configured to receive information about a beacon signal from a second IODH that manages a second IOD, the information being received by a second IOD in the second set of IODs, wherein the received information includes IOD-specific information about the second IOD and session-specific information about the ongoing session. The first IODH 130a also includes a determining unit 610 configured to initiate a determination regarding whether to allow or disallow at least some of the IODs managed by another IODH (herein, the second IODH) to participate in the ongoing session, wherein the initiation is based at least in part on the received information. The first IODH 130a further includes a management unit 620 configured to manage the participation of at least a portion of the second IODH in the ongoing session in response to knowing that at least a portion of the second IODH is allowed to participate in the ongoing session and based at least in part on information about the beacon signal received from the second IODH. In addition, the first IODH 130a includes a sending unit 630 that enables the first IODH 130a to provide information to the second IODH and respond to the second IODH.

[0075] According to another aspect, Figure 7A first IODH 130a′ is disclosed. The first IODH 130a′ includes a processor circuit 700 and a memory 710. The memory 710 includes computer-readable instructions that, when executed by the processing circuit 700, cause the first IODH 130a′ to receive, via a communication unit 720, information about a beacon signal received by a second IOD from a second IOD that manages the second IOD in a second set of IODs, wherein the received information includes IOD-specific information about the second IOD and session-specific information about an ongoing session. The second IODH 130a′ is then configured to initiate a determination, based at least in part on the received information, as to whether to allow or prohibit at least a portion of the second IOD managed by the second IOD from participating in the ongoing session. The first IODH 130a′ is further configured to manage at least a portion of the second IOD's participation in the ongoing session in response to learning that at least a portion of the second IOD is allowed to participate in the ongoing session and based at least in part on the information about the beacon signal received from the second IOD. Memory 710 may be any combination of random access memory (RAM) and / or read-only memory (ROM). Memory 710 also includes permanent storage, which may be, for example, any one or combination of magnetic storage, optical storage, solid-state storage, or even remotely mounted storage. Processing circuitry 700 may include, for example, one or more central processing units (CPUs), multiple processors, or digital signal processors (DSPs).

[0076] According to one embodiment, the first IODH 130a′ is configured to process IOD-specific information including an identity of the second IOD and an indication of a signal strength of a beacon signal when received by the second IOD, wherein the session-specific information includes the session identity. The first IODH 130a′ may also be configured to process IOD-specific information including an indication of at least one capability requested by the UT and / or including an indication of at least one capability available at the second IOD.

[0077] According to one embodiment, the first IODH 130a' is configured to initiate the determination in response to having authenticated the beacon signal as a legitimate beacon signal.

[0078] According to one embodiment, the first IODH 130a' is configured to initiate a determination based on at least one of execution of a first policy available to the first IODH and a response to a request for determination sent to a server. Where the determination is based on execution of the first policy available to the first IODH 130a', the first policy may be based on various types of rules, including at least one of: an IOD-specific rule, an IOD domain-specific rule, an IODH-specific rule, and a service-specific rule. The first IODH 130a' may be configured to apply the first policy based on a security classification, wherein the security classification may include at least one of comparing activities performed by the ongoing session to at least one predefined security level and comparing at least a portion of the second IOD to at least one predefined security level.

[0079] As suggested above, after the determination is made, a message indicating the determination can be sent from the first IODH to the second IODH. To implement this scenario, according to one embodiment, the first IODH 130a' is configured to send an accept message to the second IODH, wherein, when the first IODH determines that at least a portion of the second IOD is allowed to participate in the ongoing session, the message indicates that at least a portion of the second IOD is allowed to participate in the ongoing session, or the first IODH 130a' is configured to send a reject message to the second IODH, wherein, when the first IODH determines that at least a portion of the second IOD is not allowed to participate in the ongoing session, the message indicates that at least a portion of the second IOD is prohibited from participating in the ongoing session.

[0080] According to one embodiment, the first IODH 130a′ may be configured to, in response to knowing that at least a portion of the second IODH is allowed to participate in the ongoing session, establish a joint session associated with the ongoing session between the first IODH and the second IODH, such that the joint session may be used for signaling associated with the ongoing session between the two IODHs.

[0081] For security reasons, the first IODH 130a' can also be configured to ensure that an updated IOD-specific session key is provided to the second IOD. More specifically, the first IODH 130a' can be configured to respond to its knowledge that at least a portion of the second IOD is permitted to participate in the ongoing session by generating an IOD-specific session key associated with the second IOD and the ongoing session, or by requesting the key from the EPA authenticator or from an internal authentication function (if implemented on the first IODH 130a'), and sending the IOD-specific session key to the second IODH. According to one embodiment, the IOD-specific session key can be accompanied by at least one of a pointer to the server providing the ongoing session and a session-ID that allows the second IODH 130a' to identify the ongoing session. Furthermore, the IOD-specific session key can also be sent along with an indication of the ability to participate in the ongoing session.

[0082] The first IODH 130a' may be configured to manage at least a portion of the second IOD by performing at least one of: adding at least a portion of the second IOD to an ongoing session, replacing at least a portion of an IOD managed by the first IODDH with at least a portion of the second IOD, and deleting at least a portion of the second IOD from the ongoing session.

[0083] In some cases, it may be preferable to transfer an ongoing session from a first IODH to a second IODH. To address this situation, upon determining that at least a portion of the IOD used by the ongoing session is preferably managed by the second IODH instead, the first IODH 130a' can be configured to transfer the ongoing session from the first IODH 130a' to the second IODH. This transfer can be permanent, where the transfer persists until the ongoing session is terminated, or temporary, where the transfer occurs only for a limited time, the remainder of the session. Depending on the configuration, the first IODH 130a can indicate to the second IODH that the transfer is to be performed, or request that the second IODH accept the transfer, after which the actual transfer can be performed if the second IODH accepts the request.

[0084] As described above, transfer of an ongoing session may be preferred based on various reasons. More specifically, according to one embodiment, the first IODH 130a' may be configured to support transfer based on at least one of: a user preference of a user of the UT, a determination that an IOD managed by the first IODH is no longer involved in an active session, a majority decision made by at least the first IODH and the second IODH regarding the number of active IODs and / or capabilities involved in the session, and a decision made and provided by a server providing the ongoing session.

[0085] According to one aspect, the computer readable instructions described above may be configured as a computer program 730 and the computer program 730 may form part of a computer program product 740, which may be, for example, an optical disc such as a compact disc (CD), digital versatile disc (DVD) or Blu-ray disc.

[0086] According to another aspect, reference will now be made to Figure 8 Describing another IODH (herein referred to as a second IODH 130b) in greater detail, the second IODH 130b is capable of providing IOD-related information about the IOD it is currently managing to other IODHs, as described herein. The second IODH 130b includes a receiving unit 800 and a forwarding unit 810. The receiving unit 800 is configured to receive information about a beacon signal from the second IOD, wherein the information includes IOD-specific information about the second IOD and session-specific information about a session, wherein the session is conducted via at least a portion of a first IOD managed by the other IODH (herein referred to as the first IODH). The forwarding unit 810 is configured to forward at least a portion of the information about the beacon signal and the identity of the second IOD 130b to the first IODH.

[0087] Memory 910 may be any combination of random access memory (RAM) and / or read-only memory (ROM). Memory 910 also includes persistent storage, which may be, for example, any one or combination of magnetic storage, optical storage, solid-state storage, or even remotely mounted storage. Processing circuitry 900 may include, for example, one or more central processing units (CPUs), multiple processors, or digital signal processors (DSPs).

[0088] According to another aspect, Figure 9 A second IODH 130b' is shown. The second IODH 130b' includes processing circuitry 900 and memory 910, the memory 910 including computer-readable instructions that, when executed by the processing circuitry 900, cause the second IODH 130b' to receive information regarding a beacon signal from a second IOD via a communication unit 920, wherein the received information includes IOD-specific information regarding the second IOD and session-specific information regarding a session ongoing via at least a portion of the first IOD managed by the first IOD, and cause the second IODH 130b' to forward at least a portion of the information regarding the beacon signal and the identity of the second IOD 130b' to the first IOD.

[0089] When applying a message indicating how the first IODH will react to the forwarded information about the second IOD, the second IODH 130b′ can be configured to receive a rejection message indicating that no portion of the IOD managed by the second IODH is allowed to participate in the ongoing session, or receive an acceptance message indicating that at least a portion of the IOD managed by the second IODH is allowed to participate in the ongoing session.

[0090] The received IOD-specific information may include an identity of the second IOD and an indication of the signal strength of the beacon signal when it is received by the second IOD, wherein the session-specific information includes the session identity and may further include an indication of at least one capability requested by the UT and / or an indication of at least one capability available at the UT.

[0091] According to one embodiment, the second IODH 130b' is configured to, in response to the second IODH and the first IODH having approved their collaboration, apply a joint session associated with the ongoing session and established by the first IODH for communication between the first IODH and the second IODH. In the latter case, when the joint session is used to forward information, the second IODH 130b' can be configured to act as a proxy between the first IODH and the second IODH 130b'.

[0092] For security reasons, communication between the two IODs mentioned above may require providing an IOD-specific session key to the second IOD. In this scenario, the second IODH 130b' is configured to receive an IOD-specific session key associated with the second IOD and the ongoing session from the first IODH and forward the IOD-specific session key to the second IOD. The IOD-specific session key may be received along with at least one of: an indication of the ability to participate in the ongoing session, a pointer to a server providing the ongoing session, and a session-ID. Additionally, the key may be received along with the indication of the ability to participate in the ongoing session.

[0093] According to one embodiment, the second IODH 130b′ is configured to receive an acceptance message from the first IODH indicating that at least a portion of the second IOD is allowed to participate in the ongoing session, or a rejection message indicating that at least a portion of the second IOD is prohibited from participating in the ongoing session. In the case of an acceptance message, the second IODH 130b′ may be configured to recognize the acceptance message as a conditional acceptance that the IOD managed by the second IODH is allowed to participate in the ongoing session only under certain conditions.

[0094] According to one embodiment, the second IODH 130b' is configured to continue forwarding beacon signal information received by the second IOD and associated with the ongoing session until any of the following occurs at the second IODH: the second IODH no longer receives beacon signals including IOD-specific information about the ongoing session, the second IODH is receiving a rejection message associated with the second IOD and the ongoing session, or the ongoing session is terminated.

[0095] According to one embodiment, the second IODH 130b′ is configured to receive an instruction or request indicating that management of at least part of the IOD used by the ongoing session is instructed or requested to be transferred to the second IODH.

[0096] According to one aspect, the computer readable instructions described above may be configured as a computer program 930 and the computer program 930 may form part of a computer program product 940, which may be, for example, an optical disc such as a compact disc (CD), digital versatile disc (DVD), or Blu-ray disc.

[0097] Although the IODH is described above as a first IODH and a second IODH, wherein the two IODHs play different roles in the described process, it should be understood that the IODH can be configured to play any of the above roles. For example, the IODH can be executed on the first IODH or the second IODH separately, or more typically, the IODH can play either role once the corresponding role is needed.

[0098] The various aspects of the present disclosure have been primarily described above with reference to several embodiments. However, as will be readily appreciated by those skilled in the art, other embodiments in addition to the embodiments disclosed above are also within the scope of the present disclosure as defined by the appended patent claims. Therefore, although various aspects and embodiments have been disclosed herein, other aspects and embodiments will also be readily apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for illustrative purposes only and are not intended to be limiting, and the actual scope and spirit are defined by the appended claims.

Claims

1. A method for a first IOD Dh managing a first set of IODs including at least one first IOD, wherein the first set of IODs provides an ongoing session between a user tag UT and a server, the method comprising: - receiving (2:10) from a second IODH that manages a second IOD in a second set of IODs information about a beacon signal received by the second IOD, wherein the information includes IOD-specific information about the second IOD and session-specific information about the ongoing session; - based at least in part on the received information, initiating (2:20) a determination as to whether to allow or disallow at least some of the IODs managed by the second IODH to participate in the ongoing session; as well as - In response to having learned that at least part of the second IOD is allowed to participate in the ongoing session, and based at least in part on information about the beacon signal received from the second IODH, managing (2:70) participation of at least part of the second IOD in the ongoing session.

2. The method according to claim 1, wherein The IOD-specific information includes an identity of the second IOD and an indication of a signal strength of the beacon signal when received by the second IOD, and wherein the session-specific information includes a session identity.

3. The method according to claim 2, wherein: The IOD-specific information also includes an indication of at least one capability requested by the UT.

4. The method according to claim 2 or 3, wherein: The IOD-specific information also includes an indication of at least one capability available at the second IOD.

5. A method according to any one of the preceding claims, wherein The determining is initiated in response to the beacon signal having been authenticated as a legitimate beacon signal.

6. The method according to any one of claims 1 to 5, wherein The determination (2:20) is based on at least one of the following: - execution of a first strategy available to said first IODH, and - a response to the determined request sent to the server.

7. The method according to claim 6, wherein: The determination (2:20) is based on execution of a first strategy available to the first IODH, wherein the first strategy is based on at least one of: - IOD specific rules, - IOD domain specific rules, - IODH-specific rules, and - Service-Specific Rules.

8. The method according to claim 7, wherein: The first strategy is based on a security classification, wherein the security classification includes at least one of the following: - comparing the behavior performed by said ongoing session with at least one predefined security level, and - comparing at least part of the second IOD with at least one predefined security level.

9. The method according to any one of claims 1 to 8, further comprising: - if the first IODH determines that such operation is allowed, sending an accept message to the second IODH, the accept message indicating that at least part of the second IOD is allowed to participate in the ongoing session, or - In case the first IODH determines that such operation is not allowed, sending a rejection message to the second IODH, the rejection message indicating that at least part of the second IOD is prohibited from participating in the ongoing session.

10. The method according to any one of the preceding claims, further comprising: In response to having learned that at least a portion of the second IOD is allowed to participate in the ongoing session, a joint session associated with the ongoing session is established (2:60) between the first IODH and the second IODH.

11. The method according to any one of the preceding claims, further comprising the steps of: In response to having learned that at least a portion of the second IOD is allowed to participate in the ongoing session: - generating an IOD-specific session key associated with the second IOD and the ongoing session, and - Sending the IOD-specific session key to the second IODH.

12. The method according to claim 11, wherein The IOD-specific session key is sent along with at least one of: - a pointer to the server providing the ongoing session, and - Session-ID.

13. The method according to claim 12, wherein: The IOD-specific session key is also sent along with an indication of the capabilities that are allowed to participate in the ongoing session.

14. A method according to any one of the preceding claims, wherein At least a portion of the second IOD is managed by the first IODH (2:70), wherein the management includes at least one of the following: - adding at least part of the second IOD to the ongoing session, - replacing at least part of the IOD managed by the first IODH with at least part of the second IOD, and - deleting at least part of the second IOD from the ongoing session.

15. The method according to any one of the preceding claims, further comprising: - upon determining that it is preferred that at least part of the IOD used by the ongoing session be managed by the second IODH, transferring (3:20) the ongoing session from the first IODH to the second IODH.

16. The method according to claim 15, wherein The transfer is performed only if the transfer request sent to the second IODH results in the second IODH accepting the request (3:20).

17. The method according to claim 15 or 16, wherein Said transfer (2:20) was performed as a temporary transfer.

18. The method according to any one of claims 14 to 17, wherein At least part of the IOD used by the ongoing session is preferably managed by the second IODH based on at least one of the following: - User preferences of the user of the UT, - a determination that the IOD managed by the first IODH is no longer participating in an active session, - a majority decision by at least the first IODH and the second IODH regarding the number of active IODs and / or capabilities involved in the session, and - A decision made and provided by the server providing the ongoing session.

19. A method for a second IODH to process information about a second IOD managed by the second IODH, the method comprising: - receiving (3:10) information about a beacon signal from the second IOD, wherein the information includes IOD-specific information about the second IOD and session-specific information about a session ongoing via at least a portion of the first IOD managed by the first IODH, and - forwarding (3:20) to the first IODH at least part of the information about the beacon signal and the identity of the second IODH.

20. The method according to claim 19, further comprising: - receiving (3:60b) a reject message from the first IODH, the reject message indicating that any part of the IOD managed by the second IODH is not allowed to participate in the ongoing session, or - receiving (3:60a) an accept message from the first IODH, the accept message indicating that at least part of the IODs managed by the second IODDH are allowed to participate in the ongoing session.

21. The method according to claim 19 or 20, wherein The IOD-specific information includes an identity of the second IOD and an indication of a signal strength of the beacon signal when received by the second IOD, and wherein the session-specific information includes a session identity.

22. The method according to claim 21, wherein The IOD-specific information also includes an indication of at least one capability requested by the UT.

23. The method according to claim 21 or 22, wherein: The IOD-specific information also includes an indication of at least one capability available at the UT.

24. The method according to any one of claims 19 to 23, further comprising: In response to the second IODH having approved collaboration with the first IODH, a joint session associated with the ongoing session is established between the first IODH and the second IODH.

25. The method according to claim 24, wherein The second IODH acts as a proxy between the first IODH and the second IODH when forwarding information using the joint session.

26. The method according to any one of claims 19 to 25, further comprising: - receiving from the first IODH an IOD-specific session key associated with the second IOD and the ongoing session, and - Forwarding the IOD-specific session key to the second IOD.

27. The method according to claim 26, wherein The IOD-specific session key is forwarded along with at least one of the following: - an indication of the capabilities that are allowed to participate in the ongoing session, - a pointer to the server providing the ongoing session, and - Session-ID.

28. The method according to claim 27, wherein The IOD-specific session key is also sent along with an indication of the capabilities that are allowed to participate in the ongoing session.

29. The method according to any one of claims 19 to 28, further comprising: - Receiving from the first IODH an accept message (4:40a) indicating that at least part of the second IOD is allowed to participate in the ongoing session, or a reject message (4:40b) indicating that at least part of the second IOD is prohibited from participating in the ongoing session.

30. The method according to claim 29, wherein The received (4:40a) accept message indicates a conditional acceptance that the IOD managed by the second IODH is allowed to participate in the ongoing session only under certain conditions.

31. The method according to any one of claims 19 to 30, wherein Continue forwarding beacon signal information received by the second IOD and associated with the ongoing session until any of the following occurs at the second IODH: - the second IODH no longer receives beacon signals including IOD-specific information about the ongoing session, and - the second IODH is receiving a reject message associated with the second IOD and the ongoing session, or - The ongoing session is terminated.

32. The method according to any one of claims 19 to 31, further comprising: Receive at least one of the following: - an instruction to transfer at least part of the management of the IOD used by the ongoing session to the second IODH, or - requesting the second IODH to accept a request to transfer at least part of the management of the IOD used by the ongoing session to the second IODH.

33. The method according to claim 32, wherein The request is received, and wherein the transfer of management of the ongoing session is performed only if the request is accepted by the second IODH.

34. A first IODH (130a') comprising a processor circuit (700) and a memory (710), the memory (710) comprising computer-readable instructions that, when executed by the processing circuit (700), cause the first IODH (130a') to perform the following operations: - receiving, from a second IODH that manages a second IOD in a second set of IODs, information about a beacon signal received by the second IOD, wherein the information includes IOD-specific information about the second IOD and session-specific information about an ongoing session; - based at least in part on the received information, initiating a determination as to whether to allow or disallow at least some of the IODs managed by the second IODH to participate in the ongoing session; as well as - In response to having learned that at least a portion of the second IOD is allowed to participate in the ongoing session, and based at least in part on information about the beacon signal received from the second IODH, managing the participation of at least a portion of the second IOD in the ongoing session.

35. The first IODH (130a') of claim 34, configured to process IOD specific information comprising an identity of the second IOD and an indication of a signal strength of the beacon signal when received by the second IOD, and process session specific information comprising a session identity.

36. The first IODH (130a') according to claim 35, further configured to process IOD specific information, said IOD specific information further comprising an indication of at least one capability requested by said UT.

37. The first IODH (130a') according to claim 35 or 36, further configured to process IOD specific information, said IOD specific information further comprising an indication of at least one capability available at said second IOD.

38. The first IODH (130a') according to any one of claims 35 to 37, configured to initiate the determination in response to having authenticated the beacon signal as a legitimate beacon signal.

39. The first IODH (130a') according to any one of claims 35 to 38, configured to initiate the determination based on at least one of the following: - execution of a first strategy available to said first IODH, and - a response to the determined request sent to the server.

40. The first IODH (130a') of claim 39, configured to initiate said determination based on execution of a first policy available to said first IODH, wherein The first strategy is based on at least one of the following: - IOD specific rules, - IOD domain specific rules, - IODH-specific rules, and - Service-Specific Rules.

41. The first IODH (130a') according to claim 40, configured to apply a first policy based on security classification, wherein Consider security categories that include at least one of the following: - comparing the behavior performed by said ongoing session with at least one predefined security level, and - comparing at least part of the second IOD with at least one predefined security level.

42. The first IODH (130a') according to any one of claims 35 to 41, further configured to: - if the first IODH determines that such operation is allowed, sending an accept message to the second IODH, the accept message indicating that at least part of the second IOD is allowed to participate in the ongoing session, or - In case the first IODH determines that such operation is not allowed, sending a rejection message to the second IODH, the rejection message indicating that at least part of the second IOD is prohibited from participating in the ongoing session.

43. The first IODH (130a') according to any one of claims 35 to 42, further configured to: In response to having learned that at least a portion of the second IOD is allowed to participate in the ongoing session, establishing a joint session associated with the ongoing session between the first IODH and the second IODH.

44. The first IODH (130a') according to any one of claims 35 to 43, further configured to: In response to having learned that at least a portion of the second IOD is allowed to participate in the ongoing session: - generating an IOD-specific session key associated with the second IOD and the ongoing session, and - Sending the IOD-specific session key to the second IODH.

45. The first IODH (130a') according to claim 44, further configured to send the IOD specific session key together with at least one of: - a pointer to the server providing the ongoing session, and - Session-ID.

46. ​​The first IODH (130a') of claim 45, further configured to send the IOD specific session key together with an indication of a capability to be allowed to participate in the ongoing session.

47. The first IODH (130a') according to any one of claims 35 to 46, further configured to manage at least part of the second IOD, wherein The management includes at least one of the following: - adding at least part of the second IOD to the ongoing session, - replacing at least part of the IOD managed by the first IODH with at least part of the second IOD, and - deleting at least part of the second IOD from the ongoing session.

48. The first IODH (130a') according to any one of claims 35 to 47, further configured to: - upon determining that it is preferred that at least part of the IOD used by the ongoing session be managed by the second IODH, transferring the ongoing session from the first IODH to the second IODH.

49. The first IODH (130a') of claim 48, further configured to transfer the ongoing session only if a transfer request sent to the second IODH results in the second IODH accepting the request.

50. The first IODH (130a') according to claim 48 or 49, further configured to perform the transfer as a temporary transfer.

51. The first IODH (130a') according to any one of claims 35 to 50, further configured to prefer at least part of the IOD used by the second IODH to manage the ongoing session based on at least one of the following: - User preferences of the user of the UT, - a determination that the IOD managed by the first IODH is no longer participating in an active session, - a majority decision by at least the first IODH and the second IODH regarding the number of active IODs and / or capabilities involved in the session, and - A decision made and provided by the server providing the ongoing session.

52. A second IODH (130b´) comprising a processor circuit (900) and a memory (910), the memory (910) comprising computer-readable instructions that, when executed by the processing circuit (900), cause the second IODH (130b´) to perform the following operations: - receiving information about a beacon signal from the second IOD, wherein, The information includes IOD-specific information about the second IOD and session-specific information about a session ongoing via at least a portion of the first IOD managed by the first IODH, and - forwarding at least part of said information about said beacon signal and the identity of said second IODH to said first IODH.

53. The second IODH (130b´) according to claim 52, being configured to: - receiving a rejection message from the first IODH, the rejection message indicating that any part of the IOD managed by the second IODH is not allowed to participate in the ongoing session, or - receiving an accept message from the first IODH, the accept message indicating that at least part of the IODs managed by the second IODDH are allowed to participate in the ongoing session.

54. The second IODH (130b') according to claim 52 or 53, further configured to: identify, in the IOD specific information, an identity of the second IOD and an indication of a signal strength of the beacon signal when received by the second IOD, and to identify session specific information including a session identity.

55. The second IODH (130b') of claim 54, further configured to: identify IOD-specific information comprising an indication of at least one capability requested by the UT.

56. The second IODH (130b') according to claim 54 or 55, further configured to identify IOD specific information further comprising an indication of at least one capability available at the UT.

57. The second IODH (130b´) according to any one of claims 52 to 56, further configured to: Using a federated session associated with the ongoing session, the federated session is established between the first IODH and the second IODH in response to the second IODH having approved collaboration with the first IODH.

58. The second IODH (130b') of claim 57, further configured to act as a proxy between the first IODH and the second IODH when forwarding information using the joint session.

59. The second IODH (130b´) according to any one of claims 52 to 58, further configured to: - receiving from the first IODH an IOD-specific session key associated with the second IOD and the ongoing session, and - Forwarding the IOD-specific session key to the second IOD.

60. The second IODH (130b´) according to claim 59, further configured to forward the IOD specific session key together with at least one of: - an indication of the capabilities that are allowed to participate in the ongoing session, - a pointer to the server providing the ongoing session, and - Session-ID.

61. The second IODH (130b') according to claim 60, further configured to send the IOD specific session key together with an indication of a capability to be allowed to participate in the ongoing session.

62. The second IODH (130b´) according to any one of claims 52 to 61, further configured to: - receiving from the first IODH an acceptance message indicating that at least part of the second IOD is allowed to participate in the ongoing session, or a rejection message indicating that at least part of the second IOD is prohibited from participating in the ongoing session.

63. The second IODH (130b') of claim 62, further configured to interpret the received accept message as indicating a conditional acceptance, the conditional acceptance accepting that the IOD managed by the second IODH is allowed to participate in the ongoing session only under certain conditions.

64. The second IODH (130b') according to any one of claims 52 to 63, further configured to forward the received beacon signal information associated with the ongoing session until any one of the following occurs at the second IODH: - the second IODH no longer receives beacon signals including IOD-specific information about the ongoing session, and - the second IODH is receiving a reject message associated with the second IOD and the ongoing session, or - The ongoing session is terminated.

65. The second IODH (130b') according to any one of claims 52 to 64, further configured to receive at least one of the following: - an instruction to transfer at least part of the management of the IOD used by the ongoing session to the second IODH, or - requesting the second IODH to accept a request to transfer at least part of the management of the IOD used by the ongoing session to the second IODH.

66. The second IODH (130b') of claim 65, configured to receive the request, and further configured to participate in the transfer only if the request is accepted by the second IODH.

Images