Providing user-subscriber profile for I / O user devices performing user terminal emulation as a cloud computing service

Abstract

A method is performed by at least one network node for providing a communication service through input and / or output (I / O) user devices The method includes determining that an I / O user device is communicating with a user tag transported by a user, and associating the I / O user device to a communication service provided through a user terminal emulation application. The method provides to the I / O user device a user-subscription profile that is associated with a subscription in use by the user. The method then provides at least part of the communication service through network connectivity controlled based on the user- subscription profile, to the user through an I / O user interface capability of the I / O user device.

Description

PROVIDING USER-SUBSCRIBER PROFILE FOR I / O USER DEVICES PERFORMING USER TERMINAL EMULATION AS A CLOUD COMPUTING SERVICETECHNICAL FIELD

[0001] The present disclosure relates to providing communication services through user terminals of a wireless communications system.BACKGROUND

[0002] The market for user terminals is driven by the quest to provide users with increasingly advanced communication and other operational features within the constraints of a portable handheld form factor. The development requirements for user terminal are increasingly complex as designers seek to integrate a greater variety of user interfaces and advanced operational features within the portable handheld form factor. Advancements in operational features have required more highly integrated and faster processing circuits with greater circuit densities, which becomes more difficult under constraints on costs and power consumption.

[0003] This all-inclusive feature-rich approach for user terminal development does not satisfy all of the myriad of differing desires held by consumers seeking solutions for the rapidly expanding variety of communication services. Moreover, the always-connected expectations of today's society obligates users to vigilantly keep their user terminals within reach or risk being unable to timely receive or initiate communication services.SUMMARY

[0004] Some embodiments disclosed herein are directed to a method performed by at least one network node for providing a communication service through input and / or output (I / O) user devices. The method includes determining that an I / O user device is communicating with a user tag transported by a user, and associating the EO user device to a communication service provided through a user terminal emulation application. The method provides to the I / O user device a user-subscription profile that is associated with a subscription in use by the user. The method then provides at least part of the communication service through network connectivity controlled based on the user-subscription profile, to the user through an EO user interface capability of the EO user device.

[0005] Some other related embodiments disclosed herein are directed to a system including at least one network node for providing a communication service through I / O user devices. The at least one network node is configured to determine that an I / O user device is communicating with a user tag transported by a user, and associate the I / O user device to a communication service provided through a user terminal emulation application. The at least one network node is further configured to provide to the I / O user device a user-subscription profile that is associated with a subscription in use by the user. The at least one network node is further configured to provide at least part of the communication service through network connectivity controlled based on the user-subscription profile, to the user through an I / O user interface capability of the I / O user device.

[0006] Some potential advantages of these and related embodiments include that a user can receive and initiate communication services without the necessity of a traditional all- inclusive feature-rich user terminal. The user terminal emulation application can emulate a user terminal using one or more networked I / O user devices that are proximately located to the user tag transported by the user, and which individually or combinable have I / O user interface (UI) capabilities for the user to interface with to obtain a communication service. The embodiments provide a solution for temporarily associating and allocating the I / O user device to a user subscription, and to provide (e g., provision) a user-subscription profile (e.g., a Subscriber Identity Module (SIM) profile for use with embedded SIM (eSIM), integrated SIM (iSIM), or integrated eSIM) to the I / O user device which is associated with an authenticated user tag. The embodiments enable a user terminal emulation domain owner to provide the infrastructure for use by the users, but also have the operational ability to track and monetize the user's data / network usage. The embodiments also enable I / O user devices to be temporarily allocated to utilize premium services enabled for the users’ 3rdGeneration Partnership Project (3GPP) based subscription or other network operator subscription.

[0007] Other methods and systems according to embodiments of the inventive subject matter will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional methods and systems be included within this description, be within the scope of the present inventive subject matter, and be protected by the accompanying claims. Moreover, it is intended that all embodiments disclosed herein can be implemented individually or combined in any way and / or combinationBRIEF DESCRIPTION OF THE DRAWINGS

[0008] Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying drawings. In the drawings:

[0009] Figure 1 illustrates a system with a user terminal emulation application that operationally integrates sets of I / O user devices that are proximately located to users to logically form virtualized user terminals providing communication services in accordance with some embodiments of the present disclosure;

[0010] Figure 2 illustrates a block diagram illustrating the user terminal emulation application communicating with various elements of a cellular system to provide communication services in accordance with some embodiments of the present disclosure;

[0011] Figure 3 illustrates a block diagram illustrating the user terminal emulation application communicating in a different manner with various elements of a cellular system to provide communication services in accordance with some other embodiments of the present disclosure;

[0012] Figures 4 and 5 illustrate combined flowcharts of operations and related data flows between a UserTag, I / O user devices, an Extensible Authentication Protocol (EAP) authenticator, and a user terminal emulation application which may include an EAP server in accordance with some embodiments of the present disclosure;

[0013] Figures 6 and 7 illustrate combined flowcharts of operations and related data flows in a system including a user tag, I / O user devices, an EAP authenticator, a user terminal emulation application, a mobile network operator portal, and an eSIM provisioning server in accordance with some embodiments of the present disclosure;

[0014] Figure 8 illustrates a flowchart of operations by at least one network node, e.g., one or more elements of the system of Figures 5-7, in accordance with some embodiments of the present disclosure;

[0015] Figure 9 illustrates a block diagram of hardware circuit components of an I / O user device configured to operate in accordance with some embodiments;

[0016] Figure 10 illustrates a block diagram of hardware circuit components of a user terminal emulation server configured to operate in accordance with some embodiments of the present disclosure; and

[0017] Figure 11 illustrates a block diagram of hardware circuit components of an EAP authenticator configured to operate in accordance with some embodiments of the present disclosure.DETAILED DESCRIPTION

[0018] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of various present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present or used in another embodiment.

[0019] Various embodiments disclosed herein are directed to improvements in system operation for emulating a user terminal using one or more networked input and / or output (I / O) user devices that are proximately located to a user, and which individually or combinable have user interface (UI) capabilities to provide an I / O user interface for the user to obtain a communication service.

[0020] Some potential advantages of these embodiments include that a user can obtain a communication service without the necessity of a traditional all-inclusive feature-rich user terminal, e g., a conventional smartphone, mobile phone, tablet computer, etc. A user terminal emulation application can utilize the available UI capability of one or more I / O user devices that are proximate to a user to provide user terminal functionality for a communication service of a network operator or other service provider.

[0021] Dynamic allocation of I / O user device capabilities whenever and wherever the I / O user devices are in the proximity of a user enables efficient and flexible use of existing hardware, such as televisions, conference phones, laptops, surveillance cameras, connected household appliances, connected cars, etc , that is capable of providing necessary UI functionality to a user during a communication service. The user thereby has reduced or no need to carry an expensive and all-inclusive user terminal that includes all necessary UI capabilities, e g , display device, keyboard, speakers, microphone, etc The user may instead carry a hardware device which operates to identify the user, referred to as a "UserTag" or "user tag", over a wireless or wired (e.g., smartcard reader) communication interface, such as a near field communication (NFC) interface, to one or more of the I / O user devices. Various embodiments disclosed herein may disrupt the traditional handset-centric mobile communication industry as the features and capabilities of what forms a user terminal are not constrained to the domain of mobile phone manufacturers.

[0022] Figure 1 illustrates a system with a user terminal emulation server 100 that can use one or more I / O user devices 130 that is / are proximately located to users to logically emulate a user terminal providing a communication service in accordance with some embodiments of the present disclosure. The user terminal emulation server 100 may operationally integrate the UI capabilities of a set of the I / O user devices 130 to logically emulate a user terminal providing communication services in accordance with some embodiments of the present disclosure.

[0023] Referring to Figure 1, the user terminal emulation application 110 (e.g., executing on one or more servers 100) may be a cloud resource that is networked and remote from the I / O user devices 130, or may be more proximately located on a shared network (e g., network edge computing) with the I / O user devices 130. The user terminal emulation application 110 is configured to communicate with the I / O user device(s) 130 which are determined to be proximately located to a user for use in providing UI capabilities during a communication service.

[0024] Users may carry a hardware tag 101, a.k.a. "UserTag" or "user tag", which is capable of transmitting a unique user identifier through a communications interface, such as a near-field communications interface (e.g., Bluetooth, BLE, NFC, RFID, etc., or combinations thereof), for receipt by one or more of the VO user devices 130 which are proximately located to the user. One type of UserTag can be a low-complexity stand-alone electronic device having limited capability for transmitting an identifier through a near-field communications interface and performing authentication operations such as described herein. Another type of UserTag can be a smartphone, smartwatch, or other electronic device having communication connectivity and which may be configured to perform authentication operations such as described herein.

[0025] The UserTag may transmit a user identifier or the user identifier may alternatively or additionally be operationally determined by biometrics operations performed by, e.g., one or more of the I / O user devices 130. The biometrics operations may include, without limitation, voice recognition, image / face recognition, eye recognition, fingerprint recognition, or a combination thereof. The user identity may be determined based on a credential provided by the user when, e.g., logging into an application or account. The user identity may be provided by a cell phone using information from the subscription SIM and proximity of the cell phone to one or more of the VO user devices 130 can be determined using the phone’s near-field communications (NFC) capability.

[0026] A user identifier, a UserTag identifier, and a user terminal emulation application 110 can be logically associated with each other in a database 120 during a user registration process or as part of another setup process. For example, during a user registration process a user may obtain an account login identifier (serving as the user identifier) that is registered in the database 120 as being associated with a UserTag identifier for a physical UserTag that has been provided to (e.g., purchased by) the user and being associated with a user terminal application 110 that emulates a user terminal having defined capabilities (e.g., a cell phone providing cellular and over-the-type voice-over-IP communication services).

[0027] The user terminal emulation server 100 may maintain in the database 120 network addresses of I / O user devices 130 and UI capabilities of the I / O user devices 130. The capabilities of the I / O user devices 130 may be logically arranged in the database 120 based on the type of UI capability provided, e.g., display device, microphone, speaker, keyboard, and may be further arranged based on a quality of service provided by the UI capability.

[0028] A network address of one or more of the user terminal emulation applications 110 and an identity of a user can be registered with a network entity 150 providing communication services. The network entity 150 provides a communication service function 140 which may, for example, correspond to an over-the-top Voice Over Internet Protocol (VoIP) service, Netflix service, Facebook service, Microsoft Teams meeting service, Internet browser service, a cellular communication service, etc. The user terminal emulation application 110 is executed by one or more user terminal emulation server(s) 100. The user terminal emulation application 110 may function to provide one or more application functionality(ies) that are normally provided by a smart phone, such as a Netflix application, Facebook application, Microsoft Teams application, Internet browser application, etc.

[0029] As illustrated in Figure 1, a different instantiation of the user terminal emulation application 110 may be hosted by the server 100 for each user who can be provided communication services (i.e., illustrated user terminal emulation applications #1-#N corresponding to users 1-N), or a single user terminal emulation application 110 may be configured to emulate user terminals for a plurality of users who can be provided communication services. The user terminal emulation application 110 may perform registration of the user with the network entity 150 and operate in conjunction with an I / O device handler (IODH), discussed later, to setup and provide a communication service of the network entity 150 to a user.

[0030] When the communication service function 140 of the network entity 150 is a VoIP service, the operation to register the network address of the user terminal emulationapplication 110 and the identity of the user with the network entity 150 can include registering the network address of the user terminal emulation application 110 and the identity of the user with a network server of a VoIP communication service provider.

[0031] When the communication service function 140 of the network entity 150 is a cellular communication service, the operation to register the network address of the user terminal emulation application 110 and the identity of the user with the network entity 150 can include registering the network address of the user terminal emulation application 110 and the identity of the user with a Home Subscriber Server (HSS) or other network node of a core network operated by a cellular communication service provider.

[0032] The user terminal emulation application 110 may receive registration messages from the I / O user devices 130 using the Session Initiation Protocol (SlP)ZSession Description Protocol (SDP), where each of the registration messages identifies the network address and the UI capability of one of the I / O user devices 130. Communications requests may be received from the network entity 150 using SIP / SDP, and operations to provide communication sessions between the user terminal emulation application 110 and one or more I / O user devices, which are to provide I / O UI capabilities for a communication service, may be performed using SIP / SDP.

[0033] A registration message from an I / O user device may include, for example, an IP address and port number, MAC address, fully qualified domain name (FQDN), and / or another network address, and further include information identifying the UI capability of the I / O user device. The I / O user device may respond to becoming powered-on by communicating the registration message to the user terminal emulation application 110.

[0034] The user terminal emulation application 110 receives a communication request from the network entity 150 for establishing a communication service between the user and a requesting user terminal, e.g., a cellular phone, computer with Microsoft Teams application, etc. Responsive to the communication request, the user terminal emulation application 110 identifies one or more of the I / O user devices 130, which may be registered in the database, that are proximately located to a location of the user and are determined, based on the UI capabilities identified by the database 120 for the set of I / O user devices and based on content of the communication request, to satisfy a capability rule for being individually usable or combinable to provide an I / O user interface for the user to interface with the user terminal emulation application 110 to provide the communication service. Although various operations are described above and elsewhere as being performed by the user terminal emulation server 100, it is to be understood that these and other operations are performed bythe user terminal emulation server 100 executing one or more of the user terminal emulation applications 110 instantiated for a user. A single server 100 may execute the applications 110 or one or more of the applications 110 may be executed in-part across more than one server 100. Moreover, some of these operations may be performed by an I / O device handler (I0DH) which may be part of the terminal emulation application 110 or separate therefrom.

[0035] The user terminal emulation server 100 provides one or more communication sessions between the user terminal emulation application 110 and the one or more I / O user devices 130 and between the user terminal emulation application 110 and the requesting user terminal via the network entity 150. The communication request that is received by the user terminal emulation application 110 may contain an indication of a minimum UI capability that must be provided to the user during the communication service, such as: speaker only; combination of speaker and microphone; display only; combination of display device, speaker, and microphone; etc. A UI capability rule which can be used by the server 100 to determine whether a communication service can be provided and by which set of I / O user devices, may thereby be defined based on the minimum UI capability that is indicated by the communication request.

[0036] The user terminal emulation server 100 then routes communication traffic between at least one of the I / O user devices in the set and the requesting user terminal via the network entity 150. In some embodiments, for example, for each data type (e.g., audio data, video data, text, etc.) that is received as communication traffic from the requesting user terminal, the user terminal emulation server 100 selects one of the I / O user devices from among the set of I / O user devices based on matching characteristics of the data type to the UI capabilities identified by the database 120 for the one of the I / O user devices, and then routes the data of the data type toward the network address of the selected one of the I / O user devices.

[0037] As will be explained in further detail below, the server 100 may also combine data streams that are received from the I / O user devices in the set, and route the combined data streams towards the requesting user terminal, e.g., via the network entity 150.

[0038] The user terminal emulation server 100 (e.g., via the IODH 212 described below) may be responsible for tracking which I / O user devices are proximately located to a present location of the user. The server 100 can receive presence reports from individual ones of the I / O user devices containing their network address and an identifier of a user tag which is determined by the I / O user device to be proximately located thereto. For example, an I / O user device may read a user tag through an NFC communication interface and / or may performother operations to detect presence of a user and to identify a user tag transported by the user. Responsive to the presence reports, the server 100 updates the database 120 to indicate which user tag identifiers are proximately located to which of the I / O user devices.

[0039] With further reference to the example system of Figure 1, a set of I / O user devices 130 has been determined by the I0DH 212 (Fig. 2) to be proximately located to a location of a first user carrying UserTag#l, and further determined to have UI capabilities that are combinable to satisfy the UI capability rule for providing a combined I / O user interface for the first user to use during a requested communication service. I0DH 212 (Fig. 2) responsively uses that set of I / O user devices 130 to provide a combined I / O user interface for use by the first user during a communication service via Application #1 and network entity 150 between the first user and another user terminal.

[0040] Similarly, another set of I / O user devices 130 has been determined by the I0DH 212 (Fig. 2) to be proximately located to a location of a second user carrying UserTag#2, and to further have UI capabilities that are combinable to satisfy the UI capability rule for providing a combined I / O user interface for the second user to use during a requested communication service. I0DH 212 responsively uses that set of I / O user devices 130 to provide a combined I / O user interface for use by the second user during a communication service via Application #2 and network entity 150 between the second user and yet another user terminal.

[0041] Figure 1 also illustrates that another set of I / O user devices 130 is not proximately located to either UserTag#l or UserTag#2.

[0042] As explained above, the communication request which is requesting the establishment of communication service session ("communication session" or "session") with an identified user may be initiated by the network entity 150 using the network address of the user terminal emulation application and identity of the user which were earlier registered with the network entity 150. However, the communication request may additionally or alternatively be generated by one of the I / O user devices 130 responsive to a command received from a proximately located user. For example, a user tag may operate automatically or through action of the user to initiate communications with one of the I / O user devices 130. Alternatively, a user may operate a user interface provided by one of the I / O user devices 130 to initiate, e.g., a combined audio and video call with another user. An identity of the user tag may be sent with the communication request, or the identity of the user tag may be logically bound to the communication session between the I / O user device and the user terminal emulation server 100. The application 110 performs the identifying, providing, routing,selecting, and combining operations described above to set up and operate a communication service between the user and the other user via the network entity 150.

[0043] Further example systems and related operations will now be described to further illustrate how I / O user devices having different UI capabilities can be operationally used or combined to provide a combined UI that can be used by user to satisfy the communication requirements of a communication service.

[0044] Further illustrative operations are described regarding an example embodiment in which a speaker device is one of the I / O user devices 130 in the set capable of playing a received audio stream and a microphone device is one of the I / O user devices 130 in the set capable of sensing audio to provide a microphone stream. Operations by the user terminal emulation application include updating the database 120 based on content of registration messages from the speaker device and the microphone device to identify network addresses of the speaker device and the microphone device, and to identify UI capabilities of the speaker device as having a speaker capability and the microphone device as having a microphone capability. The speaker UI capabilities may identify a number of speakers provided, sound loudness capability, and / or other operational characteristics. The microphone UI capabilities may identify the number of microphones provided, sensitivity of the microphones, and / or other operational characteristics. The speaker device and the microphone device are each identified as belonging to the set of I / O user devices that are determined to be proximately located to the location of the user (e.g., UserTag#l) and are further determined, based on the UI capabilities identified by the database 120, to satisfy the UI capability rule for used individually or combined to provide a combined I / O UI for the user to interface with the user terminal emulation application 110 to provide the communication service. Based on determining that the speaker device and the microphone device satisfy the UI capability rule, further operations are performed to route a microphone stream received from the microphone device toward the requesting user terminal (e.g., via network entity 150). When an audio stream is received as communication traffic from the requesting user terminal the operations select the speaker device based on matching an audio characteristic of the audio stream to the speaker capability identified by the database 120 for the speaker device, and then route the audio stream toward the network address of the speaker device.

[0045] In some embodiments, the UI capabilities of devices may correspond to different UI functions and / or circuits provided by the same electronic device. The speaker device and the microphone device may correspond to a speaker function and circuit and to a microphonefunction and circuit, respectively, of a same smartphone, television, or other electronic device. The streams may then be routed to an application programming interface (API) of the targeted functions and / or circuits.

[0046] The example embodiment may include, when a display device is one of the I / O user devices in the set capable of displaying a received video stream, the operations update the database 120 based on content of registration messages to identify network addresses of the display device, and to identify UI capabilities of the display device as having a display capability. The display UI capabilities may identify a screen display size, aspect ratio, pixel resolution, video frame rates supported, whether display device supports shared user support via split screen configuration, and / or other operational characteristics. The display device is also identified as among the set of I / O user devices that determined, based on the UI capabilities identified by the database 120, to satisfy the UI capability rule for being used individually or combined to provide the combined I / O UI for the user to interface with the user terminal emulation application 110 to provide the communication service. In an optional further embodiment, the set of I / O user devices is further selected based on each of the I / O user devices satisfying a rule for being proximately located to the location of the user. Based on determining that the speaker device, the display device, and the microphone device satisfy the UI capability rule, further operations respond to receipt of video stream as communication traffic from the requesting user terminal by selecting the display device based on matching a video characteristic of the video stream to the display capability identified by the database 120 for the display device, and then routing the video stream toward the network address of the display device.

[0047] In the example embodiment the operations for routing the audio stream and the video stream toward the network addresses (or APIs) of the speaker device and the display device, respectively, may include when audio data and video data are received within a same stream from the requesting user terminal through a first communication session: separating the audio data from the video data; routing the audio data toward the network address (or API) of the speaker device through a second communication session; and routing the video data toward the network address (or API) of the display device through the second communication session or a third communication session.

[0048] The example embodiment may include, when a camera device is one of the I / O user devices in the set capable of providing a camera stream, the operations update the database 120 based on content of a registration message to identify a network address of the camera device and to identify a UI capability of the camera device as having a cameracapability. The camera UI capabilities may identify a camera pixel count, image quality, light sensitivity, and / or other operational characteristics. The camera device is further identified as a member of the set of I / O user devices that are determined to be proximately located to the location of the user and is further determined, based on the UI capability identified by the database 120, to satisfy the UI capability rule for being used individually or combined with the other I / O user devices in the set to provide the combined I / O UI for the user to interface with the user terminal emulation application 110 to provide the communication service. Based on determining that the camera device satisfies the UI capability rule, further operations are performed to route the camera stream received from the camera device toward the requesting user terminal, e.g., via the network entity 150.

[0049] The operations for routing the microphone stream received from the microphone device and the camera stream received from the camera device toward the requesting user terminal, can include: receiving the microphone stream from the microphone device through a first communication session; receiving the camera stream from the camera device through the first communication session or a second communication session; combining the microphone stream and camera stream in a combined stream; and routing the combined stream toward the requesting user terminal through a third communication session, e g., via the network entity 150.

[0050] The example embodiment may include, when a keyboard device is one of the I / O user devices in the set capable of outputting key selection data responsive to key selections by a user among keys of the keyboard device, the operations can update the database 1 0 based on content of a registration message to identify a network address of the keyboard device and to identify a UI capability of the keyboard device as having a keyboard capability. The keyboard device capabilities may identify a number of keys (buttons) that are user selectable, indication of whether the keyboard is a physical keyboard or a touch sensitive input device, and / or other keyboard capabilities. The keyboard device is further identified as a member of the set of I / O user devices that are determined to be proximately located to the location of the user and is further determined, based on the UI capability identified by the database 120, to satisfy the UI capability rule for being used individually or combined with the other I / O user devices in the set to provide the combined I / O UI for the user to interface with the user terminal emulation application 110 to provide the communication service. Based on determining that the keyboard device satisfies the UI capability rule, further operations are performed to identify commands formed by the key selection data receivedfrom the keyboard and to perform operations that have been predefined as being triggered based on receipt of the identified commands.

[0051] The operations for routing the key selection data received from the keyboard device and microphone stream received from the microphone device, may include: receiving the key selection data from the keyboard device through a first communication session receiving the microphone stream from the microphone device through the first communication session or a second communication session; combining the key selection data and the microphone stream in a combined stream; and routing the combined stream toward the requesting user terminal through a third communication session, e.g., via the network entity 150.

[0052] Figure 2 is a block diagram illustrating the user terminal emulation server 100 as an element of an operator service node 202 within a cellular system 200. Referring to Figure 2, the communication service function of the network entity 150 (Fig. 1) may be provided by the operator service node 202 or may be reached through external infrastructure 240, e.g., the Internet or private network. The server 100 may, for example, be implemented in the radio access network 220 to provide edge computing with faster responsiveness or may be implemented within another node of the cellular system 200. The user terminal emulation server 100 can include the I0DH 212, a control function (CF) 214, the instantiated user terminal emulation applications 110, and a service gateway (GW) 216. A user terminal emulation application 110 may perform one or more user applications which are provided by a smart phone, such as a Netflix application, Meta (Facebook) application, Microsoft Teams application, Internet browser application, etc.

[0053] The user terminal emulation server 100, or the IODH 212 which can be part of the server 100, may perform operations to manage the VO user devices, such as to handle maintenance of the database 120, perform registration of I / O user devices to be available for use by the user terminal emulation applications 110, and manage mobility through operations for setting up and performing handover of communication services through I / O user devices. For example, the user terminal emulation server 100 / IODH 212 may operate to identify the IP address of a user terminal emulation application, e.g., which encapsulates a Microsoft Teams application, for a subscriber with a service provider, e.g., a Microsoft Teams server. In some other embodiments, the IODH 212 may be located outside the user terminal emulation server 100 in another network node of the system. The CF 214 may be responsible for assigning an IP address to each user terminal emulation application 110. The IP address to be assigned by the CF 214 may be received from the core network 210 functionality such as aPDN-GW. The service GW 216 may interconnect the user terminal emulation server 100 to a PSTN network, packet data network gateway of a 3GPP (3rdGeneration Partnership Project) system, etc. The cellular system 200 can include a Core Network 210 having a Home Subscriber Server (HSS) 211, a Policy and Charging Roles Function (PCRF), gateway (GW) and Mobility Management Entity (MME) providing control signaling related to mobile terminal mobility and security for the radio access. The HSS 211 contains subscriber-related information and provides support functionality for user authentication and user access to the system. The PCRF enables QoS control per data flow and radio bearer, by setting QoS rules for each data flow, based on operator set policies and subscriber information. The GW can include a Serving GW (S-GW) and a Packet Data Network GW (PDN-GW), where the S- GW interconnects the core network 210 with the radio access network 220 and routes incoming and outgoing packets for the VO user devices 232 and / or 130 and the user terminals 230. The PDN-GW interconnects the core network 210 with external infrastructure 240, such as the Internet, and allocates IP-addresses and performs policy control and charging.

[0054] Some I / O user devices 232 having cellular communication capability can communicate via, e.g., eNBs (Evolved Node B (a.k.a. RBS, Radio Base Station) or other radio access nodes of a Radio Access Network 220 with the operator service node 202 via the core network 210. In the system of Figure 2, the user terminal emulation server 100 / IODH 212 may handle set up of a communication service between a selected set of the I / O user devices that are proximate to a user and a remote user terminal 230 (e g., smart phone) via the cellular system 200.

[0055] Figure 3 is a block diagram illustrating the user terminal emulation server 100 communicating in a different manner with various elements of a cellular system 200, which may operate as the network entity 140 (Fig. 1), to provide communication services in accordance with some embodiments of the present disclosure. The system of Figure 3 differs from the system of Figure 2 by the user terminal emulation server 100 / being an Internet service within external infrastructure 240 outside of the cellular system 200. In the system of Figure 3, the CF 214 may determine the IP address to be assigned to different ones of the user terminal emulation applications 110 based on signaling from the Internet service within the external infrastructure 240.

[0056] The above and other example operations will now be described in further detail in the context of three different example "use cases": 1) incoming call scenario; and 2) outgoing call scenario.Use Case 1: Incoming call Scenario

[0057] This use case involves a user, with a user tag or other way of being identified, being proximately located to I / O user devices 130 having different UI capabilities when an incoming call is received by the user terminal emulation server. Although operations are explained below in the context of identifying a user through a physical user tag transported by the user, these operations are not limited thereto and may be used with any other way of identifying a user, such as by sensing biometric information that identifies the user and involving operational communications with the user tag transported by the user.

[0058] A user terminal emulation application 110 may be instantiated or otherwise activated responsive by an incoming call (service, session) targeting the user tag. The user terminal emulation application 110 can identify subscriptions associated with the user tag (e.g., registered in a user account) and preferred methods of communication (e.g., audio not video, audio and video, etc.) that have been specified by the user, and determines the UI capabilities of the I / O user devices that will be needed to satisfy the UI capabilities which may be specified for the incoming communication session. The user terminal emulation application 110 may ask the I0DH 212 to identify which I / O user devices 130 are proximately located to the user tag, and may further ask the IODH 212 to determine or may determine itself whether the identified I / O user devices 130 are usable individually or combinable to satisfy the UI capabilities specified by the incoming communication session. The user terminal emulation application 110 and / or the IODH 212 may receive an ACK or NACK back on whether a sufficient set of I / O user devices 130 can be used to provide the communication service. If ACK, then the IODH 212 also sets the state of the I / O user devices 130 in the set to in-use to avoid another user terminal emulation application 110 attempting to utilize the same I / O user devices 130 as which are presently in use.

[0059] In case of NACK, the user terminal emulation application 110 and / or the IODH 212 can take different actions to setup a reduced UI capability communication service with the user depending on user settings, e g., only allow sound-based communications instead of a combination of sound and video responsive to when no display device is presently available for use. An example of no display device being available may occur when the only display device that is proximately located to the user is presently being used by another user to receive information from another user terminal emulation application during an ongoing communication service or when no display device is proximately located to the user.

[0060] Further operations by user tags, I / O user devices, and the user terminal emulation server are described in accordance with this example use case. A user tag enters a room andsignals its presence to any proximately located and capable I / O user device in the room using a discovery beacon signal. Alternatively, one or more of the I / O user devices determines presence of the user tag by polling, such as by periodically transmitting discover beacon signals that trigger responsive signaling by the user tag. The I / O user devices that receive signaling indicated presence of the user tag report to the IODH 212 along with a network address of the I / O user device (e.g., IP address, port number, MAC address, FQDN, etc.) or an API of an application function on the I / O user device.

[0061] Alternatively, the signaling may be implicit when the IODH 212 already has presence information and / or presence is determined based on content of IP packets sent from the I / O user device to the IODH 212. The IODH 212 may be executed by the user terminal emulation server as part of the user terminal emulation application, by the I / O user devices, and / or by another computing node of the system. The user terminal emulation application corresponding to the specific user (i.e., the user tag) is updated with respect to the detected user's presence. The IODH 212 may operate to receive the notifications from the I / O user devices proximately located to the user tag. Further UI capability discovery (synchronization) communications may optionally be performed between the IODH 212 and the I / O user devices, or the IODH 212 may be per-configured with knowledge of the UI capabilities of the I / O user devices. The I / O user devices are associated to the user in the database 120, along with associated indications of combinable UI capabilities provided by the set of VO user devices which are proximately located to the user tag. One or more of the I / O user devices may be selected for default call reception ACK / NACK. The user via the user tag is now known to be reachable within the system through an identified set of I / O user devices with identified UI capabilities (e.g., speakers yes / no, display yes / no, microphone yes / no, keyboard yes / no, etc ), thereby creating a logical virtualized user terminal through which the user may be provided in a communication service. The user may receive or accept a communication service through a touchscreen, voice command sensed by a microphone, performing a defined gesture observable by a camera, and / or other input provided to one of the proximately located I / O user devices.

[0062] An incoming session (e.g., video call) from a requesting user terminal which is directed to the user (user tag) arrives at the user terminal emulation server for the user carrying the user tag. The individual or combinable UI capabilities of the available I / O user devices is compared to the UI requirements of the incoming session. When the UI requirements of the incoming session are not satisfied by the UI capabilities of the I / O user devices, the user terminal emulation server may renegotiate the required UI capabilities (e.g.,QoS) of the incoming session. In contrast, when the UI requirements of the incoming session are satisfied the user terminal emulation server prompts, via one or more of the available I / O user devices (e.g., a pre-selected answer device), the user carrying the user tag to provide a session request answer (ACK / NACK). The user responds through the pre-selected answer device to accept (ACK) or reject (NACK) the incoming session, to provide signaling to the user terminal emulation server. When an ACK is received, operations route an audio stream from the requesting user terminal to one of the I / O user devices in the set that has a speaker capability via one or more sessions, and routes a video stream from the requesting user terminal to another one of the I / O user devices in the set that has a display capability via one or more sessions. A data stream that is received from one of the I / O user devices in the set through a one or more sessions is routed toward the requesting user terminal. When two or more data streams are received through one or more sessions from the I / O user devices, they can be combined into a combined data stream that is routed toward the requesting user terminal.

[0063] The user terminal emulation server or I0DH 212 may perform operations to continuously monitor presence of the I / O user devices to determine when one or more of I / O user devices is no longer proximately located to the user such that it can no longer be included as part of the combined UI be provided during the ongoing communication session. The user terminal emulation server or IODH 212 may substitute the UI capability of another I / O user device to the set being used by the user for the ongoing communication session responsive to a previous member of the set no longer having required presence.Use case 2, Outgoing call

[0064] This use case involves a user, with a user tag, being proximately located to I / O user devices 130 having different UI capabilities when an outgoing call (communication session) is received by the user terminal emulation server. The I / O user devices 130 are associated to the identified user via the user terminal emulation server 100 which handles all communications sessions for the user while the associated I / O user devices 130 are managed by an IODH 212.

[0065] A user terminal emulation application 110 may be instantiated or otherwise activated responsive by an outgoing call being requested by a user carrying the user tag. The user may initiate an outgoing call through a touchscreen, voice command sensed by a microphone, performing a defined gesture observable by a camera, and / or other input provided to one of the proximately located I / O user devices.

[0066] The user terminal emulation application 110 can identify subscriptions associated with the user tag and preferred methods of communication (e.g., audio not video, audio and video, etc.) that have been specified by the user, and determines the UI capabilities of the I / O user devices that will be needed to satisfy the UI capabilities which may be specified for the outgoing call. The user terminal emulation application 110 may ask the I0DH 212 to identify which I / O user devices 130 are proximately located to the user tag, and may further ask the I0DH 212 to determine or may determine itself whether the identified I / O user devices 130 are individually useable or combinable to satisfy the UI capabilities specified by the outgoing call. The user terminal emulation application 110 and / or the I0DH 212 may receive an ACK or NACK back on whether one or a set of I / O user devices 130 can be used to provide the communication service. If ACK, then the I0DH 212 also sets the state of the one or more I / O user devices 130 in the set to in-use to avoid another user terminal emulation application 110 attempting to utilize the same I / O user device(s) 130 or one or more capabilities of that I / O user device(s) 130 which are presently in use. In case of NACK, the user terminal emulation application 110 and / or the I0DH 212 can take different actions to setup a reduced UI capability communication service with the user depending on user settings, e.g. only allow sound instead of the preferred sound and video responsive to when no display device is presently available for use (e.g., when presently used by another user terminal emulation application 110 or when none is proximately located to the user tag).

[0067] Example operations for an outgoing call and related data flows between user tags, I / O user devices, and the user terminal emulation server are now described in the context of this use case. A user tag enters a room and signals its presence to any proximately located and capable I / O user device in the room using a discovery beacon signal. Alternatively, one or more of the VO user devices determines presence of the user tag by polling, such as by periodically transmitting discover beacon signals that trigger responsive signaling by the user tag. The I / O user devices that receive signaling indicated presence of the user tag report to the I0DH 212 along with a network address or other identifier of the I / O user device (e.g., IP address, port number, MAC address, FQDN, etc.) or API of an application function on the I / O user device. The IODH 212 may be executed by the user terminal emulation server as part of the user terminal emulation application, by the VO user devices, and / or by another computing node of the system. The user terminal emulation application corresponding to the specific user (i.e., the user tag) is updated with respect to the detected user's presence.

[0068] The IODH 212 may operate to receive the notifications from the I / O user devices proximately located to the user tag. Further UI capability discovery (synchronization)communications are performed between the user terminal emulation server or the IODH and the I / O user devices. The I / O user devices are associated to the user in the database 120, along with associated indicated service subscriptions and combinable UI capabilities provided by the set of I / O user devices which are proximately located to the user tag. One or more of the I / O user devices may be selected for use in making a call or initiating another service. The user via the user tag is now known to be reachable within the system through an identified set of I / O user devices with identified UI capabilities (e.g., speakers yes / no, display yes / no, microphone yes / no, keyboard yes / no, etc.), thereby creating a logical virtualized user terminal through which the user may be provided in a communication service. The user may initiate a communication service through a touchscreen, voice command sensed by a microphone, performing a defined gesture observable by a camera, and / or other input provided to one of the proximately located I / O user devices.

[0069] A user carrying the user tag uses the UI of one of the I / O user devices to trigger an outgoing call (e g., video call), which triggers signaling of the outgoing call to the user terminal emulation server. The IODH 212 and / or the user terminal emulation application queries the user (e.g., displays a message, generates a sound, etc.) through one of the I / O user devices proximately located to the user to request the user to select among available types of communication methods that can be presently used for the outgoing call. One of the I / O user devices provides responsive signaling to the IODH 212 or user terminal emulation server 100 indicating the user's selected type of communication method for the outgoing call. The user terminal emulation server communicates an outgoing session stream request to the network entity 150, where the request may include an identifier of the calling user, identifier of the user terminal of the called user, and a quality of service for the communication session. The user terminal emulation server receives a communication session acceptance (ACK) or denial (NACK) from the network entity 150. When the communication session is denied, the user terminal emulation server may attempt to renegotiate the requested communication session such as at a lower quality of service.

[0070] When the communication session is accepted (ACK), for each data type that is received as communication traffic from the requested user terminal, the user terminal emulation server selects one of the I / O user devices from among the set of I / O user devices based on matching characteristics of the data type to the UI capabilities identified by the database 120 for the one of the I / O user devices, and then routes the data of the data type toward the network address of the selected one of the I / O user devices or API of a selected application function on the I / O user device. The I / O user devices transmit data streamsthrough one or more sessions to the user terminal emulation server, which may combine the data streams into a combined data stream that is routed toward the called user terminals via the network entity 150.

[0071] The user terminal emulation server or I0DH may continuously monitor presence of the I / O user devices to determine when one or more of I / O user devices is no longer proximately located to the user such that it can no longer be included as part of the combined UI be provided during the ongoing communication session. The user terminal emulation server or IODH may substitute the UI capability of another I / O user device to the set being used by the user for the ongoing communication session responsive to a previous member of the set no longer having required presence.

[0072] Security issues and related operations are now discussed below.

[0073] It can be desirable in some systems to provide operation for a virtual instance, e.g., virtual terminal emulation application 110, in the cloud, e.g., user terminal emulation server 100, to dynamically secure use of physical resources using authentication and key establishment procedures.

[0074] Some embodiments are directed to using a trusted party (function) to enable secure access and communications between a cloud service, e.g., user terminal emulation server 100 and I / O user device(s) 130. These embodiments may extend existing authentication functions to establish a secure association among various elements of the systems described in Figures 1-3 and, in particular, between the user terminal emulation server 100, the I / O user device(s) 130 proximately located to a user, and the user tag transported by the user.

[0075] In some embodiments, the user, who has been registered and authenticated to a cloud service, carries a user tag which has been associated (e.g., by a user identity) to the user terminal emulation server 100 such in the database 120. As explained above, there can be numerous I / O user devices 130 that are associated and registered to a lookup service, e.g., IODH 212.

[0076] When a user enters the close proximity of at least one I / O user device 130, operations are performed based on Extensible Authentication Protocol (EAP), Authentication and Key Management for Applications (AKMA), or another security function to establish a secure association between the user terminal emulation server 100, the UO user device(s) 130 proximately located to the user, and the user tag transported by the user. The secureassociation enables the user terminal emulation server 100 to utilize the UI capabilities of those I / O user device(s) 130 to obtain a communication service.

[0077] In some example scenarios, the user tag is transported by a user to identify the user and can be capable of short-range radio signalling, e.g., NFC, RFID, Bluetooth, etc., and / or long-range radio (LoRa) signalling, e.g., WiFi, cellular, etc. The user tag is registered and authenticated to the user terminal emulation server. At least one I / O user device 130 has a local service providing certain UI capabilities which can be registered with the user terminal emulation server 100 or I0DH 212 for inclusion in a lookup service provided through a database, e.g., database 120 and / or which may reside in the I0DH 212 and / or the I / O user devices 130.

[0078] Although some embodiments are described in the context of the user terminal emulation server 100 being a cloud-based service, these and other embodiments are not limited thereto. Operations disclosed herein can be used to enable an authenticated user to securely couple physical resources, residing on separate private networks, to a cloud-based service. The cloud-based service may be a phone service, videoconference service, streaming media service, video on-demand service, audio on-demand service, web service, digital assistant service, service technician service and / or any other service which may operate to communicatively connect to physical resources in the proximity of a user.

[0079] Various embodiments are now separately explained in the context of EAP -based authentication operations and the context of AKMA-based authentication operations, although the operations may be used with any security function operations which can facilitate secure access. In some embodiments, the user terminal emulation server 100 performs operations to establish a secure channel connection with a first I / O user device 130 using a session identifier and an identifier associated with the first I / O user device to determine a first I / O user device specific key generated from a master key, the first I / O user device specific key and the session identifier being used for authentication and secure communication of messages with the first I / O user device. The operations receive an indication of an I / O user interface capability of the first I / O user device 130 through the secure channel connection with the first I / O user device 130. The operations communicate with the first I / O user device 130 to use the I / O user interface capability to provide at least part of the communication service for a user.

[0080] These and other related operations are first described in the EAP-based authentication context and then described in the AKMA-based authentication context.

[0081] EAP-Based Authentication and related operations are now discussed below.

[0082] EAP is an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support fragmentation.

[0083] EAP is a two-party protocol spoken between the EAP peer and server. Within EAP, keying material is generated by EAP authentication algorithms, known as "methods". Part of this keying material can be used by EAP methods themselves, and part of this material can be exported. In addition to the export of keying material, EAP methods can also export associated parameters such as authenticated peer and server identities and a unique EAP conversation identifier, and can import and export lower-layer parameters known as "channel binding parameters", or simply "channel bindings".

[0084] From RFC 5247: “EAP methods supporting key derivation and mutual authentication SHOULD export a method-specific EAP conversation identifier known as the Session-Id. ..”. Exporting can entail providing the exported information to the EAP authenticator.

[0085] An example, flow of an EAP exchange for access authentication (802. lx used for WLAN / LAN), can include the device attaching to an authenticator point (AP). This means an (e.g.) 802.11 association is established between device and AP. The AP requests the identity of the device with an EAP identity request message. The device replies with its identity in an EAP response message. The AP, which works as an Authenticator, forwards the identity in a RADIUS or DIAMETER access request message to the authentication server.

[0086] The authentication server replies with a challenge for the device and indicating the EAP method to be used. The AP forwards the request in an EAP request message to the device. The device responds to the EAP message with an EAP response message. The AP forwards the response in a RADIUS or DIAMETER message to the authentication server. EAP messages are exchanged between the device and the authentication server until the authentication server has authenticated the device using the chosen method. The authentication server sends a RADIUS or DIAMETER access accept message, containing a pairwise master key (PMK) to the AP. The AP keeps the PMK and forwards the success in an EAP success message to the device. The device generates the corresponding PMK. The device is authenticated and the AP and device can use the PMK to configure access security.EAP can also be run towards Authenticators other than WLAN APs, and the Authenticator can be co-located with / part of the Authentication server.

[0087] EAP-based operations between a user tag 110 and the user terminal emulation server 110, which can operate an EAP server (function), are now described with reference to Figure 4. Figure 4 illustrates a combined flowcharts of operations and related data flows between the user terminal emulation application 110 and elements of an I / O user device (IOD) domain 410, such as I / O user devices 130, a lookup service / IODH, and an Extensible Authentication Protocol (EAP) authenticator 400 in accordance with some embodiments of the present disclosure. For brevity when discussing various example operations below, the term "EO user device" is abbreviated as "IOD".

[0088] Referring to Figure 4, an assumption in the EAP-based approach is that the user tag is transported with the user and contains circuitry which is configured to operate as an EAP client. The user tag therefore has at least limited communication and computational capabilities. An example user tag can be any type of mobile electronic device, such as tablet computer, mobile phone, or less complex device with NFC, RFID, Bluetooth, or other short- range communication such as capacitive communication coupling. The IODS 130 are registered with their (local) I0DH 212, which functions as a lookup service for IOD A ... IOD x in the local IOD domain 410, i.e., the I0DH 212 has information characterizing IOD A ... IOD x which may include an identifier, authentication credentials (e.g. public key of IOD A ... IOD x, location of IOD A ... IOD x such as spatial coordinates, room numbers, floor numbers, etc., defining type information, defining UI capabilities, etc. In some embodiments, the user terminal emulation application 110 may be executed within the IOD Domain 410, such as with the EAP Authenticator 400 and / or the IODH 212. Executing the user terminal emulation application on the same computing node or on a locally networked node as the EAP authenticator and / or IODH can simplify and reduce system resources consumed to exchange information and other communications therebetween.

[0089] Which users and / or user terminal emulation applications are allowed to interact with IOD A ... IOD x in the IOD domain 410 can be determined based on access control policies which can reside in the IODH 212 and may vary depending on use case scenario, e.g., semi-public domain, such as a hotel vs. private domain such as an enterprise office complex.

[0090]

[0091] An embedded Subscriber Identity Module (eSIM) is now discussed below.

[0092] GSMA has specified the eSIM provisioning architecture and protocol. eSIM is a way of storing and using SIM profiles in 3GPP devices such as mobile phones. Instead of inserting a physical SIM card (UICC) holding the SIM profile into a device, with eSIM it is possible to download the SIM profile from a provisioning server (SM-DP+ / SM-DP) onto an embedded (eUICC), integrated UICC (iUICC), or integrated eUICC (ieUICC) in the device. eSIM is often referred to as iSIM in the case of integrated (e)UICC. For simplicity, the terms eSIM and eUICC are used herein a general sense to denote all variants. The onboarding process includes the eUICC authenticating the provisioning server, and the provisioning server authenticating the eUICC. Furthermore, session keys are derived, which are used for protecting the profile when it is sent from the provisioning server to eSIM.

[0093] There are two main variants of eSIM in use, namely consumer and M2M, with separate functions and protocols. Further, GSMA has specified a 3rd alternative (see references [1] and [2]), aimed at constrained loT devices, which among other things makes it possible to use eSIM with devices that do not support HTTPS, but instead uses, e.g., Constrained Application Protocol (CoAP) over Datagram Transport Layer Security (DTLS). An Internet of Things (loT) device can also be constrained because it lacks a user interface. The eSIM for loT builds on the consumer variant, but introduces a new component called eSIM loT remote Manager (elM) for remotely managing profiles of loT devices. In case of network constrained loT devices, the elM can be an intermediary device between the loT device with the eUICC and the provisioning server assisting in the profile download. The elM can act as a proxy and make it possible to have the provisioning server (SM-DP+) work as in legacy eSIM (including using HTTPS), while the loT device with the eUICC uses a protocol stack suitable for constrained loT (e.g. CoAP over DTLS). The elM may either be a standalone entity or may be implemented by a device management entity so the protocol stack for secure device management can be leveraged also for secure profile download and profile management. In the loT device, besides the eUICC there is also a software component called loT Profile Assistant (IP A) that assists in profile download and installation and in profile management. In some realizations the IPA may be integrated into the eUICC.

[0094] For profile download, an Activation Code (AC) is used to provide the address of the provisioning server and an AC token, called Matching ID, to locate the prepared profile at the provisioning server. The profile is not bound to a specific eUICC until the download starts but allows the profile to be prepared in advance, before the identifier of the eUICC where the profile will be downloaded is known. The AC may either be delivered to the loT device itself or to the elM. For constrained loT devices the AC handling may be completelyhandled by the elM to offload the loT device. Alternatively, a profile is bound to the eUICC identifier (EID) when the profile is ordered, and in this case an activation code may not be needed if the address of the provisioning server is known to the elM or loT device.

[0095] Initial connectivity is one main challenge in eSIM; more specifically, how can the loT device with eUICC get connectivity so that it can be provisioned with the SIM profile so that it can get 3GPP connectivity. One approach is that the eSIM comes pre-installed with a provisioning profile (for 3GPP access), which can be used for initial connectivity needed for provisioning. Another approach is that the loT device has a secondary access interface, e.g. WiFi, which can be used to connect to a so called “primary device” which can provide global connectivity to the loT device for eSIM provisioning.

[0096] In [2] the elM needs to send signed messages to the eUICC for profile state management operations (e.g. enable profile, disable profile, delete profile) and for operations relating to management of the set of elMs currently managing the eUICC (e.g. adding a new elM, deleting an elM). The signed messages are introduced to protect against e.g. potential malwares residing in the device that may perform unauthorized change of active profile or delete of profile.

[0097] Some present embodiments are directed to users obtaining communication services through the I / O user interface capabilities of I / O user devices that use cellular or other (e g., WiFi) connections to a user terminal emulation application that emulates user terminals. An authenticated user can be temporarily associated and allocated to I / O user device(s) to obtain the communication service through the user terminal emulation application. There are benefits if the user’s own (e.g., existing cellular) subscription is used for the cellular connection of the I / O user device. For example, billing of the user’s data traffic becomes easier and does not require a specific billing system to be used at the I / O user device domain. The user may also leverage features and benefits of the user's subscription for the VO user device such as premium services (e.g. speed boost, data bucket, etc.).

[0098] An inefficient but straight-forward solution for how this may be done is for the user to have a plurality of SIM cards that the user can temporarily insert into SIM slots of a plurality of I / O user devices, if allowed, while using the I / O user devices to obtain the communication service. This would however not be possible in many I / O user device deployments because of restricted and / or denied physical access to those aspect of the I / O user devices. A more efficient solution is for the I / O user devices to be equipped with an eUICC and use the eSIM technology to provision a user-subscription profile (e.g., SIM profile) to the I / O user devices while the I / O user devices are being used. A furtherembodiment is directed to solving how this SIM profile provisioning to an I / O user device, and management of SIM profiles at the I / O user device, shall be implemented in the context of user terminal emulation such that the I / O user device always has connectivity to manage new users without charging a (previous) user for non-user data traffic.

[0099] Various present embodiments are directed to solutions that enable usersubscription profile (e.g., a SIM profile for use with embedded SIM (eSIM), integrated SIM (iSIM), etc.) provisioning to an I / O user device with 3GPP connectivity which is proximately located to a user based on the I / O user device communicating with a user tag transported by the user. Some further embodiments can use eSIM in context of emulating a user terminal through the I / O user interfaces of one or more I / O user device(s), which can be performed in scenarios where a SIM profile exists for the user on the I / O user device(s), and where the user does not have any credentials or SIM profile on the I / O user device(s).

[0100] Figures 6 and 7 illustrate combined flowcharts of operations and related data flows in a system including a user tag, I / O user devices 705, an EAP authenticator 212 / 400, a user terminal emulation application 110, a mobile network operator portal 700, and an eSIM provisioning server 420 in accordance with some embodiments of the present disclosure.

[0101] There are two use cases related to eSIM and I / O user devices.

[0102] The first use case is described with reference to Figure 6. The I / O user device 130 already has a (disabled) SIM profile of the user terminal emulation application 110 available. The I / O user device 130 is equipped with a cellular modem and an eUICC (Embedded Universal Integrated Circuit Card) where SIM profiles can be provisioned. The eUICC has an active SIM profile for I / O user device 130 management data. This profile is typically provisioned when the I / O user device 130 is configured. The I / O user device 130 also has a disabled SIM profile of the user terminal emulation application 110 This can be a typical case in an environment with a static group of users using the I / O user devices 130, e.g., an office or a home environment.

[0103] A user enters an IOD domain and approaches at least one I / O user device 130 registered to the IOD domain. The I / O user device 130 detects a user tag 101 transported by the user, and the I / O user device 130 responsively initiates user registration to the IOD domain via, e.g. EAP Authentication. An initial (e.g., default) SIM profile in the I / O user device 130, which is owned by the IOD domain, is enabled and used for providing connectivity for, e.g., I / O user device management data.

[0104] EAP Authentication 603 is performed between the user tag 101 (which may involve user input) and the user terminal emulation application 110, whereby the user tag 101is authenticated to the user terminal emulation application 110, and the IOD domain also learns about the successful authentication of the user tag 101 as well as session key material and session ID.

[0105] The I0DH 212 provides 604 I / O user device specific credential(s) to I / O user device(s) 130, which is / are selected based on their I / O user interface capabilities to support a communication service, and which is / are to be connected to the user terminal emulation application 110 session as an indication to connect to the user terminal emulation application 110.

[0106] The I / O user device(s) 130 authenticates 605 to the user terminal emulation application 110 using the received credentials. These operations are performed over the connection provided by the initial (IOD domain owned) SIM profile in the I / O user device 130.

[0107] If there already is a user and / or user terminal emulation application 110 specific SIM profile (e.g., user cellular subscription) available at the eUICC of the I / O user device 130 from a previous session, then a new SIM profile does not need to be provisioned. The eSIM loT remote Manager (elM) (which may be located in the I0DH 212, the I / O user device 130 itself, or as a dedicated entity in the network) is notified 606 about existing profile for the user and sends a command to the I / O user device 130 to enable the new profile. The I / O user device 130 enables the user terminal emulation application 110 specific SIM profile and the “default” (IOD domain owned) SIM profile is automatically disabled. The I / O user device performs a network attachment procedure to connect to the “new” cellular network according to the user profile. The I / O user device 130 then either re-authenticates to the user terminal emulation application 110 over the new connection (user terminal emulation application 110 eSIM), thereby terminating the initial session and creating an identical new one, or does mobility signaling towards the user terminal emulation application 110 to indicate the new IP address of the original session. Alternatively, the I0DH 212 may already in step 604 search its database to determine that there is a user and / or user terminal emulation application 110 specific SIM profile and notify the I / O user device 130 to enable it, or the I / O user device 130 itself may enable the profile if the I / O user device 130 has determined that there is already a user profile belonging to the user associated with the user tag. Step 605 may then be performed where a session with the user terminal emulation application is established including authentication, wherein, in this case, there is no need to re-authenticate and recreate a new session over the new connection or do mobility signaling.

[0108] The second use case is now described with reference to Figure 7. An I / O user device 130 does not have a user terminal emulation application 110 SIM profile readily available. These embodiments enable SIM profile provisioning to I / O user devices 130 equipped with, e.g., a cellular modem, and an eUICC where SIM profiles can be provisioned. In this case there is no user and / or user terminal emulation application 110 SIM profile available at the eUICC of the I / O user device 130. This is a typical case in an environment with public I / O user devices, e.g., in public spaces and transports, as well as in stores, museums, hotels, etc.

[0109] This second use case can initially proceed according to description of the first use case up to and including step 605 in Figure 6, and then further proceeds according to the additional new steps 701-704 shown in Figure 7.

[0110] In step 701, if there is no user specific SIM profile and / or user terminal emulation application 110 specific SIM profile (e.g., user cellular subscription) available at the eUICC of the I / O user device 130, the I / O user device 130 will trigger the provisioning of a user terminal emulation application 110 SIM profile. Triggering of the provisioning can correspond to the I / O user device 130 indicating to the I0DH 212 that a profile is needed (e.g., I0DH 212 propagates the request to the user terminal emulation application 110), or can correspond to the I / O user device 130 indicating directly to the user terminal emulation application 110 that a profile is needed. It is noted that when a local elM is used, i.e. where the I / O user device comprises an elM, (and the I / O user device 130 is capable of communicating directly with the SIM provisioning server 420) then operation of the I0DH 212 is not needed and all notifications then go directly from the I / O user device 130 to the user terminal emulation application 110.

[0111] In step 702, the I / O user device 130 obtains an activation code (AC) for a prepared profile (directly, or via the IODH 212) from the user terminal emulation application 110. For example, the user terminal emulation application 110 may have a (main) subscription with a mobile network operator (MNO) that allows to have a set of “child” subscriptions connected to its main subscription. The user terminal emulation application 110 can request an AC from its MNO, or it might have pre-fetched a set of ACs to be used later. In the case an AC is requested from the MNO, if no profile is already prepared, the MNO interacts with the provisioning server 420 to prepare a profile for download.

[0112] In step 703, the I / O user device 130 uses the received profile download information (e.g., AC) to connect to the eSIM provisioning server (SM-DP+) 420 of the MNO (e.g. eSIM provisioning server owned by the MNO or 3rdparty eSIM provisioningserver used by the MNO) to download and install a new SIM profile into the eUICC of the I / O user device 130 for the new user of the I / O user device 130.

[0113] In step 704, upon successful download and installation, the I / O user device 130 informs its eSIM loT remote Manager (elM), e.g. the IODH 212 or a local elM, which sends a command to the I / O user device 130 to enable the new profile. The “default” (IOD domain owned) SIM profile can be automatically disabled.

[0114] In a further step, the I / O user device 130 performs a network attachment procedure to connect to the “new” cellular network according to the new profile and, after either doing mobility update for the session established over the connection of the management profile or creating a new session towards the user terminal emulation application 110 established over the connection created using the user specific SIM profile. User data can now be sent and received using the new connection (linked to the new profile) for which the user will be billed via the (main) subscription.

[0115] Some potential advantages provided by these and other embodiments can include that they provide a secure method and solution for communication services through user terminal emulation as a cloud computing service. These embodiments can temporarily associate and allocate one or more I / O user devices to a user-subscription profile, and to provision an eSIM to a selected one or more I / O user devices and associated to an authenticated user terminal emulation application. These embodiment can make it possible for an IOD domain owner to provide the infrastructure for use by users who want access to services via user terminal emulation, while facilitating the user's payment for the data and / or network usage. These embodiment can make it possible for temporarily allocated I / O user devices to obtain access to and use premium services enabled for the user’s 3GPP subscription.

[0116] These and other embodiments are now described in further detail below.

[0117] As explained above, embodiments can enable eSIM provisioning to an I / O user device with 3 GPP connectivity, in the proximity of a user One assumption with an EAP based approach is that the user tag transported by the user can act as an EAP client. This means the user tag has at least some limited communication and computational capabilities. A smart card is a possible user tag where communication could be based on NFC or other short-range communication like capacitive coupling. Alternatively, the user tag may have Bluetooth or other communication capabilities.

[0118] Also as explained above, I / O user devices 130 are registered with their (local) IODH 212, which acts as a lookup service in that local domain. For example, the IODH 212has information regarding the I / O user devices 130 that can include identifiers, authentication credentials (e.g. public key of I / O user devices 130), locations of the I / O user devices 130 (e.g. meeting or hotel room number, floor etc.), I / O user interface capabilities, etc.

[0119] A user in proximity of a I / O user device 130 is authenticated using EAP as explained above and is registered to the IOD domain and secure communication, e.g., TLS- based or QUIC based, is established between the I / O user device 130 and the user terminal emulation application 110. If there is not already a SIM profile for the user available at the eUICC of the I / O user device 130 from a previous session, the user terminal emulation application 110 is notified by the I / O user device 130, or IODH 212, that a user cellular subscription profile needs to be provisioned to the I / O user device 130. Otherwise, the existing SIM profile can be directly enabled.

[0120] Thus, as part of the IODH 212 adding the selected the I / O user device 130 to the session of the user tag 101 or the user terminal emulation application 110, the IODH 212 obtains information about whether there exists a SIM profile of the user tag 101 or the user terminal emulation application 110 stored in the I / O user device 130. This can be based on a database query (database 120) where information about SIM profiles available at the I / O user devices 130 is stored together with an indication about which user tag 101 or user terminal emulation application 110 the profile belongs to. Thus, when a SIM profile is downloaded to the I / O user device 130, the database 120 is updated with the mapping <1 / 0 user device ID, SIM profile ID (e.g. ICCID), user / user terminal emulation application ID>, and similarly when the I / O user device 130 removes a profile the database is updated to match that, i.e the entry is removed from the database. Alternatively, the I / O user device 130 might itself keep a local record about the available SIM profiles and what user tag 101 or user terminal emulation application 110 they belong to. If the I / O user device 130 is requested (by IODH 212) to connect to a user terminal emulation application 110 for which it does not have a SIM profile, the I / O user device 130 signals the need for a SIM profile, either directly to the user terminal emulation application 110 (e g. as part of connecting and authenticating to the user terminal emulation application 110) or to IODH 212 which then interacts with the user terminal emulation application 110 to indicate the need for a profile for the I / O user device 130.

[0121] The user terminal emulation application 110 connects to an MNO portal to request a subscription. For example, the user terminal emulation application 110 has a (main) subscription with an MNO that allows to have a set of “child” subscriptions connected to its main subscription, or then the user terminal emulation application 110 just requests a new(parallel) profile that is not linked to the main subscription of the user but linked to a separate subscription. The communication between the user terminal emulation application 110 and the MNO may be secured using for example TLS and a shared key obtained using GBA / AKMA using the main subscription. Alternatively, the user terminal emulation application 110 has some other form of application layer credentials to use towards the MNO. The MNO returns an activation code (AC) to the user terminal emulation application 110 that provides information for the download of the profile. In some embodiments, in lieu of connecting to the MNO, the user terminal emulation application 110 already has requested a set of ACs for profiles that it can download and selects one of those.

[0122] The user terminal emulation application 110 provides the AC to the I / O user device 130 (possibly via the I0DH 212) and the I / O user device 130 uses the information in the AC to connect to an eSIM provisioning server (SM-DP+) 420 of the MNO to download and install a new SIM profile for the new user of the I / O user device 130.

[0123] If the I / O user device 130 is constrained (e.g. only supports low-power wide area (LPWA) networks such as NB-IoT and does not support HTTPS over TCP) such that it is not capable of communicating directly with the provisioning server (SM-DP+) 420, the profile download may be via the I0DH 212 acting as elM.

[0124] Upon successful download and installation of a new profile, or if a profile for the user / user terminal emulation server was available from the start, the I0DH 212, acting as eSIM loT remote Manager (elM), is triggered and sends a command to the I / O user device 130 to enable the profile. The “default” (IOD domain owned) eSIM profile is then automatically disabled.

[0125] The I / O user device 130 performs a new network attachment procedure to connect to the “new” network according to the new profile and user data is now sent and received using the new connection (linked to the new profile) for which the user will be billed via its (main) subscription. Any premium services enabled for the subscription will also be valid for the I / O user device 130 as long as the user’s profile is provisioned. Switching to using the newly enabled / activated profile means that the IP address used towards the user terminal emulation application 110 will change. This means that the I / O user device 130 either has to do a new authentication towards the user terminal emulation application 110 and request the same stream over the new connection IP as it requested initially when connecting over the management profile provided connection, or that the communication protocol (e.g. QUIC) used between the I / O user device 130 and the user terminal emulation application 110 has to support client mobility, in which case the I / O user device 130 needs to do mobility signalingfor the established session to move the session to the IP address of the new connection (linked to the new profile).

[0126] The I / O user device 130 notifies the I0DH 212 which in turn notifies the user terminal emulation application 110 about the successful installation and enabling of the profile and the profile identifier ICCID is also provided to the user terminal emulation application 110. Alternatively, the I / O user device 130 notifies the user terminal emulation application 110 directly. The MNO is notified by the I / O user device 130 via the provisioning server 420 that the profile was successfully installed and enabled.

[0127] When the user stops using the I / O user device 130 (e.g., walks away or terminates the service), the I0DH 212 is triggered to enable the initial (e.g., default or other IOD domain owned) SIM profile. The user SIM profile or the user terminal emulation application SIM profile is then automatically disabled. The user SIM profile or the user terminal emulation application SIM profile remains in the eUICC of the I / O user device 130 and can be reenabled when the user or the user terminal emulation application 110 uses the I / O user device 130 again. Alternatively, this could depend on IOD domain owner’s choice of how the I / O user devices shall behave. Another alternative for the IOD domain owner is to immediately delete the user SIM profile or the user terminal emulation application SIM profile. The I0DH 212 may, e.g., decide to trigger a request to delete the user SIM profile or the user terminal emulation application SIM profile from the I / O user device 130 due to limited space in the eUICC, and where the space is needed for download of a user SIM profile or a user terminal emulation application SIM profile of another user The user terminal emulation application 110 is notified by the I / O user device 130 (possibly via the IODH 212) that the profile was deleted. Also, the MNO is notified via the provisioning server 420.

[0128] Alternatively, in order to avoid communication with the IODH 212 to enable a user SIM profile or a user terminal emulation application SIM profile, a local elM may be running in the I / O user device 130 that handles the profile enabling instead of the IODH 212. The local elM can directly enable the user SIM profile or the user terminal emulation application SIM profile upon successful installation of the profile, or upon successful authentication of the user in case a profile is already available. The local elM can also trigger enabling of the initial (e.g., default or other IOD domain owned) SIM profile when the user stops using the I / O user device 130.

[0129] The local elM has an advantage over the IODH 212 acting as elM if the user SIM profile or the user terminal emulation application SIM profile for some reason loses connectivity. Then the I / O user device 130 must re-enable the initial (e.g., default or otherIOD domain owned) SIM profile. This can be done without connectivity using the local elM, but it is not possible to contact the IODH 212 without connectivity to trigger this re-enabling.

[0130] In case of using a local elM in an I / O user device, the I / O user device is capable of communicating directly with the provisioning server 420, and where the I / O user device keeps its own local record of provisioned profiles and link to user terminal emulation application users, all eSIM communication related to provisioning and notification can be directly between the I / O user device and the user terminal emulation application without involving the IODH 212 at all.

[0131] It is further possible to have a scenario where certain I / O user devices have a local elM and others are handled by the IODH 212.

[0132] Some further embodiments are directed to when an initial (e.g., default) IOD domain owned SIM profile is used as a fallback SIM profile. In order to not rely on user SIM profile or the user terminal emulation application SIM profile to recover the system, an initial (e.g., default) SIM profile owned by the IOD domain is used as a fallback profile such that whenever any enabled user SIM profile or the user terminal emulation application SIM profile for some reason is unable to provide connectivity, the I / O user device can locally enable for use (without a local elM running at the I / O user device) the initial (e.g., default) SIM profile owned by the IOD domain.

[0133] Some further embodiments are directed to revoking a SIM profile. When the user stops using the I / O user device (e.g., walks away or terminates the service), the IODH 212 (or local elM at the I / O user device) may, after enabling the initial (e.g., default) SIM profile owned by the IOD domain, automatically trigger a request to delete the user SIM profile from the I / O user device, e.g., based on settings configured when the user starts to use the I / O user device. Alternatively, the user terminal emulation application triggers the IODH 212 (possibly via the I / O user device) to delete the profile. The MNO is notified via the provisioning server (SM-DP+) 420 that the profile was successfully deleted. If the user has a subscription with a set of child subscriptions for use in I / O user devices, the deletion of the profile means a child subscription is released and a new profile can be downloaded in some other I / O user device linked to that child subscription.

[0134] Some further embodiments are directed to supporting multiple enabled profiles. It takes some time before a SIM profile is downloaded, installed, enabled, and a network attachment procedure to connect using the new profile is performed. In an alternative solution, the I / O user device is equipped with two cellular modems and an eUICC supporting multiple enabled profiles (MEP). This allows the SIM profile for I / O user devicemanagement data to be always enabled and used with the first cellular modem for sending and receiving I / O user device management data, including download of new SIM profiles for user data. The second modem and user SIM profile is used in parallel for user data. To allow the user to start sending and receiving user data immediately upon successful authentication of the user, the first modem and I / O user device management profile may be leveraged to, at least for a short while, send user data as a service included in the price for using the I / O user device. However, once the user SIM profile has been activated and there is network connectivity available via it, the I / O user device again needs to move over the session from the management profile to the user profile connection. This can be done, as discussed earlier, either via mobility signaling or establishing a new session over the connectivity provided by the user SIM profile.

[0135] Some further embodiments are directed to where the user’s SIM profile is dynamically provisioned when the user adds the capability of the I / O user device to the current session. As one example, an embodiment can facilitate billing for the user’s data as it becomes easier for the network to keep track of which I / O user devices are currently being used by a specific subscriber. Furthermore, if the user uses premium services in the network, e.g., temporary speed boost, this can be activated for all I / O user devices currently in the user’s session.

[0136] Further example operations are now described with primary reference to Figure 5 to provide communication services through secure network connections and for controlling delivery of services through the network connections using a user-subscription profile.

[0137] Referring to Figure 5, operations establish 511 a secure channel connection with a first IOD 130 using a session identifier and an identifier associated with the first IOD to determine a first IOD specific key generated from a master key, where the first IOD specific key and the session identifier being used for secure communication of messages with the first IOD.

[0138] In the scenario of Figures 4 and 5, a user who is transporting a user tag 101, e g., dongle, wants to utilize a proximately located IOD A. The user may trigger IOD A, by pushing a button on the user tag 101, triggering a command responsive to the user tag seeing a Service Set IDentifier (SSID) or Bluetooth (BT) address of IOD A, and / or IOD A. For example, the user may activate or initiate attention from IOD A using the user tag over NFC or RFID (i.e., very close proximity), and / or by the user pushing a button on the IOD A to initialize a bootstrapping process 501. Alternatively, the user tag can broadcast a beacon signal which can be detected by an IOD and which will trigger the authentication.

[0139] The user tag sends 502, via the IOD (target), an attach request to the system where the IOD is connected. The attach request is forwarded 503 by the IOD to the EAP Authenticator 400 in the system. The EAP authenticator 400 may be a local process in IOD A or in the I0DH 212 of the user terminal emulation server 100, or may reside as a separate entity in the IOD domain 410. The attach request may therefore be processed by the IOD itself, i.e., where multiple EAP Authenticators are present in the system, be processed by the I0DH 212, or be processed by the EAP authenticator 400.

[0140] The EAP authenticator 400 responds 504 with an EAP identity request, which is communicated back to the user tag 101.

[0141] The user tag 101 responds 505 with an EAP response, which carries the identity of the user tag 101. The identity identifies the user tag 101 (e.g., holder of user tag, such as the user) and points to the user terminal emulation application 110 associated with the user tag 101. The identity may be <hash(user_pub_key)>@<user_terminal_emulation_application_address>, or <Tag_ID>@<addr_terminal_emulation>. The hash of the public key provides a more compact identity of the public key of the user tag 101, and may be included with a network address of the user terminal emulation application 110. As explained above, the user terminal emulation application 110 may provide a communication service function corresponding to, for example, an over-the-top Voice Over Internet Protocol (VoIP) service, Netflix service, Facebook service, Microsoft Teams meeting service, Internet browser service, a cellular communication service, etc.

[0142] When the user tag 101 has been issued to the user, it may have also been associated with the corresponding user terminal emulation application 110. This means that the user tag 101, in addition to its own credentials (e g., public key pair), can be configured to have reachability information of the user terminal emulation application 110, e.g., a Fully Qualified Domain Name (FQDN), as well as credentials for authentication of the user terminal emulation application 110 (e g., public key of user terminal emulation application 110). Likewise, the user terminal emulation application 110 may have been configured with the credentials of the user tag 101 (e.g., public key of user tag 101). This means that the user terminal emulation application 110 knows that the user tag 101 is an entity that is authorized to request data streams and services from the user terminal emulation application 110.

[0143] The EAP authenticator 400 identifies the user terminal emulation application 110 based on the realm part of the identifier and forwards the request to the user terminalemulation application 110, which is here acting as the EAP server (referred to as "EAP server / user terminal emulation application 110" for brevity).

[0144] The EAP authenticator 400 first establishes 506a secure connection between itself and the EAP server / user terminal emulation application 110. The EAP messages are passed over that secure channel between authenticator and EAP server / user terminal emulation application 110. The secure connection may be a Transport Layer Security (TLS) session. The EAP Authenticator 400 knows it needs to talk with the EAP server / user terminal emulation application 110 based on the identity (realm part of identity) received 506b in EAP Identity Response. It also knows it needs to have a secure channel with the EAP server / user terminal emulation application 110. Thus, if there is not an existing secure session (typically TLS), the EAP Authenticator 400 creates the secure session and then forwards 506b the Identity response to the EAP server / user terminal emulation application 110. The communication between the EAP Authenticator 400 and the EAP server / user terminal emulation application 110 function of the user terminal emulation application 110, while using EAP messages, may be carried by DIAMETER or RADIUS protocol.

[0145] The user terminal emulation application / EAP server 110 and the user tag 101 will perform an EAP exchange 507 to authenticate the user tag 101 to the user terminal emulation application 110. The EAP server / user terminal emulation application 110 may also be authenticated to the user tag 101. The authentication may require multiple messages to be exchanged between the user tag 101 and the EAP server / user terminal emulation application 110 via the EAP authenticator 400.

[0146] Once the user tag 101 and possibly also the EAP server / user terminal emulation application 110 is / are successfully authenticated, the EAP server / user terminal emulation application 110 can send 508 a final EAP SUCCESS message to the EAP authenticator 400 The EAP SUCCESS message also carries the master key, e.g., pairwise master key (PMK), and the session-ID. The PMK key is the master key for the session-ID, the PMK key can be used to derive more keys for IODS, e g., IOD X, added to this session.

[0147] In an optional operation, the user tag 101 at this stage may derive the master key, e.g., PMK key, but it will not (necessarily) be used by the user tag 101. The master key can be used if the user wants to authorize additional IOD, e.g., IOD X, assuming the user is more in control of which IODs are added to the session by having to actively (e.g., by pressing a button, scanning a RFID tag, etc. to trigger) add more IODs to the EAP server / user terminal emulation application 110.

[0148] The authenticator generates 509 an IOD specific key K iodA from the received keying material to be used for streaming data between user terminal emulation application 110 and the target IOD A. Generating the IOD specific key K iodA may include using the received keying material as is, or may include performing a computational operation on the received key material such as by hashing a concatenation of the keying material and the identifier of the target IOD A and / or using another key derivation function (KDF) based on PMK and IOD specific information.

[0149] The EAP authenticator 400 provides 510, e.g., via the I0DH 212, the IOD specific key K_iodA to the IOD A, together with the session-ID exported by the EAP server / user terminal emulation application 110 and the address (e g. FQDN) of the user terminal emulation application 110.

[0150] The IOD A can use the received data to establish 511 secure channel (e.g., TLS) between itself and the user terminal emulation application 110. It is noted that in some embodiments, to establish the secure channel between IOD A and the EAP server / user terminal emulation application 110 there needs to be a shared secret (which is the first IOD specific key K_iodA), an identifier for who is connecting to the EAP server / user terminal emulation application 110 (IOD A) and that is used to derive IOD specific key, and an identifier (session-ID) that the EAP server / user terminal emulation application 110 can use to lookup the context from where it can derive the corresponding K_iodA.

[0151] If the EAP Authenticator 400 is part of IOD A, then IOD A could re-use the TLS session established in operation 506. However, a more scalable solution is enabled by using a uniform operation for all IODS connecting to the EAP server / user terminal emulation application 110 so as to not have special cases in an implementation.

[0152] In operation 11, the IOD A can use the session-ID to indicate to the EAP server / user terminal emulation application 110 the session / keying material / authenti cation context to which the connection request relates.

[0153] The EAP server / user terminal emulation application 110 locates context and associate keying material based on received session-ID. As background, the IOD A is to connect with the EAP server / user terminal emulation application 110 using a secure channel so the EAP server / user terminal emulation application 110 can stream or receive data from the IOD A, such that the IOD A needs to have keying material which it can use to establish a secure connection and the user terminal emulation application 110 needs to verify that the IOD A is authorized to send data. So, the session ID that was sent in operation 508 is what the IOD A can send to the EAP server / user terminal emulation application 110 so it knowsthe request relates to the authentication session that was setup for the session ID, and then locates its copy of the PMK key and any other keys negotiated during the authentication.

[0154] The IOD uses its own identifier (e.g. IOD A) as a kind of username. The IOD A thereby tells the EAP server / user terminal emulation application 110 who it is. The EAP authenticator 400 has derived an IOD A specific key based on the PMK key, e.g., by concatenating the IOD A ID and the PMK key and then hashing the concatenated string, and may truncate the hash value to a defined length. The EAP server / user terminal emulation application 110 needs to know the ID for the IOD A so it can derive the same IOD A specific key provided to IOD A in, e.g., step 510.

[0155] The EAP server / user terminal emulation application 110 uses the IOD identifier to derive IOD A specific key (K iodA) that is sent to the IOD A in step 510. In step 511, the IOD A uses the received key K_iodA as the password / authentication credential to authenticate to the EAP server / user terminal emulation application 110. In this operation the IOD A and the EAP server / user terminal emulation application 110 share the same IOD A specific key which is used as a shared secret that the EAP server / user terminal emulation application 110 and IOD A use to authenticate each other and establish a secure channel therebetween. The EAP server / user terminal emulation application 110 verifies, via PSK- based authentication, that the IOD indeed possesses a valid session key (K_iodA) and is thus authorized to connect to the EAP server / user terminal emulation application 110 and exchange data with it. A secure channel is established between the IOD A and the EAP server / user terminal emulation application 110

[0156] In steps 510, 511 and / or 512 the user terminal emulation application 110 can determine whether IOD A has a user-subscription profile (e g., user eSIM profile) that is associated with a subscription in use by the user and, if not, the IOD A can obtain from the user terminal emulation application 110 information, e.g., an Activation Code (AC), for obtaining and enabling a user-subscription profile. Although not shown, the user terminal emulation application 110 may interact with the MNO and request a new user-subscription profile (e.g., AC profile) if not yet available in local memory.

[0157] In step 514 IOD A communicates with the eSIM provisioning server (e.g., SM- DP+) 420 such as according to GSM specification to obtain the user-subscription profile (e.g., using the AC to obtain the user eSIM profile). IOD A and the eSIM provisioning server can use mutual authentication to download and install the user-subscription profile (e.g., user eSIM profile).

[0158] In step 515, IOD A after installing the user-subscription profile (e.g., user eSIM profile) enables it (e.g., based on command from IODH or using local elM) for use to attach to the network.

[0159] In step 516, mobility signaling is performed to move the session to the new (user eSIM based) connect. Since in the earlier steps there was authentication between IOD A and the user terminal emulation application 110, it was done using the management profile using an initial (e.g., default) user-subscription profile (eSIM profile) and then it had one IP address and when it now enabled the second user-subscription profile (eSIM) profile it will have a different IP address. Thus, the connection is no longer valid because the IP address has changed in step 516. It is possible that IOD A would perform mobility signaling to tell the user terminal emulation application 110 that it have changed IP address and now reachable at the new IP address. Alternatively, a new authentication is performed between IOD A and the user terminal emulation application 110 at this stage, so if using a quick protocol this could be performed as client side mobility.

[0160] In step 517, the operations allow application layer communications which may include traffic requested by the user or traffic requested or sent by the user terminal emulation application 110.

[0161] IOD A may indicate 517 its UI capabilities (e.g., display, camera, speaker, microphone, etc.) to the user terminal emulation application 110 which may operate based on the UI capabilities to enable data streaming to and / or from the IOD A.

[0162] The user may have defined policies to the EAP server / user terminal emulation application 110 regarding what operations can be enabled automatically (e.g., streaming video to a display device for the communication service) and what operations requires explicit user consent before performing (e.g., to enable microphone use for the communication service).

[0163] The EAP server / user terminal emulation application 110 may operate to interact 518 with the IODH 212 to exchange information regarding other IODS in the vicinity of the user which have UI capabilities that can be used to provide the communication service to the user. These operations can provide the EAP server / user terminal emulation application 110 information about what UI and / or VO capabilities could be available to the user for the communication service. Whether the EAP server / user terminal emulation application 110 may operate to interact 518 with the IODH 212 regarding other IODs may depend on which service and / or application is running in the EAP server / user terminal emulation application 110.

[0164] This communication may be performed via an entity of the IOD domain 410 acting as an EAP authenticator 400 towards the EAP server / user terminal emulation application 110, and thereby the already established secure channel could be re-used. Alternatively, the EAP authenticator 400 may generate an I0DH 212 specific session key (similar to what was performed for IOD A) and provide IODH 212 with all relevant info (e.g., K_iodh, session-ID, EAP server / user terminal emulation application 110 FQDN) for securely communicating with the user terminal emulation application 110.

[0165] The IODH 212 may itself be the EAP authenticator 400, in which case much of the “communication” between authenticator and IODH 212 is simplified, such as where the PMK is used directly by the IODH 212 to securely communicate with user terminal emulation application 110, or the already established secure session is re-used.

[0166] The communication may include the IODH 212 telling the user terminal emulation application 110 about which lODs are available to the user, and may include the EAP server / user terminal emulation application 110 requesting certain hardware resources from the IODH 212.

[0167] When the IODH 212 concludes, or the EAP server / user terminal emulation application 110 requests, that a certain other IOD (IOD X) should join the session established between the user and the IOD domain 410, the IODH 212 can enable IOD X for terminal emulation by requesting 519 the EAP authenticator 400 to generate 520 credentials for the other IOD X, (e.g., K iodx, session-ID, EAP server / user terminal emulation application 110 FQDN) and provide those credentials to the other IOD X.

[0168] The IODH 212 may send 519 a request based on the user instructing the EAP server / user terminal emulation application 110 (e.g., over connection with some already connected IOD) or based on local policy and / or configuration. The decision that a further IOD is required may be dependent upon: which application and / or service the user activates; ongoing application and / or service; available devices and their respective UI capabilities; and / or a defined configuration by the user to always try to find an IOD which has certain UI capability or capabilities.

[0169] If the other IOD X receives 521 a trigger (e g., where the trigger is the credentials etc. needed to connect to user terminal emulation application 110) from the IODH 212 or EAP authenticator 400, the other IOD X performs 522 similar operations to the IOD A as described above in operations 511 to 517.

[0170] Various embodiments have been described above in the context of being performed by certain system nodes. Other embodiments are not limited to the above-described mapping of certain operations to certain nodes. More general operations that can be performed by at least one network node of the system are now discussed below with reference to the flowchart of operations illustrated in Figure 8 in accordance with some embodiments of the present disclosure. Unless specifically required below, the operations being described may be performed by any one or more of the system nodes of the figures.

[0171] Referring to Figure 8, the operations include to determine 800 that an I / O user device is communicating with a user tag transported by a user. The operations associate 802 the I / O user device to a communication service provided through a user terminal emulation application. The operations provide 804 to the I / O user device a user-subscription profile that is associated with a subscription in use by the user. The operations then provide 806 at least part of the communication service through network connectivity controlled based on the usersubscription profile, to the user through an I / O user interface capability of the I / O user device.

[0172] The user-subscription profile may be a SIM profile.

[0173] In one embodiment, before the operation to determine 800 that the I / O user device is communicating with the user tag transported by the user, the I / O user device can operate to obtain an initial network connection, and the operation to determine 800 that the I / O user device is communicating with the user tag transported by the user is performed using the initial network connection. The initial network connection may be obtained using an initial subscription profile.

[0174] In a further embodiment, the operations determine that the user tag has been authenticated by an authentication node based on an identifier of the user tag reported by the I / O user device communicating with the user tag, wherein the authentication of the user tag is performed using the initial network connection.

[0175] In a further embodiment, the operations establish a session between the I / O user device and the user terminal emulation application through the initial network connection. Following the operation to provide 804 the user-subscription profile to the VO user device, the operations moving the session to a new network connection established with the I / O user device using the user-subscription profile. The at least part of the communication service is provided 806 through the session after moving to the new network connection established with the I / O user device using the user-subscription profile. The operations may terminate the initial network connection based on completion of the moving of the session to the new network connection.

[0176] In a further embodiment, the operations establish a first session through the initial network connection. Following the operations to provide 804 the user-subscription profile to the I / O user device, the operations further establish a second session between the I / O user device and the user terminal emulation server using the user-subscription profile.

[0177] Some further embodiments are directed to disabling the user-subscription profile to the I / O user device when the user stops using the I / O user device, e.g., user carrying the user tag wanders away and is handed over to another I / O user device or the communication service is terminated. In one embodiment, responsive to determining that the I / O user device cannot detect the user tag or that the communication service is terminated, the operations disable use of the user-subscription profile by the I / O user device.

[0178] In a further embodiment, the operations respond to determining that the I / O user device cannot detect the user tag or that the communication service is terminated, by resuming use of the initial subscription profile for communications between the I / O user device and the I0DH 212.

[0179] In a further embodiment, the operations to disable use of the user-subscription profile by the I / O user device, include to signal the I / O user device to delete the usersubscription profile from local memory of the I / O user device. In one embodiment, the I0DH 212 sends a signal to disable or delete the eSIM profile in the I / O user device. For example, the I0DH 212 can track where the user tag is moving to know when the user tag is no longer served by an (old) I / O user device, which can then trigger the I0DH 212 to send the signal disable or delete the eSIM profile in the old I / O user device.

[0180] In an alternative further embodiment, the operations to disable use of the usersubscription profile by the I / O user device, include to signal the VO user device to disable use of the user-subscription profile for communication while retaining the user-subscription profile in local memory of the VO user device.

[0181] Some further embodiments are directed to the situation where the usersubscription profile is already available in the I / O user device or I0DH, e.g., from a previous session. In one embodiment, the operation to provide 804 the user-subscription profile, includes to determine that the user-subscription profile was earlier provided for network connectivity of a now-terminated session of a communication service provided through the I / O user device to the user. The operations then activate the user-subscription profile for the at least part of the communication service to the user.

[0182] The operation to determine that the user-subscription profile was earlier providing for network connectivity of the now-terminated session of the communication serviceprovided through the I / O user device to the user, may include to determine that the usersubscription profile resides in a local memory of the I / O user device based on information stored in the I / O user device or in an I / O user device handler.

[0183] Some further embodiments are directed to an alternative situation where the usersubscription profile needs to be requested from an eSIM provisioning server. The I0DH or the user terminal emulation application responds to a request from the I / O user device by providing an activation code which the I / O user device uses to request a user-subscription profile from the eSIM provisioning server. In one embodiment, the operation to provide 804 the user-subscription profile to the I / O user device, includes to respond to receiving an indication from the I / O user device or an I / O user device handler that a user-subscription profile is needed, by providing an activation code to the I / O user device where the activation code is used to obtain the user-subscription profile from a subscriber identity module provisioning server.

[0184] The activation code may be requested from an MNO. The operation to provide 804 the user-subscription profile to the I / O user device, can include to respond to receiving the indication from the I / O user device or the I / O user device handler that a user-subscription profile is needed, by requesting the activation code from a mobile network operator.

[0185] The activation code may be selected from among a set of activation codes configured in a local memory of a user terminal emulation application or the I0DH. In one embodiment, the operation to provide 804 the user-subscription profile to the I / O user device, further includes to respond to receiving the indication from the I / O user device or the I / O user device handler that a user-subscription profile is needed, by selecting the activation code from among a set of activation codes configured in a local memory of the user terminal emulation application or an I / O user device handler, and indicating the selected activation code to the I / O user device.

[0186] Some other embodiments are directed to operations for provisioning the usersubscription profile to the I / O user device

[0187] In one embodiment, the operations to provide 804 the user-subscription profile to the I / O user device, include to obtain the user-subscription profile provided by a subscriber identity module provisioning server. The operations install the user-subscription profile in a subscriber module of the I / O user device. The operations notify a subscriber module Internet of Things remote manager that the user-subscription profile is installed. The operations then activate, in a subscriber module of the I / O user device, the user-subscription profile based onreceiving signaling from the subscriber module loT remote Manager following reception of notification about successful user-subscription profile installation.

[0188] The subscriber module may, for example, be an embedded universal integrated circuit card (eUICC), an integrated UICC (iUICC), or an ieUICC.

[0189] The subscriber module loT remote Manager may reside in an IODH or, alternatively, may reside locally in the I / O user device or reside in an independent function in the IOD domain.

[0190] Example I / O user device 130, user terminal emulation server 100 and / or IODH 212, EAP authenticator 400, and core network node 1200 are now discussed below.

[0191] Figure 9 is a block diagram of hardware circuit components of an VO user device 130 which are configured to operate in accordance with some embodiments. The VO user device 130 can include a wired / wireless network interface circuit 970, a near field communication circuit 980, at least one processor circuit 950 (processor), and at least one memory circuit 960 (memory). The processor 950 is connected to communicate with the other components. The memory 960 stores program code (e.g., providing functionality in cooperation with the user terminal emulation application 110) that is executed by the processor 950 to perform operations disclosed herein. The processor 950 may include one or more data processing circuits (e.g., microprocessor and / or digital signal processor), which may be collocated or distributed across one or more data networks. The processor 950 is configured to execute the program code in the memory 960, described below as a non- transitory computer readable medium, to perform some or all of the operations and methods for one or more of the embodiments disclosed herein for a I / O user device. The I / O user device 130 can include one or more UI component devices, including without limitation, a microphone 982, a speaker 984, a camera 986, a display device 970, and a user input interface 972.

[0192] Figure 10 is a block diagram of hardware circuit components of a user terminal emulation server 100 and / or an VO device handler (IODH) 212 which are configured to operate in accordance with some embodiments. The user terminal emulation server 100 and IODH 212 may be implemented in the same physical computing platform or may be implemented in different physical computing platforms which are communicatively networked together. The term "server" used herein can correspond to a single physical computing platform or a plurality of network connected physical computing platforms. The user terminal emulation server 100 and / or IODH 212 can include a wired / wireless network interface circuit 1070, a database 120 (e.g., any one or more of a listing VO user devices, UIcapabilities of the I / O user devices, communication protocols used to communicate with the I / O user devices, known proximities to user identifiers, identifiers of user tags, I / O user device specific keys, session identifiers, etc.), a display device 1082, a user input interface 1084 (e.g., keyboard or touch sensitive display), at least one processor circuit 1050 (processor), and at least one memory circuit 1070 (memory). The processor 1050 is connected to communicate with the other components. The memory 1070 stores instructions that are executed by the processor 1050 to perform operations disclosed herein. The processor 1050 may include one or more data processing circuits (e.g., microprocessor and / or digital signal processor), which may be collocated or distributed across one or more data networks. The processor 1050 is configured to execute computer program instructions in the memory 1070, described below as a non-transitory computer readable medium, to perform some or all of the operations and methods for one or more of the embodiments disclosed herein for a user terminal emulation server and / or an IODH.

[0193] Figure 11 illustrates a block diagram of hardware circuit components of an EAP authenticator 400 that are configured to operate in accordance with some embodiments of the present disclosure. The components can include a wired / wireless network interface circuit 1170, a display device 1172, a user input interface 1174 (e.g., keyboard or touch sensitive display), at least one processor circuit 1150 (processor), and at least one memory circuit 1160 (memory). The processor 1150 is connected to communicate with the other components. The memory 1160 stores program instructions that are executed by the processor 1150 to perform operations disclosed herein. The processor 1150 may include one or more data processing circuits (e.g., microprocessor and / or digital signal processor), which may be collocated or distributed across one or more data networks. The processor 1150 is configured to execute computer program instructions in the memory 1160, described below as a non-transitory computer readable medium, to perform some or all of the operations and methods for one or more of the embodiments disclosed herein for a mobile electronic device.Further Definitions and Embodiments:

[0194] In the above-description of various embodiments of present inventive concepts, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of present inventive concepts. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which present inventive concepts belongs. It will be further understood that terms, such asthose defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

[0195] When an element is referred to as being "connected", "coupled", "responsive", or variants thereof to another element, it can be directly connected, coupled, or responsive to the other element or intervening elements may be present. In contrast, when an element is referred to as being "directly connected", "directly coupled", "directly responsive", or variants thereof to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, "coupled", "connected", "responsive", or variants thereof as used herein may include wirelessly coupled, connected, or responsive. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Well-known functions or constructions may not be described in detail for brevity and / or clarity. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0196] It will be understood that although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Thus, a first element / operation in some embodiments could be termed a second element / operation in other embodiments without departing from the teachings of present inventive concepts. The same reference numerals or the same reference designators denote the same or similar elements throughout the specification

[0197] As used herein, the terms "comprise", "comprising", "comprises", "include", "including", "includes", "have", "has", "having", or variants thereof are open-ended, and include one or more stated features, integers, elements, steps, components or functions but does not preclude the presence or addition of one or more other features, integers, elements, steps, components, functions or groups thereof Furthermore, as used herein, the common abbreviation "e g ", which derives from the Latin phrase "exempli gratia," may be used to introduce or specify a general example or examples of a previously mentioned item, and is not intended to be limiting of such item. The common abbreviation "i.e.", which derives from the Latin phrase "id est," may be used to specify a particular item from a more general recitation.

[0198] Example embodiments are described herein with reference to block diagrams and / or flowchart illustrations of computer-implemented methods, apparatus (systems and / or devices) and / or computer program products. It is understood that a block of the blockdiagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by computer program instructions that are performed by one or more computer circuits. These computer program instructions may be provided to a processor circuit of a general purpose computer circuit, special purpose computer circuit, and / or other programmable data processing circuit to produce a machine, such that the instructions, which execute via the processor of the computer and / or other programmable data processing apparatus, transform and control transistors, values stored in memory locations, and other hardware components within such circuitry to implement the functions / acts specified in the block diagrams and / or flowchart block or blocks, and thereby create means (functionality) and / or structure for implementing the functions / acts specified in the block diagrams and / or flowchart block(s).

[0199] These computer program instructions may also be stored in a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer- readable medium produce an article of manufacture including instructions which implement the functions / acts specified in the block diagrams and / or flowchart block or blocks. Accordingly, embodiments of present inventive concepts may be embodied in hardware and / or in software (including firmware, resident software, micro-code, etc.) that runs on a processor such as a digital signal processor, which may collectively be referred to as "circuitry," "a module" or variants thereof.

[0200] It should also be noted that in some alternate implementations, the functions / acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality / acts involved. Moreover, the functionality of a given block of the flowcharts and / or block diagrams may be separated into multiple blocks and / or the functionality of two or more blocks of the flowcharts and / or block diagrams may be at least partially integrated Finally, other blocks may be added / inserted between the blocks that are illustrated, and / or blocks / operations may be omitted without departing from the scope of inventive concepts. Moreover, although some of the diagrams include arrows on communication paths to show a primary direction of communication, it is to be understood that communication may occur in the opposite direction to the depicted arrows.Many variations and modifications can be made to the embodiments without substantially departing from the principles of the present inventive concepts. All such variations andmodifications are intended to be included herein within the scope of present inventive concepts. Accordingly, the above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended examples of embodiments are intended to cover all such modifications, enhancements, and other embodiments, which fall within the spirit and scope of present inventive concepts. Thus, to the maximum extent allowed by law, the scope of present inventive concepts are to be determined by the broadest permissible interpretation of the present disclosure including the following examples of embodiments and their equivalents, and shall not be restricted or limited by the foregoing detailed description.References:[1] GSMA SGP.31 eSIM loT Architecture and Requirements, Version 1.1[2] GSMA SGP.32 eSIM loT Technical Specification, Version 1.0.1Abbreviations:3 GPP 3rdGeneration Partnership Project’AC Activation CodeApp Application, i.e. programEAP Extensible Authentication Protocol elM eSIM loT remote Manager eSIM embedded SIM eUICC embedded UICC eNB Evolved Node B (a.k.a. RBS, Radio Base Station)GW GatewayHTTPS Hypertext Transfer Protocol SecureICMP Internet Control Message ProtocolIOD Input / Output D evi ceIOD Input Output DeviceI0DH Input Output Device Handler loT Internet of ThingsiUICC integrated UICC ieUICC integrated eUICCIPA loT Profile AssistantITU International Telecommunication UnionMEP Multiple Enabled ProfilesNTP Network Time ProtocolPMK Pairwise Master KeyPPP Point-to-Point ProtocolRTP Real Time ProtocolRTCP Real Time Control ProtocolSDP Session Description ProtocolSR Sender ResponseUE User equipmentUI User InterfaceUICC Universal Integrated Circuit CardWi-Fi, WLAN Wireless Fidelity, Wireless Local Area Network

Claims

CLAIMS:

1. A method performed by at least one network node for providing a communication service through input and / or output, I / O, user devices, the method comprising: determining (800) that an I / O user device is communicating with a user tag transported by a user; associating (802) the I / O user device to a communication service provided through a user terminal emulation application; providing (804) to the I / O user device a user-subscription profde that is associated with a subscription in use by the user; and providing (806) at least part of the communication service through network connectivity controlled based on the user-subscription profile, to the user through an I / O user interface capability of the I / O user device.

2. The method Claim 1, wherein the user-subscription profile is a Subscriber Identity Module, SIM, profile.

3. The method of Claims 1 to 2, further comprising: before the determining (800) that the I / O user device is communicating with the user tag transported by the user, the I / O user device obtaining an initial network connection, and wherein determining (800) that the I / O user device is communicating with the user tag transported by the user is performed using the initial network connection.

4. The method of Claim 3, wherein the initial network connection is obtained using an initial subscription profile.

5. The method of Claim 4, further comprising:, determining that the user tag has been authenticated by an authentication node based on an identifier of the user tag reported by the I / O user device communicating with the user tag, wherein the authentication of the user tag is performed using the initial network connection.

6. The method of any of Claims 3 to 5, further comprising:establishing a session between the I / O user device and the user terminal emulation application through the initial network connection; and following the providing (804) of the user-subscription profile to the I / O user device, moving the session to a new network connection established with the I / O user device using the user-subscription profile, wherein the at least part of the communication service is provided (806) through the session after moving to the new network connection established with the I / O user device using the user-subscription profile.

7. The method of Claim 6, further comprising: terminating the initial network connection based on completion of the moving of the session to the new network connection.

8. The method of any of Claims 3 to 5 further comprising: establishing a first session through the initial network connection, and following the providing (804) of the user-subscription profile to the I / O user device, establishing a second session between the I / O user device and the user terminal emulation server using the user-subscription profile.

9. The method of any of Claims 1 to 8, further comprising: responsive to determining that the I / O user device cannot locate the user tag or that the communication service is terminated, disabling use of the user-subscription profile by the I / O user device.

10. The method of any of Claims 3 to 9, further comprising: responsive to determining that the I / O user device cannot locate the user tag or that the communication service is terminated, resuming use of the initial subscription profile for communications between the I / O user device and an I / O device handler.

11. The method of Claim 9, wherein the disabling use of the user-subscription profile by the I / O user device, comprises: signaling the I / O user device to delete the user-subscription profile from local memory of the I / O user device.12 The method of Claim 9, wherein the disabling use of the user-subscription profile by the I / O user device, comprises: signaling the I / O user device to disable use of the user-subscription profile for communication while retaining the user-subscription profile in local memory of the I / O user device.

13. The method of any of Claims 1 to 12, wherein the providing (804) of the usersubscription profile, comprises: determining that the user-subscription profile was earlier provided for network connectivity of a now-terminated session of a communication service provided through the I / O user device to the user; and activating the user-subscription profile for the at least part of the communication service to the user.

14. The method of Claim 13, wherein the determination that the user-subscription profile was earlier providing for network connectivity of the now-terminated session of the communication service provided through the I / O user device to the user, comprises: determining that the user-subscription profile resides in a local memory of the I / O user device based on information stored in the I / O user device or in an I / O user device handler.

15. The method of any of Claims 1 to 14, wherein the providing (804) of the usersubscription profile to the I / O user device comprises: responsive to receiving an indication from the I / O user device or an I / O user device handler that a user-subscription profile is needed, providing an activation code to the I / O user device where the activation code is used to obtain the usersubscription profile from a subscriber identity module provisioning server.

16. The method of Claim 15, wherein the providing (804) of the user-subscription profile to the I / O user device further comprises: responsive to receiving the indication from the I / O user device or the I / O user device handler that a user-subscription profile is needed, requesting the activation code from a mobile network operator.

17. The method of Claim 15, wherein the providing (804) of the user-subscription profile to the I / O user device further comprises: responsive to receiving the indication from the I / O user device or the I / O user device handler that a user-subscription profile is needed, selecting the activation code from among a set of activation codes configured in a local memory of the user terminal emulation application or an I / O user device handler, and indicating the selected activation code to the I / O user user device.

18. The method of any of Claims 1 to 17, wherein the providing (804) of the usersubscription profile to the I / O user device comprises: obtaining the user-subscription profile provided by a subscriber identity module provisioning server; installing the user-subscription profile in a subscriber module of the I / O user device; notifying a subscriber module Internet of Things remote manager that the usersubscription profile is installed; and activating, in a subscriber module of the I / O user device, the user-subscription profile based on receiving signaling from the subscriber module Internet of Things remote Manager following reception of notification about successful usersubscription profile installation.

19. The method of Claim 18, wherein the subscriber module is an embedded universal integrated circuit card, eUICC, an integrated UICC, iUICC, or an ieUICC.

20. The method of Claim 1 , wherein the subscriber module Internet of Things remote Manager resides in an I / O user device handler.

21. The method of Claim 19, wherein the subscriber module Internet of Things remote Manager resides locally in the I / O user device.

22. A system comprising at least one network node (212, 400, 110, 420, 101) for providing a communication service through input and / or output, I / O, user devices, the at least one network node configured to:determine that an I / O user device is communicating with a user tag transported by a user; associate the I / O user device to a communication service provided through a user terminal emulation application; and provide to the I / O user device a user-subscription profile that is associated with a subscription in use by the user; and provide at least part of the communication service through network connectivity controlled based on the user-subscription profile, to the user through an I / O user interface capability of the I / O user device.

23. The system of Claim 22, wherein the at least one network node is further configured to perform the method of any of Claims 2 to 21.

Images