Providing communication services to users via I / O user devices

Abstract

A user terminal emulation server (100) provides a communication service to a user (UserTag#!, UserTag#2) via one or more input and / or output (I / O) user devices (130). The user terminal emulation server is configured to register the user with a network entity (150) that provides the communication service and to predict that the I / O user device will be in proximity to the user. Based on the prediction that the I / O user device will be in proximity to the user, the user terminal emulation server determines that the I / O user device has an I / O user interface that satisfies a capability criterion that enables the user to use a first communication service of the communication services. Based on the satisfaction of the capability criterion and before the user is predicted to be in proximity to the I / O user device, the user terminal emulation server signals the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity.

Description

[Technical Field]

[0001] The present disclosure relates to a user terminal emulation server for providing communication services to a user via one or more input and / or output (I / O) user devices, a method for providing communication services to a user via one or more I / O user devices, and a corresponding computer program product. [Background technology]

[0002] The market for user terminals is driven by the desire to provide users with increasingly advanced communication capabilities and other operational features within the constraints of a portable, handheld form factor. Development requirements for user terminals are becoming increasingly complex as designers seek to integrate more diverse user interfaces and advanced operational features within a portable, handheld form factor. The increasing sophistication in operational features requires more highly integrated and faster processing circuits as circuit density increases, which becomes increasingly difficult under cost and power consumption constraints.

[0003] This comprehensive, feature-rich approach to developing user devices does not satisfy all of the myriad different needs of consumers, and the expectations of today's always-on society force users to vigilantly keep their user devices within reach or risk not being able to receive or initiate communication services in a timely manner.

[0004] Several approaches have been proposed that seek to replace traditional user terminals with other types of user interfaces that can interface with server-based services. For example, Sun Microsystems has proposed a thin-client stateless terminal that allows users to access user applications run by a server. The terminal includes an integrated smart card reader that operates to authenticate the user and allow the user to remove their smart card to pause their session (logging the user off from one terminal), subsequently insert the smart card into any other terminal (logging the user in at the other terminal), and immediately resume the session from where the user left off. Summary of the Invention

[0005] Various embodiments disclosed herein are directed to providing techniques for server-based emulation of a user terminal using an input and / or output (I / O) user device that is prepared for a user to use a communication service before the user is expected to be in proximity to the I / O user device.

[0006] Some embodiments are directed to a user terminal emulation server that provides communication services to a user via one or more input and / or output (I / O) user devices. The user terminal emulation server is configured to register a user with a network entity that provides the communication services and to predict that the I / O user device will come into proximity with the user. Based on the prediction that the I / O user device will come into proximity with the user, the user terminal emulation server determines that the I / O user device has an I / O user interface that meets a capability criterion that enables the user to use a first communication service of the communication services. Based on the satisfaction of the capability criterion and before the user is predicted to come into proximity of the I / O user device, the user terminal emulation server signals the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity.

[0007] Some other related embodiments are directed to a method for providing communication services to a user via one or more I / O user devices. The method includes registering a user with a network entity that provides the communication services and predicting that the I / O user device will be in proximity to the user. Based on the prediction that the I / O user device will be in proximity to the user, the method determines that the I / O user device has an I / O user interface that meets a capability criterion that enables the user to use a first communication service of the communication services. Based on the satisfaction of the capability criterion and before the user is predicted to be in proximity to the I / O user device, the method signals the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity.

[0008] Some other related embodiments are directed to a computer program product including a non-transitory computer-readable medium storing program instructions executable by at least one processor of a user terminal emulation server to provide a communication service to a user via one or more I / O user devices. This is accomplished through operations including registering a user with a network entity that provides the communication service and predicting that the I / O user device will be in proximity to the user. The operations further include determining, based on the prediction that the I / O user device will be in proximity to the user, that the I / O user device has an I / O user interface that meets capability criteria that enables the user to use a first communication service of the communication services. The operations further include signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity based on the satisfaction of the capability criteria and before the user is predicted to be in proximity to the I / O user device.

[0009] Some potential advantages of these embodiments include being able to provide a user with more immediate access to communication services provided via a network entity when the user comes into proximity of one or more I / O user devices that have already been prepared for use by the user based on a prediction that the user will be in proximity to the I / O user devices. Examples of the types of communication services that a network entity may provide include, but are not limited to, voice-over-IP and / or video-over-IP calling (e.g., Skype, Microsoft Teams, etc.), streaming media (e.g., Netflix, HBO, Hulu, etc.), online gaming, etc. I / O user devices may include, for example, wireless (e.g., Bluetooth, WiFi, light communications LiFi, and / or cellular)-enabled speakers, microphones, display devices, keyboards, cameras, other user input and / or output user interface devices, etc., which are becoming almost ubiquitous following the Internet of Things (IoT) revolution. When a user is predicted to come into proximity of one or more of the I / O user devices having an I / O user interface that meets the capability criteria for enabling the user to use a first of the communication services, the I / O user device is advantageously signaled to prepare to use the I / O user interface to provide the first communication service to the user via the network entity.The signaling may, for example, do one or more of: waking up the I / O user device to enable it to report when the user comes into proximity so that the first communication service can be provided more instantaneously; activating an I / O user interface for immediate use by the user for the first communication service; establishing a communication session to enable more rapid transfer of communication traffic for the first communication service over an already established communication session when the user comes into proximity of the I / O user device; communicating device configuration data to the I / O user device that configures the I / O user device to use the I / O user interface to provide the first communication service; etc. In this way, one or more I / O user devices are prepared for use by the user before the user is predicted to come into proximity. Faster and more seamless establishment of communication services via I / O user devices and network entities may facilitate implementation of user terminal emulation servers as cloud resources while providing communication services of acceptable quality.

[0010] Other servers, methods, and corresponding computer program products according to embodiments of the present subject matter will be or become apparent to one of ordinary skill in the art upon examination of the following figures and detailed description. All such additional servers, methods, and corresponding computer program products are intended to be included herein, within the scope of the present subject matter, and protected by the accompanying claims. Also, it is intended that all of the embodiments disclosed herein may be implemented separately or in combination in any manner and / or combination.

[0011] Aspects of the present disclosure are illustrated by way of example and not limitation in the accompanying figures. [Brief explanation of the drawings]

[0012] [Figure 1]FIG. 1 illustrates a system comprising a user terminal emulation server that operationally aggregates a set of I / O user devices in proximity to a user to logically form a virtualized user terminal that provides communication services, in accordance with some embodiments of the present disclosure. [Figure 2] 1 is a block diagram illustrating a user terminal emulation server that communicates with various elements of a cellular communication network to provide communication services, according to some embodiments of the present disclosure. [Figure 3] 1 is a combined flowchart of operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server, according to some embodiments of the present disclosure. [Figure 4] 1 is a combined flowchart of operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server, according to some embodiments of the present disclosure. [Figure 5] 1 is a combined flowchart of operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server, according to some embodiments of the present disclosure. [Figure 6] 1 is a flowchart of operations that may be performed by a user terminal emulation server to provide communication services through a set of I / O user devices, according to some embodiments of the present disclosure. [Figure 7] 1 is a flowchart of operations that may be performed by a user terminal emulation server to provide communication services through a set of I / O user devices, according to some embodiments of the present disclosure. [Figure 8] FIG. 1 is a block diagram of components of an I / O user device configured to operate in accordance with some embodiments. [Figure 9] FIG. 2 is a block diagram of components of a user terminal emulation server configured to operate in accordance with some embodiments of the present disclosure. [Figure 10]10 is a combined flowchart of operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server, according to some further embodiments of the present disclosure. [Figure 11] 10 is a combined flowchart of operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server, according to some further embodiments of the present disclosure. [Figure 12] 1 is a flowchart of operations that may be performed by a user terminal emulation server to signal an I / O user device to prepare to use an I / O user interface to provide a first communication service to a user via a network entity, according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] The inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which example embodiments of the inventive concepts are shown. However, the inventive concepts may 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 the various inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. There may be an implicit understanding that elements from one embodiment are also present in or used in another embodiment.

[0014] Known existing solutions do not acceptably support cloud-based, software-defined smartphones, and the like, in a manner that can provide sufficiently seamless handoff of communication services between individual input and / or output ("I / O") devices ("IODs") or sets of I / O user devices in proximity to a user. If an I / O user device can be made available to a user, there can be unacceptable delays between detecting the user's presence and establishing communication services via the I / O user device. Furthermore, handoff between I / O user devices may not be available or may be supported in a discontinuous manner that results in disconnections or interruptions in communication services as the user moves.

[0015] Various embodiments disclosed herein are directed to providing a user terminal emulation server, e.g., as a cloud server resource, that emulates a user terminal using an individual I / O user device or a set of I / O user devices that are in proximity to a user and have the necessary user interface (UI) capabilities to provide the user with the ability to obtain communication services provided by a network entity. These embodiments can predict that an I / O user device or a set of I / O user devices will be in proximity to a user and can send a signal to prepare the I / O user device or group of I / O user devices for use with communication services before the user is in proximity to the I / O user devices. When the user arrives, the I / O user device or group of I / O user devices can be configured to already be used to provide the network entity's communication services to the user, or can be more instantly available to provide communication services.

[0016] A user can receive and initiate communication services without needing a typical comprehensive and feature-rich user terminal, i.e., a traditional smartphone, mobile phone, tablet computer, etc. The user terminal emulation server can adaptively combine available UI capabilities of I / O user devices predicted to be in proximity to the user to support the provision of communication services to the user before the user comes into proximity of the I / O user devices. Dynamically allocating I / O user interface capabilities of I / O user devices whenever and wherever predicted to be in proximity to the user enables efficient and flexible use of existing hardware, such as televisions, conference phones, laptop computers, surveillance cameras, connected home appliances, and connected automobiles, to provide some UI functionality to the user during communication services. This reduces or eliminates the need for users to carry expensive comprehensive user terminals, e.g., smartphones, that include all necessary UI capabilities, display devices, keyboards, speakers, etc. Instead, users can carry a hardware device that serves to identify the user, referred to as a “UserTag,” via a wireless communication interface with one or more of the I / O user devices, such as a Near Field Communication (NFC) interface.

[0017] The various embodiments disclosed herein have the potential to disrupt the traditional handset-centric mobile communications industry because the features and capabilities of what constitutes a user terminal are not constrained to the domain of mobile phone manufacturers. A user terminal emulation server may operate to provide a user terminal, which may also be referred to as a "SoftUE" or "softphone," depending on the user terminal emulation application executed by the user terminal emulation server.

[0018] 1 illustrates a system comprising a user terminal emulation server 100 that operationally employs individual I / O user devices 130, or operationally aggregates a set of I / O user devices 130, in proximity to a user to logically emulate a user terminal that provides communication services via a network entity 150, in accordance with some embodiments of the present disclosure. FIG. 12 is a flowchart of operations that may be performed by the user terminal emulation server 100 to signal an I / O user device 130 to prepare to use its I / O user interface to provide a first communication service to a user via a network entity 150, in accordance with some embodiments of the present disclosure.

[0019] 1 and 12 , the user terminal emulation server 100 may be a cloud resource networked remotely from the I / O user device 130, or may be closer to the I / O user device 130, e.g., in an edge cloud, on a shared network with the I / O user device 130. The user terminal emulation server 100 is configured to register 1202 a user with a network entity 150 that provides communication services to the user, such as by registering the user with a voice over Internet Protocol (VoIP) service, a video conferencing service (e.g., Teams, Skype, etc.), a media content streaming service (e.g., Netflix, HBO, Hulu, etc.), a gaming service (e.g., an online gaming application), etc. The communication services may include, but are not limited to, voice over IP and / or video over IP calling (e.g., Skype, Microsoft Teams, etc.), streaming media (e.g., Netflix, HBO, Hulu, etc.), online gaming, etc. User terminal emulation server 100 is further configured to predict (1204) that one or more of I / O user devices 130 will come into proximity with the user, and to determine (1206) based on the prediction that I / O user device 130 will come into proximity with the user, that I / O user device 130 has an I / O user interface that satisfies a capability criterion that enables the user to use a first one of the communication services provided by network entity 150. Furthermore, based on satisfying the capability criterion and before the user is predicted to come into proximity with I / O user device 130, user terminal emulation server 100 is further configured to signal I / O user device 130 to prepare to use the I / O user interface to provide the first communication service to the user via network entity 150 (1208).

[0020] A user may carry a hardware tag, commonly referred to as a "UserTag," of FIG. 1, that can transmit a user identifier over a communication interface, such as a short-range communication interface (e.g., Bluetooth, Bluetooth low energy (BLE), near-field communication (NFC), RFID, etc., or a combination thereof), for receipt by one or more of the I / O user devices 130 in proximity to the user. One type of UserTag may be a simple, standalone electronic device with limited capabilities to transmit an identifier over a short-range communication interface. Another type of UserTag may be a smartphone or smartwatch with cellular connectivity that transmits cellular identification information (e.g., from a SIM card) or application identification information over a cellular or short-range communication interface.

[0021] In one exemplary embodiment, described in more detail below, user terminal emulation server 100 may operate to provide a seamless handoff of video conferencing services currently being provided to a first user from a first I / O user device 130 to a second I / O user device 130 via network entity 150 as the first user walks down a building hallway. For example, the first I / O user device 130 may be located at an entrance to the building hallway, and the second I / O user device 130 may be located further down the building hallway. User terminal emulation server 100 determines that the first user is currently in proximity to first I / O user device 130 based on receiving a report from the first I / O user device 130 providing a user identifier of a detected UserTag#1 associated with the first user. In response to an incoming request from the network entity 150 or the first user to establish a video conferencing service, the user terminal emulation server 100 uses the I / O user interface of the first I / O user device 130 to provide the video conferencing service.

[0022] The user terminal emulation server 100 predicts that the second I / O user device 130 will be in proximity to the user based on being configured to know the relative positions of the first and second I / O user devices 130 and / or from learning that the user will be in proximity to the second I / O user device 130 within a threshold time after being in proximity to the first I / O user device 130. Alternatively or additionally, the user terminal emulation server 100 may predict that the second I / O user device 130 will be in proximity to the user based on being notified of the user's location by a satellite-based positioning system (e.g., GNSS, GPS, etc.), a cellular-based positioning system, etc.

[0023] The user terminal emulation server 100 can determine that the second I / O user device 130 has an I / O user interface that meets the capability criteria to enable the first user to use the video conferencing service provided by the network entity 150, and can signal the second I / O user device 130 to prepare to use the I / O user interface to provide the video conferencing service to the first user. For example, as described in further detail below, the user terminal emulation server 100 can begin forwarding video conferencing service traffic to the second I / O user device 130 before the first user is predicted to come into proximity of the second I / O user device 130. The second I / O user device 130 may perform one of the following operations using the video conference service traffic: initiate playback of the video conference service traffic via the I / O user interface, buffer the video conference service traffic for subsequent playback via the I / O user interface in response to the user coming into proximity of the second I / O user device 130, and discard the video conference service traffic until the user comes into proximity of the second I / O user device 130.

[0024] The identity of a user, e.g., a first user, may alternatively or additionally be operationally determined by, for example, a biometric authentication operation performed by one or more of the I / O user devices 130. The biometric authentication operation may include, but is not limited to, one or more of voice recognition, image / facial recognition, eye recognition, fingerprint recognition, or a combination thereof. The user identity may be confirmed based on authentication information provided by the user, for example, when logging into an application or account. The user identity may also be determined from information provided by the mobile phone, such as from a subscription SIM, and the phone's near-field communication (NFC) capabilities may be used to determine the user's proximity of the mobile phone to one or more of the I / O user devices 130.

[0025] The user identifier, UserTag identifier, and user terminal application may be logically associated with one another within database repository 120 during a user registration process or as part of another start-up process. For example, during a user registration process, a user may have an account login identifier (which serves as a user identifier) ​​registered in database repository 120 as associated with a UserTag identifier for a physical UserTag given to (e.g., purchased by) the user and associated with a user terminal application that emulates a user terminal with specified capabilities (e.g., a mobile phone providing cellular or over-the-top voice-over-IP communication services).

[0026] Operations that may be performed by user terminal emulation server 100 to provide communication services to users are described below with further reference to Figure 6. Referring to Figures 1 and 6, user terminal emulation server 100 identifies the network address of I / O user device 130 based on the content of the received registration message and maintains (700) a database repository 120 that identifies the UI capabilities of I / O user device 130. The capabilities of I / O user device 130 may be logically arranged in repository 120 based on the type of UI capabilities provided, e.g., display device, microphone, headphones or ear speakers (e.g., Bluetooth ear speakers), speakers, keyboard, and may further be arranged based on quality of service characteristics provided by the UI capabilities (e.g., mono or stereo speakers, maximum speaker volume, display screen size, maximum display resolution, etc.).

[0027] An I / O user device 130 can communicate a registration message including its network address and UI capabilities to user terminal emulation server 100 in response to connecting to a new communications network, initial startup operations, and / or another event defined to trigger the generation of a registration message. The registration message can include the geographic location of the I / O user device 130, which can be stored in database repository 120. The I / O user device 130 can communicate with server 100 over a data network (e.g., the Internet and / or a private network) using a WiFi transceiver, a Bluetooth transceiver, a cellular transceiver, a light communication transceiver (LiFi), and / or another RF or optical communication transceiver.

[0028] The user terminal emulation server 100 may register a user with a network entity 150 that provides communication services (e.g., 1202 of FIG. 12 ), such as by registering (702) the user's identity with the network entity 150, and may further register a network address of the user terminal emulation application 110 with the network entity 150. The network entity 150 provides communication service functionality 140 that may correspond to, for example, over-the-top Voice over Internet Protocol (VoIP) services, videoconferencing services (e.g., Teams, Skype, etc.), media content streaming services (e.g., Netflix, HBO, Hulu, etc.), gaming services (e.g., online gaming applications), Internet browser services, cellular communication services, etc. The user terminal emulation application 110 is executed by the user terminal emulation server 100. The user terminal emulation application 110 may execute one or more applications typically executed by a smartphone, such as a VoIP service application, a videoconferencing service application, a media content streaming application, an online gaming application, an Internet browser application, etc.

[0029] 1, in some embodiments, a different instantiation of user terminal emulation application 110 is hosted by server 100 for each user to whom communication services are to be provided (i.e., the illustrated user terminal emulation applications #1-#N corresponding to users 1-N). User terminal emulation application 110 may register users with network entity 150 and launch communication services with users in response to communication requests, in accordance with the operations of FIG.

[0030] If the communication service function 140 of the network entity 150 is a VoIP service, operation 702 of registering the network address and user identification information of the user terminal emulation application with the network entity 150 may include registering the network address and user identification information of the user terminal emulation application 110 with a network server of a VoIP communication service provider.

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

[0032] User terminal emulation server 100 can receive registration messages from I / O user devices 130 using Session Initiation Protocol (SIP) / Session Description Protocol (SDP), each of which identifies the network address and UI capabilities of one of I / O user devices 130. Communication requests can be received from network entity 150 using SIP / SDP, and the work of providing communication sessions between user terminal emulation application 110 and each of the I / O user devices 130 in the set, and between user terminal emulation application 110 and the requesting user terminal, can be performed using SIP / SDP.

[0033] The registration message from the I / O user device 130 may include, for example, an IP address and port number, a MAC address, a Fully Qualified Domain Name (FQDN), and / or another network address, and may further include information identifying the UI capabilities of the I / O user device 130. The I / O user device 130 may respond to being powered on by communicating a registration message to the user terminal emulation server 100.

[0034] User terminal emulation server 100 receives 704 a communication request from network entity 150 to establish a communication service between a user and a requesting user terminal, e.g., a mobile phone, a computer with a Skype application, etc. In response to the communication request, user terminal emulation server 100 identifies 706 a set of I / O user devices 130 identified by repository 120 that are determined to be proximate to the user's location or are predicted to become proximate to the user. Based on the UI capabilities identified by repository 120 for the set of I / O user devices and based on the content of the communication request, user terminal emulation server 100 further determines that the set of I / O user devices meet a combination capability criterion that they can be combined to provide a combined I / O user interface for a user interfacing with user terminal emulation application 110 to provide the communication service.

[0035] Based on a determination that the set of I / O user devices meets the combined capabilities criteria, user terminal emulation server 100 provides (708), via network entity 150, a communication session between user terminal emulation application 110 and the I / O user devices in the set, and between user terminal emulation application 110 and the requesting user terminal. The communication request 704 received by user terminal emulation application 110 may include an indication of the minimum UI capabilities that should be provided to the user during the communication service, such as speaker only, a combination of speaker and microphone, display only, or a combination of a display device, speaker, and microphone. The combined capabilities criteria used by server 100 to determine whether and by which set of I / O user devices the communication service can be provided may thereby be defined based on the minimum UI capabilities indicated by the communication request.

[0036] Thereby, user terminal emulation server 100 forwards 710 communication traffic received from at least one of the I / O user devices in the set to the requesting user terminal via network entity 150. For each data type received as communication traffic from the requesting user terminal, user terminal emulation server 100 selects one of the I / O user devices from the set of I / O user devices based on matching the characteristics of the data type to the UI capabilities identified by repository 120 for one of the I / O user devices, and then forwards data of that data type to the network address of the selected one of the I / O user devices.

[0037] As described in further detail below, server 100 may combine 716 the data streams received from the I / O user devices in the set and forward the combined data stream toward the requesting user terminal, for example, via network entity 150.

[0038] User terminal emulation server 100 (e.g., application 110 or an I / O user device handler, described below) may be responsible for tracking which I / O user devices are currently proximate to the user's current location and for predicting which other I / O user devices will be proximate to the user. FIG. 7 is a flowchart of corresponding operations. Server 100 may receive presence reports 800 from individual ones of the I / O user devices, including their network addresses and identifiers of users determined by the I / O user devices to be in proximity. For example, the I / O user devices may read hardware tags, also referred to herein as “UserTags,” via an NFC communication interface, detect biometric information from the user, identify the user via facial recognition performed on a video stream from a camera, and / or perform other operations to detect the user's presence and identify the user. In response to the presence reports, server 100 updates repository 120 to indicate which user identifiers are in proximity to which of the I / O user devices (802).

[0039] 1 , a set of I / O user devices 130 are determined by instantiated user terminal emulation application #1 to be proximate to a location of a first user carrying UserTag #1 and have UI capabilities that are combinable to meet a combination capability criterion to provide a combined I / O user interface for use by the first user during a requested communication service. In response, application #1 uses the 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 between the first user and another user terminal via network entity 150.

[0040] Similarly, another set of I / O user devices 130 is determined by the instantiated user terminal emulation application #2 to be in proximity to a second user carrying UserTag #2 and to have UI capabilities that are combinable to meet the combination capability criteria to provide a combined I / O user interface for use by the second user during the requested communication service. In response, application #2 uses the set of I / O user devices 130 to provide a combined I / O user interface for use by the second user during the communication service between the second user and yet another user terminal via network entity 150.

[0041] 1 also shows that another set of I / O user devices 130 is not in proximity to either UserTag#1 or UserTag#2. This other set of I / O user devices 130 may be predicted to become in proximity to the first or second user, e.g., within a threshold time, and thus be available for use by user terminal emulation server 100 to provide communication services to that user in the future. According to some embodiments, user terminal emulation application 100 (e.g., user terminal emulation application #1 or #2) and the signaled other set of I / O user devices 130 prepare to use their respective I / O user interfaces to provide communication services to that user, as described further below.

[0042] As described above, a communication request requesting the establishment of a communication service with an identified user may be initiated by network entity 150 using the user's identification information, as well as the network address of a user terminal emulation application previously registered with network entity 150. However, the communication request may also or instead be generated by one of I / O user devices 130 in response to a command received from a nearby user. For example, a user may activate a user interface provided by one of I / O user devices 130 to initiate a combined audio and video call with another user. User terminal emulation server 100 receives the communication request along with the user's identification information, which may be detected via the UserTag. Application 110 performs the identification 706, provisioning 708, forwarding 710, selection 712, and combination 716 operations described above with respect to FIG. 6 to launch and operate communication services between that user and other users via network entity 150.

[0043] Further system and related work examples are now described that further illustrate how I / O user devices having different UI capabilities can be operationally combined to provide a combined UI that can be used by a user to meet the communication requirements of a communication service.

[0044] Further exemplary work will be described with respect to an example embodiment in which the speaker device is one of a set of I / O user devices 130 in a set capable of playing received audio streams, and the microphone device is another one of the I / O user devices 130 in a set capable of detecting audio and outputting microphone streams. Work by the user terminal emulation server 100 (e.g., one of the user terminal emulation applications) includes updating the repository 120 based on the content of registration messages from the speaker and microphone devices to identify the network addresses of the speaker and microphone devices, as well as to identify the UI capabilities of the speaker device as having speaker capabilities and the UI capabilities of the microphone device as having microphone capabilities. The speaker UI capabilities may specify the number of speakers provided, loudness capabilities, and / or other operational characteristics. The microphone UI capabilities may specify the number of microphones provided, microphone sensitivity, and / or other operational characteristics. The speaker device and microphone device are each determined to be in proximity to, or predicted to become in proximity to, the location of the user (UserTag#1), and are further identified as belonging to a set of I / O user devices that are determined, based on the UI capabilities identified by repository 120, to satisfy a combined capability criterion that they can be combined to provide the user with a combined I / O UI for interfacing with user terminal emulation application 110 to provide communication services. Based on the determination that the speaker device and microphone device satisfy the combined capability criterion, further action is taken to forward (e.g., via network entity 150) the microphone stream received from the microphone device to the requesting user terminal.When an audio stream is received as communication traffic from a requesting user terminal, the operation involves selecting a speaker device based on matching the audio characteristics of the audio stream to speaker capabilities specified by the repository for the speaker device, and then forwarding the audio stream to the network address of the speaker device.

[0045] This example embodiment may include, if one of the I / O user devices in the set capable of displaying the received video stream is a display device, updating repository 120 based on the contents of the registration message to identify the network address of the display device and to identify the UI capabilities of the display device as having the display capability. The display UI capabilities may identify screen display size, aspect ratio, pixel resolution, supported video frame rate, whether the display device supports shared user support via a split-screen configuration, and / or other operational characteristics. The display device is also identified within the set of I / O user devices as being determined to be in proximity to the user's location or predicted to become in proximity, based on the UI capabilities identified by repository 120, and as being determined to meet a combination capabilities criterion that it can be combined to interface with user terminal emulation application 110 to provide the user with a combined I / O UI for providing communication services. Based on a determination that the speaker device, display device, and microphone device meet the combined capability criteria, a further operation is to, in response to receiving the video stream as communication traffic from the requesting user terminal, select a display device based on matching the video characteristics of the video stream to the display capabilities identified by repository 120 for the display device, and then forward the video stream to the network address of the display device.

[0046] In this example embodiment, the act of forwarding the audio stream and the video stream to the network address of the speaker device and the network address of the display device, respectively, may include separating the audio data from the video data if the audio data and video data are received in the same stream from the requesting user terminal through the first communication session, forwarding the audio data to the network address of the speaker device through the second communication session, and forwarding the video data to the network address of the display device through the second communication session or the third communication session.

[0047] This example embodiment may include, if the camera device is one of the I / O user devices in the set capable of outputting a camera stream, updating repository 120 based on the contents of the registration message to identify the network address of the camera device and to identify the UI capabilities of the camera device as having a camera capability. The camera UI capabilities may identify camera pixel count, resolution, image quality, light sensitivity, and / or other operational characteristics. The camera device is further identified as part of a set of I / O user devices that are determined to be in proximity to the user's location and, based on the UI capabilities identified by repository 120, are further determined to meet a combination capabilities criterion that allows the camera device to be combined with other I / O user devices in the set to interface with user terminal emulation application 110 and provide the user with a combined I / O UI for providing communication services. Based on a determination that the camera device meets the combination capabilities criterion, a further operation is performed: forwarding the camera stream received from the camera device to the requesting user terminal, e.g., via network entity 150.

[0048] The act of forwarding the microphone stream received from the microphone device and the camera stream received from the camera device to the requesting user terminal may 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 the camera stream into a combined stream, and forwarding the combined stream to the requesting user terminal via, for example, network entity 150, through a third communication session.

[0049] This example embodiment may include an operation of updating repository 120 based on the contents of the registration message to identify a network address of the keyboard device and to identify UI capabilities of the keyboard device as having keyboard capabilities, if the keyboard device is one of the I / O user devices in the set that can output key selection data in response to a user's key selection from among the keys of the keyboard device. The keyboard device capabilities may identify a key count, an 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 a set of I / O user devices that are determined to be in proximity to the user's location or predicted to be in proximity to the user and, based on the UI capabilities identified by repository 120, are further determined to satisfy a combination capability criterion that the keyboard device can be combined with other I / O user devices in the set to provide the user with a combined I / O UI for interfacing with user terminal emulation application 110 to provide communication services. Based on a determination that the keyboard device satisfies the combination capability criterion, a further operation is performed of identifying a command formed by the key selection data received from the keyboard and performing a predefined operation as being triggered based on receipt of the identified command.

[0050] The act of forwarding the key selection data received from the keyboard device and the 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 the second communication session, combining the key selection data and the microphone stream into a combined stream, and forwarding the combined stream to a requesting user terminal via, for example, network entity 150, through a third communication session.

[0051] 2 is a block diagram illustrating a user terminal emulation server 100 as an element of an operator services node 202 in a cellular system 200. Referring to FIG. 2, the communication service functions of the network entity 140 (FIG. 1) may be provided by the operator services node 202 or may be delivered through an external infrastructure 240, such as the Internet and / or a private network. The server 100 may be implemented in the radio access network 220, for example, to provide edge computing with faster responsiveness, or may be implemented in another node of the cellular system 200. The user terminal emulation server 100 may include an I / O user device handler (IODH) 212, a control function (CF) 214, an instantiated user terminal emulation application 110, and a service gateway (GW) 216. The user terminal emulation application 110 may execute one or more applications typically executed by a smartphone, such as a Netflix application, a Facebook application, a Skype application, an Internet browser application, etc.

[0052] The IODH 212 may perform tasks for managing I / O user devices, such as maintaining the repository 120 (700 in FIG. 7) and / or registering users and possibly also the user terminal emulation application 110 (702 in FIG. 7). For example, the IODH 212 may act to register the IP address of the Skype application executed by or interfaced to the user terminal emulation application 110 and the user's Skype name with the Skype service server. The CF 214 may be responsible for assigning IP addresses to each user terminal emulation application 110. The IP addresses to be assigned by the CF 214 may be received from a core network 210 function such as a PDN-GW. The Service GW 216 may interconnect the user terminal emulation server 100 to a PSTN network, a packet data network gateway of a 3GPP (Third Generation Partnership Project) system, etc. The cellular system 200 may include a core network 210 having a Home Subscriber Server (HSS), a Policy and Charging Roles Function (PCRF), Gateways (GWs), and a Mobility Management Entity (MME) that provides control signaling and security related to mobile terminal mobility for radio access. The HSS contains subscriber-related information and provides support for user authentication and user access to the system. The PCRF enables QoS control per data flow and radio bearer by setting QoS criteria per data flow based on operator-configured policies and subscriber information. The GWs may include a Serving GW (S-GW) and a Packet Data Network GW (PDN-GW), which interconnects the core network 210 and the radio access network 220 and forwards incoming and outgoing packets to I / O user devices 232 and / or 130 and user terminals 230.The PDN-GW interconnects the core network 210 with an external infrastructure 240 such as the Internet, assigns IP addresses, and performs policy control and charging.

[0053] Several I / O user devices 232 with cellular communication capabilities can communicate with operator services node 202 via core network 210, e.g., eNBs or other radio access nodes of radio access network 220. In the system of Figure 2, user terminal emulation server 100 can handle the establishment of communication services between a selected set of I / O user devices determined to be in proximity to the user or predicted to become in proximity to the user and remote user terminals 230 (e.g., smartphones) via cellular system 200.

[0054] Figure 3 is a block diagram illustrating a user terminal emulation server 100 that can operate as a network entity 140 (Figure 1) that provides communication services and communicates in different manners with various elements of a cellular system 200, according to some embodiments of the present disclosure. The system of Figure 3 differs from the system of Figure 2 in that the user terminal emulation server 100 is an Internet service in an external infrastructure 240 outside the cellular system 200. In the system of Figure 3, the CF 214 can determine the IP addresses to be assigned to each of the user terminal emulation applications 110 based on signaling from the Internet service in the external infrastructure 240.

[0055] The above and other work will now be described in further detail in the context of three different exemplary "use cases": 1) an inbound scenario, 2) an outbound scenario, and 3) a sharing I / O user device scenario (sharing physical resources and / or capabilities).

[0056] Use Case 1: Incoming Scenario This use case involves a user, identified in some other way, with a UserTag who is in or is expected to be in proximity to an I / O user device 130 with various UI capabilities when an incoming call is received by the user terminal emulation server. Although the operations are described below in the context of identifying the user through a physical UserTag carried by the user, these operations are not so limited and may be used in any other manner of identifying the user, such as by sensing a biometric that identifies the user.

[0057] The user terminal emulation application 110 may be instantiated or enabled in response to an incoming call (service, session) targeted for the UserTag. The user terminal emulation application 110 may identify the subscriber (i.e., physical user) associated with the UserTag and the preferred communication method (e.g., audio rather than video, audio and video, etc.) specified by the user, and determine the UI capabilities of the I / O user devices required to satisfy the UI capabilities that may be specified for the incoming communication session. The user terminal emulation application 110 may ask the IODH to identify which I / O user devices 130 are proximate to the UserTag or are predicted to become proximate to the UserTag, and may further ask the IODH to determine, or determine itself, whether the identified I / O user devices 130 can be combined to satisfy the UI capabilities specified by the incoming communication session. The user terminal emulation application 110 and / or the IODH may receive an ACK or NACK regarding whether a sufficient set of I / O user devices 130 is available to provide the communication service. In the case of an ACK, the IODH may also set the state of an I / O user device 130 in the set to in use to prevent another user terminal emulation application 110 from attempting to utilize the same I / O user device 130 that is currently in use or attempting to use. In the case of a NACK, the user terminal emulation application 110 and / or the IODH may variously act, depending on the user settings, to bring up a reduced UI capabilities communication service with the user, for example, allowing only audio-based communication instead of combined audio and video in response to the absence of any display devices currently available.An example of no display devices being available may occur when the only display device in proximity to the user is currently being used by another user to receive information from another user terminal emulation application during an ongoing communication service, or when there are no display devices in proximity to the user.

[0058] FIG. 3 is a combined flowchart of operations and related data flows between a UserTag, an I / O user device, and a user terminal emulation server according to some embodiments of the present disclosure. Referring to FIG. 3, a UserTag enters a room and signals its presence to any nearby, capable I / O user devices in the room using a discovery beacon signal (400). Alternatively, one or more of the I / O user devices determine the presence of the UserTag by polling (402), such as by periodically transmitting a discovery beacon signal that triggers in response to the signaling by the UserTag. The I / O user device receiving the signaling reports the UserTag's presence to the IODH at the user terminal emulation server (404), along with the I / O user device's network address (e.g., IP address, port number, MAC address, FQDN, etc.). The user terminal emulation application corresponding to the particular user (i.e., UserTag) is updated in connection with the detected user's presence (406). The IODH can be operable to receive notifications from I / O user devices that are in proximity to the UserTag. Further UI capability discovery (synchronization) communications occur between the user terminal emulation server and I / O user devices that reported the user's presence and / or I / O user devices that are predicted to be in proximity to the user, such as based on the user's current proximity to another one of the I / O user devices (410). The I / O user devices are associated with the user in the repository, along with combinable UI capabilities provided by the corresponding subscription indications, the set of I / O user devices that are in proximity to or predicted to be in proximity to the UserTag.By operation 412, it is now seen that a user via a UserTag is reachable within the system through a specified set of I / O user devices having specified UI capabilities (e.g., speaker yes / no, display yes / no, microphone yes / no, keyboard yes / no, etc.), thereby creating a logical virtualized user terminal through which the user can be provided with communication services. The user can initiate communication services through a touchscreen, voice commands sensed by the microphone, making defined gestures observable by the camera, and / or other input provided to one of the proximate I / O user devices.

[0059] At operation 414, an incoming session (e.g., a video call) from a requesting user terminal destined for a user (UserTag) arrives at a user terminal emulation server for the user with UserTag. At operation 416, the combinable UI capabilities of available I / O user devices are compared with the UI requirements of the incoming session. If the UI requirements of the incoming session are not met by the combinable 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 416. In contrast, if the UI requirements of the incoming session are met by the combinable UI capabilities of the I / O user devices, the user terminal emulation server prompts the user with UserTag to provide a session request answer (ACK / NACK) via one or more of the available I / O user devices (e.g., pre-selected answering devices). The user responds through preselected answer device 420 by signaling 422 to the user terminal emulation server to accept (ACK) or decline (NACK) the incoming session. Once the ACK is received, operation 424 forwards 426 the audio stream from the requesting user terminal to one of the I / O user devices in the set that has speaker capability via one or more sessions, and forwards 426 the video stream from the requesting user terminal to another one of the I / O user devices in the set that has display capability via one or more sessions. A data stream received from one of the I / O user devices in the set via one or more sessions 429 is forwarded 430 to the requesting user terminal. When two or more data streams are received 429 from an I / O user device via one or more sessions, the data streams may be combined into a combined data stream, and the combined data stream is forwarded 430 to the requesting user terminal.

[0060] The user terminal emulation server performs operations (428) that continuously monitor the presence of the I / O user devices and can determine when one or more of the I / O user devices are no longer in proximity to the user such that they can no longer be included as part of the combined UI capabilities provided during the ongoing communication session. In response to a previous member of the set no longer being required to be present, the user terminal emulation server can substitute the UI capabilities of another I / O user device in the set used by the user in the ongoing communication session. The user terminal emulation server substitutes the UI capabilities of another I / O user device that is predicted to come into proximity to the user as the user moves, and signals the other I / O user device to prepare to use its I / O user interface to support the ongoing communication session. As described in further detail below, the user terminal emulation server signals the I / O user device that is predicted to come into proximity to the user to prepare to use its I / O user interface to provide the user with the ongoing communication session.

[0061] Use case 2, outgoing call This use case involves a user with a UserTag who is in or is expected to be in proximity to an I / O user device 130 with various UI capabilities when an outgoing call (communication session) is received by the user terminal emulation server. The I / O user device 130 is associated with the identified user through the user terminal emulation server 100, which handles all of the communication sessions for that user, while the associated I / O user device 130 is managed by the IODH.

[0062] The user terminal emulation application 110 may be instantiated or enabled in response to a call being requested by a user with a UserTag. The user may initiate a call through a touchscreen, a voice command detected by a microphone, making a predefined gesture observable by a camera, and / or other input provided to a nearby I / O user device.

[0063] The user terminal emulation application 110 can identify the subscriber (i.e., the physical user) associated with the UserTag and the preferred communication method specified by the user (e.g., audio rather than video, audio and video, etc.) and determine the UI capabilities of the I / O user devices required to satisfy the UI capabilities that may be specified in the outgoing call. The user terminal emulation application 110 can ask the IODH to identify which I / O user devices 130 are proximate to the UserTag and, for example, can further ask which other I / O user devices 130 are predicted to be proximate to the user depending on the response. The user terminal emulation application 110 can further ask the IODH, or determine itself, to determine whether the identified I / O user devices 130 and / or other I / O user devices 130 can be combined to satisfy the UI capabilities specified by the outgoing call. The user terminal emulation application 110 and / or the IODH can receive an ACK or NACK based on whether a sufficient set of I / O user devices 130 can be used to provide the communication service. In the case of an ACK, the IODH also sets the state of the I / O user devices 130 in the set to IN USE to prevent another user terminal emulation application 110 from attempting to utilize the same I / O user device 130 that is currently in use or about to be used. In the case of a NACK, the user terminal emulation application 110 and / or the IODH may, depending on the user settings, variously initiate a reduced UI capabilities communication service with the user, such as providing only sound instead of the preferred sound and video in response to no display devices being available at the time (e.g., if none are currently in use by another user terminal emulation application 110 or are in proximity to the UserTag or are expected to become in proximity to the UserTag at the threshold time).

[0064] FIG. 4 is a combined flowchart of the operations and associated data flows of a call between a UserTag, an I / O user device, and a user terminal emulation server, according to some embodiments of the present disclosure. Referring to FIG. 4, a UserTag enters a room and signals its presence to any nearby, capable I / O user devices in the room using a discovery beacon signal (500). Alternatively, one or more of the I / O user devices may determine the presence of the UserTag by polling (502), such as by periodically transmitting a discovery beacon signal that triggers in response to the signaling by the UserTag. The I / O user device receiving the signaling reports the UserTag's presence to the IODH at the user terminal emulation server (504), along with the I / O user device's network address (e.g., IP address, port number, MAC address, FQDN, etc.). The user terminal emulation application corresponding to the particular user (i.e., UserTag) is updated in conjunction with the detected user presence (506).

[0065] The IODH may operate to receive notifications from I / O user devices in proximity to the UserTag. Further UI capability discovery (synchronization) communication between the user terminal emulation server and the I / O user devices occurs 510. The I / O user devices are associated with the user in the repository along with corresponding subscription indications, combinable UI capabilities provided by the set of I / O user devices in proximity to the UserTag. By operation 512, it is now known that the user via the UserTag is reachable within the system through the set of identified I / O user devices having specified UI capabilities (e.g., speaker 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 communication services. The IODH may further predict which other I / O user devices will come into proximity to the user, such as within a threshold time, and have combinable UI capabilities that meet the capability requirements. A user can initiate communication services through a touchscreen, voice commands sensed by a microphone, making defined gestures observable by a camera, and / or other input provided to one of the nearby I / O user devices.

[0066] At operation 514, a user with a UserTag triggers an outgoing call (e.g., a video call) using the UI of one of the I / O user devices, thereby triggering signaling of the outgoing call to the user terminal emulation server 516. At operation 518, the IODH queries the user through one of the I / O user devices in proximity to the user (e.g., displays a message, plays a sound, etc.) and requests the user to select from available types of communication methods that can then be used for the outgoing call. One of the I / O user devices provides response signaling to the IODH 520 indicating the communication method type selected by the user for the outgoing call. At operation 522, the user terminal emulation server communicates an outgoing session stream request to network entity 150, which may include an identifier of the calling user, an identifier of the called user terminal, and quality of service for the communication session. At operation 522, the user terminal emulation server receives a communication session accept (ACK) or a communication session reject (NACK) from network entity 150. If the communication session is rejected, the user terminal emulation server may attempt to renegotiate 524 the requested communication session, such as with a reduced quality of service.

[0067] Once the communication session is accepted (ACK), for each data type 528 received in communication traffic from the requesting user terminal, the user terminal emulation server selects one of the I / O user devices from the set of I / O user devices based on matching the characteristics of the data type to the UI capabilities identified by the repository for one of the I / O user devices, and then forwards data of that data type to the network address of the selected one of the I / O user devices (530). A data source one of the I / O user devices sends (532) data streams to the user terminal emulation server over one or more sessions (536), and the user terminal emulation server 100 combines (538) the data streams into a combined data stream that is forwarded (540) to the called user terminal via network entity 150.

[0068] The user terminal emulation server may continuously monitor (534) the presence of the I / O user devices to determine when one or more of the I / O user devices are no longer proximate to the user so that they are no longer included as part of the combined UI provided during the ongoing communication session, and / or determine when one or more of the predicted soon-to-be-proximate I / O user devices become proximate to the user so that they may be included as part of the combined UI provided during the ongoing communication session. The user terminal emulation server may replace the UI capabilities of another I / O user device, e.g., an I / O user device predicted to become proximate to the user, into the set being used by the user for the ongoing communication session in response to a previous member of the set no longer being required to be present. As described in further detail below, the user terminal emulation server may signal an I / O user device predicted to become proximate to the user to prepare the I / O user device to use its I / O user interface in order to provide the user with the ongoing communication session.

[0069] Use Case 3, User Shared I / O User Device (Physical Resources, UI Capabilities) A third use case addresses a scenario in which two or more users are present in a physical area with several I / O user devices that have combined UI capabilities that are insufficient to meet the UI requirements needed to accommodate overlapping communication sessions without sharing between the two users. In this case, both users' identity entities, i.e., UserTags, are detected in the vicinity of several I / O user devices, thereby corresponding the IODHs to their respective user terminal emulation applications 110.

[0070] In the illustration of Figure 5, user terminal emulation application #1 is already handling an ongoing communication session in which some of the associated I / O user devices are assigned and in use by a first user corresponding to UserTag #1, which means that this example begins after block 430 of Figure 3. At that point, another second user with UserTag #2 enters the physical area.

[0071] In block 610, UserTag#2 comes into proximity, or is predicted to come into proximity, to at least one of the I / O user devices currently being utilized by user terminal emulation application #1. For example, at least one of the I / O user devices detects UserTag#2, or another I / O user device detects UserTag#2, and UserTag#2 is predicted to come into proximity to at least one of the I / O user devices, e.g., within a threshold time. In response, user terminal emulation application #2 is instantiated on user terminal emulation server 100 by the IODH.

[0072] In block 612, a request for a new communication session targeted to user terminal emulation application #2 is received. In block 614, the IODH considers the priority within the user terminal emulation application to be instantiated. The IODH compares the currently hosted (ongoing) user terminal emulation application #1 session offer with the offer of the new incoming request for a communication session to user terminal emulation application #2.

[0073] If no prioritization is identified, user terminal emulation applications are treated equally, such that available I / O user devices with their UI capabilities are assigned on a first-come, first-served basis. In contrast, if prioritization is identified, the IODH assigns priority to a particular I / O user device for the user terminal emulation application with the highest priority according to specified QoS / capability prioritization criteria, and operates such that if a particular UI capability is present in a particular type of I / O user device, some UI capabilities are operationally shared between a first user and a second user (e.g., a fairly large display screen may be divided in half and one half assigned to each of the first and second users).

[0074] In this scenario, user terminal emulation applications #1 and #2 are treated equally with no prioritization applying to all work within criteria block 611.

[0075] In block 616, the IODH evaluates the second user and the user terminal emulation application #2's request for capabilities (taking into account the prioritization, if any, established in the previous step). Regardless of any prioritization, if the user terminal emulation application #2 does not support the incoming request (e.g., there are no available I / O user devices or insufficient available I / O user devices determined (via query for I / O user devices 617) to meet the required UI capabilities), the IODH may act to negotiate UI capabilities with the network entity sending the session request for the second user. In contrast, if the UI capabilities provided by user device emulation application #2 for the requested communication session do not support the incoming request, as determined by user terminal emulation application #2 querying available I / O user devices, an ACK is communicated 618 to network entity 150.

[0076] If user terminal emulation application #2 is unable to service the incoming communication request when a priority is given to the use of some of the I / O user devices currently being used by user terminal emulation application #1, the operation of block 619 is performed, which preempts or causes sharing of one or more of the I / O user devices currently being used by user terminal emulation application #1, thereby allowing the IODH and / or user terminal emulation application #1 to renegotiate with network entity 150 the required UI capabilities of user terminal emulation application #1's communication session for the first user. User terminal emulation application #1 may receive a session ACK / NACK 620 generated by one or more of the preempted or shared I / O user devices with user terminal emulation application #2 indicating which UI capabilities are available for use by user terminal emulation application #1, and may accordingly terminate the current communication session if the required UI capabilities provided by the I / O user devices are no longer sufficient for use by user terminal emulation application #1 for the communication session.

[0077] In block 624, user terminal emulation application #2 queries the second user through a pre-selected one of the I / O user devices as to whether the requested communication session has been accepted. The pre-selected one of the I / O user devices may display a prompt query 626 for the second user to respond to, which is provided as an ACK / NACK 628 to user terminal emulation application #2. If the second user accepts the communication session (ACK), a communication session between the second user and the remote user terminal is established through user terminal emulation application #2 and network entity 150.

[0078] An I / O user device presence monitor may serve as a function of the IODH to monitor ongoing communication sessions (continuously, periodically, or in response to the occurrence of a predetermined event) to ensure that all of a set of I / O user devices remain in proximity and operationally available to users.

[0079] Message exchange between various system entities may be performed using the Session Initiation Protocol (SIP) in conjunction with the Session Description Protocol (SDP), with the possibility of some slight changes in the protocols and media formats currently supported. Using SIP / SDP may be convenient as the connection between I / O user devices, and user terminal emulation applications may be SIP sessions that can be launched similar to sessions between two VoIP clients.

[0080] More generally, the operations performed by the user terminal emulation server may include receiving from a network entity another communication request to establish another communication service between another user and another requesting user terminal. In response to the another communication request, the operations determine whether another set of I / O user devices from the I / O user devices identified by the repository are determined to be proximate to the location of the other user or are predicted to become proximate to the other user and are available for use for the other communication service. Based on the UI capabilities identified by the repository for the other set of I / O user devices, a further determination is made that the set of I / O user devices meet a combination capability criterion that they can be combined to provide a combined I / O UI for another user that interfaces with another user terminal emulation application to provide the other communication service. Based on a determination that there is no other set of I / O user devices that meets the combined capability criteria, that are usable by another communication service, and that are determined to be in proximity to, or are predicted to become in proximity to, the location of the other user, the operations responsively configure one of the I / O user devices in the set of I / O user devices that are in proximity to, or are predicted to become in proximity to, the other user but that are then in use by that user to operate to provide a shared UI for use by that user while the communication service is continuously provided to that user, and for further use by the other user while the other communication service is provided to that other user.

[0081] In one example, information intended for that user may be forwarded for display on one half of the screen of the display device, and information intended for the other user may be forwarded for display on the other half of the screen of the display device. In another example, a keyboard may be shared by two users who identify themselves via the keyboard (e.g., by typing a user ID, by scanning a UserTag, by biometric scanning, etc.) as they enter information, so that the server can selectively forward keyboard input to the correct one of the two user terminal emulation applications.

[0082] Predicting user proximity and preparing I / O user devices for communication services

[0013] Above, various operations were described for determining that an I / O user device has an I / O user interface that meets capability criteria that enable a user to use communication services via a network entity and to use the I / O user device for communication services. Now, further operations are described for predicting that the I / O user device will be in proximity to a user and, accordingly, signaling the I / O user device to prepare to use its I / O user interface to provide communication services to the user.

[0083] FIG. 10 shows a combined flowchart of operations and associated data flows between a UserTag, an I / O user device, and a user terminal emulation server 100 to predict when a user will be in proximity to the I / O user device and, in response, signal the I / O user device to prepare to use the I / O user interface to provide communication services to the user, according to some embodiments of the present disclosure.

[0084] 10 , a first I / O user device (IOD#1) detects (1000) a UserTag transmitted by a user and transmits (1002) IOD data obtained from the UserTag or determined based on detecting characteristics of the UserTag to the user terminal emulation server 100. The IOD data may include a user identifier, user preferences for one or more types of communication services, and / or user mobility information (e.g., location, movement speed, movement direction, etc.). The user preferences indicated by the IOD data may include one or more of whether the user prefers to use headset audio or speaker audio, the user's speaker volume preference, whether the user prefers to use or not use camera video when participating in an online conference, the user's document language preference, the user's keyboard layout setting preference, the user's video characteristic preference (e.g., minimum text size preference), etc.

[0085] 10 , the IOD data is received by the I / O user device handler (IODH) 212, which associates (1004) a first I / O user device (IOD#1) with the user terminal emulator 110 and sends (1006) a notification to the user terminal emulator 110 indicating that the first I / O user device (IOD#1) is currently proximate to the user and available to provide communication services to the user. The IODH 212 sends (1008) a prediction request including at least a portion of the IOD data, such as a user identifier and an indication that the first I / O user device (IOD#1) is currently proximate to the user.

[0086] In some embodiments, the prediction request is provided to the machine learning model 252, which predicts (1012) which other I / O user devices, if any, will be in proximity to the user based on the content of the received prediction request (also 1204 of FIG. 12 ). In one embodiment, the machine learning model 252 determines one or more I / O user devices that meet the criteria for having a probability that meets a probability threshold of coming within a threshold proximity range of the user within a threshold time. The machine learning model 252 provides (1014) a prediction response to the IOD H 212 indicating that, in the example of FIG. 10 , the second I / O user device (IOD #2) meets the criteria. The prediction response may identify a list of any I / O user devices that meet the determination by the machine learning model 252.

[0087] The IODH 212 determines (1016) whether to associate the second I / O user device (IOD#2) with the user terminal emulator 110 based on the predicted response and a determination (e.g., 1206 of FIG. 12) of whether the second I / O user device (IOD#2) has an I / O user interface that meets the capability criteria that enables the user to use communication services via the network entity 150. Once the IODH 212 determines (1016) to associate the second I / O user device (IOD#2) with the user terminal emulator 110, the IODH 212 may signal (1018) the second I / O user device (IOD#2) to prepare to use an I / O user interface to provide communication services to the user via the network entity 150 (e.g., 1208 of FIG. 12 ), and may further send (1020) a notification to the user terminal emulator 110 indicating that the second I / O user device (IOD#2) is available, or may soon become available, to provide communication services to the user. In this manner, the user terminal emulator 110 recognizes that the second I / O user device (IOD#2) can be used to launch a communication service with the user or to hand off an ongoing communication service involving the user, such as from using the first I / O user device (IOD#1) to instead using the second I / O user device (IOD#2). For example, audio and / or video streams that were being forwarded to a first I / O user device (IOD#1) may additionally or alternatively be forwarded to a second I / O user device (IOD#2) in response to the first I / O user device (IOD#1) ceasing to detect the presence of a UserTag, for example, for at least a threshold time, and / or in response to the second I / O user device (IOD#2) detecting the new presence of a UserTag.

[0088] In some embodiments, various I / O user devices may be configured to communicate directly with each other to perform functions on behalf of the user terminal emulation server 100. For example, the IOD 212 may signal (1018) (e.g., 1208 in FIG. 12 ) a first I / O user device (IOD#1) to trigger the first I / O user device (IOD#1) to then signal a second I / O user device (IOD#2) to prepare to use the I / O user interface of the second I / O user device (IOD#2) to provide a communication service to the user. Alternatively or additionally, the first and second I / O user devices may communicate between themselves to coordinate a handoff between them to provide an I / O user interface to the user for an ongoing communication service.

[0089] Predicting user proximity and preparing to forward communication service traffic to I / O user devices Further work, according to some embodiments, is now described for predicting when an I / O user device will be in proximity to a user and, accordingly, controlling the forwarding of traffic for ongoing communication services to an I / O user interface.

[0090] FIG. 11 illustrates a combined flowchart of the operations and related data flows between a UserTag, an I / O user device, and the user terminal emulation server 100, according to some embodiments of the present disclosure.

[0091] 11, a user associated with UserTag is using a first I / O user device (IOD#1) or group of IODs (collectively referred to as IOD#1) for a communication session 1100 established to carry traffic for an ongoing communication service provided via user terminal emulation server 100 and, for example, network entity 150 of FIG. 1. User terminal emulation server 100, and more specifically, IODDH 212, transmits 1102 a prediction request including at least a portion of the IOD data, such as a user identifier and an indication that the first I / O user device (IOD#1) is currently in proximity to the user.

[0092] In some embodiments, the prediction request is provided to the machine learning model 252, which predicts (1104) which other I / O user devices, if any, will be in proximity to the user based on the content of the received prediction request (also 1204 in FIG. 12 ). In one embodiment, the machine learning model 252 determines one or more I / O user devices that meet the criteria for having a probability that meets a probability threshold of coming within a threshold proximity range of the user within a threshold time. The machine learning model 252 provides (1106) a prediction response to the IOD H 212 indicating that, in the example of FIG. 11 , the second I / O user device (IOD #2) meets the criteria. The prediction response may identify a list of any I / O user devices that meet the determination by the machine learning model 252.

[0093] The IODH 212 determines (1108) whether to associate the second I / O user device (IOD #2) with the user terminal emulator 110 based on the expected response and a determination (e.g., 1206 of FIG. 12 ) of whether the second I / O user device (IOD #2) has an I / O user interface that meets the capability criteria that allows the user to use the ongoing communication service via the network entity 150. Once the IODH 212 determines (1108) to associate the second I / O user device (IOD #2) with the user terminal emulator 110, the IODH 212 can repeatedly signal the second I / O user device (IOD #2) to prepare to use its I / O user interface (1110a-1110n (e.g., 1208 of FIG. 12 ) to serve as a user interface for at least a portion of the traffic of the ongoing communication session 1100. The repeatedly signaling (1110a-1110n) can be performed by the IODH 212. 1110n) can serve to query the second I / O user device (IOD#2) whether a user has come into proximity, determine when a user has come into proximity and wake up the second I / O user device (IOD#2) to page the second I / O user device (IOD#2), and / or enable faster establishment of a communication session with the IOD H212 when a communication service handoff should be made to the second I / O user device (IOD#2).

[0094] The IODH 212 may further send (1112) a notification to the user terminal emulator 110 indicating that the second I / O user device (IOD#2) is available, or may soon become available, to provide the user with communication services for the communication session 1100. In this manner, the user terminal emulator 110 recognizes that the second I / O user device (IOD#2) can be used to perform a handoff of an ongoing communication service involving the user, such as transferring traffic of the communication service to the second I / O user device (IOD#2) and stopping the transfer of traffic of the first I / O user device (IOD#1). For example, audio and / or video streams that were being forwarded to a first I / O user device (IOD#1) may additionally or alternatively be forwarded to a second I / O user device (IOD#2) in response to the first I / O user device (IOD#1) ceasing to detect the presence of a UserTag, for example, for at least a threshold time, and / or in response to the second I / O user device (IOD#2) detecting the new presence of a UserTag.

[0095] 11 , the second I / O user device (IOD#2) detects the presence of the UserTag (1114) and receives IOD data, which may include a user ID and user preferences as described above. The second I / O user device (IOD#2) transmits the IOD data (e.g., user ID) to the IODDH 212 (1116), which can provide notification to the user terminal emulator 110 that the second I / O user device (IOD#2) is currently in proximity to the user (e.g., user ID) (1118). The user terminal emulator 110 responsively determines to transfer traffic (user data) of the ongoing communication service to the second I / O user device (IOD#2), for example, by establishing a communication session with the second I / O user device (IOD#2) (1120).

[0096] Signaling I / O user devices to prepare them for communication services In some embodiments, the act of signaling an I / O user device (e.g., a second I / O user device (IOD#2)) to prepare to use its I / O user interface to provide communication services to the user (e.g., 1208 in FIG. 12 , 1018 in FIG. 10 , 1110a-n in FIG. 11 ) includes sending a message (e.g., 1018 in FIG. 10 , 1110a-n in FIG. 11 ) configured to trigger the I / O user device to report to the user terminal emulation server 100 when the user comes into proximity.

[0097] As shown in the working scenario of FIG. 11, signaling (e.g., 1208 of FIG. 12, 1018 of FIG. 10, 1110a-n of FIG. 11) can include repeatedly sending messages (1110a-n) and adjusting the rate at which the messages are repeatedly sent based on at least one of the following: a determined probability that the I / O user device will be in proximity to the user, and a prediction of when the I / O user device will be in proximity to the user.

[0098] In some other embodiments, user terminal emulation server 100 initiates forwarding of traffic for the communication service to the I / O user device before the user is predicted to come into proximity of the I / O user device. In one exemplary embodiment, signaling an I / O user device to prepare to use an I / O user interface to provide a communication service to a user via network entity 150 (1208 of FIG. 12 , 1018 of FIG. 10 , 1110a-n of FIG. 11 ) includes initiating forwarding of communication traffic for the communication service to the I / O user device before the user is predicted to come into proximity of the I / O user device. The I / O user device is configured to do one of the following with respect to the communication traffic: initiate playback of the communication traffic via the I / O user interface (e.g., audio output via a speaker, video output via a video display, etc.), buffer the communication traffic for subsequent playback via the I / O user interface in response to the user coming into proximity of the I / O user device, and discard the communication traffic until the user comes into proximity of the I / O user device.

[0099] Preparing the I / O user device in response to the signaling may include establishing a communication session with an I / O user device connecting the I / O user device to user terminal emulation server 100 before the user is predicted to come into proximity of the I / O user device. In some embodiments, traffic for the communication session may not begin forwarding to the I / O user device until the user's proximity, e.g., userTag, is reported. In an exemplary embodiment, user terminal emulation server 100, e.g., user terminal emulator 110 and / or IOD#2, establishes a communication session with an I / O user device (e.g., a second I / O user device (IOD#2)) connecting the I / O user device to user terminal emulation server 100 before the user is predicted to come into proximity of the I / O user device. In response to determining that the user has come into proximity to the I / O user device, the user terminal emulation server 100 starts forwarding communication traffic of the communication service via a communication session established with the I / O user device (e.g., a second I / O user device (IOD#2)) and stops forwarding communication traffic of the communication service via another communication session established with an I / O user device (e.g., a first I / O user device (IOD#1)) that was previously in proximity but is no longer in proximity to the user.

[0100] The signaling to prepare the I / O user device may include configuration and / or startup information used by the I / O user device to become operationally ready to use its I / O user interface to provide a communication service to a user. For example, in one embodiment, the signaling (1208 of FIG. 12 , 1018 of FIG. 10 , 1110a-n of FIG. 11 ) includes communicating (1018) device configuration data to the I / O user device that configures the I / O user device to use the I / O user interface to provide the first communication service. In a further embodiment, the device configuration data communicated to the I / O user device is adapted to configure at least one of the following operations of the I / O user device: 1) the relative duration of the sleep cycle and wake cycle of the I / O user device, where during the sleep cycle the I / O user device is unable to provide UI capabilities to the user (e.g., the user interface is not operational for use by the user) and during the wake cycle the I / O user device is able to provide UI capabilities to the user (e.g., the user interface is operational for use by the user); 2) Paging procedures for I / O user devices; 3) the frame rate of video streamed from the camera of the I / O user device to the network entity 150 when the first communication service is provided via the I / O user device; 4) the resolution of the video streamed from the camera of the I / O user device to the network entity 150 when the first communication service is provided via the I / O user device; 5) a coding format of video streamed from a camera of the I / O user device to the network entity 150 when the first communication service is provided via the I / O user device; 6) a coding format for audio streamed from a microphone of the I / O user device to the network entity 150 when the first communication service is provided via the I / O user device; 7) the frame rate of the video displayed by the display screen of the I / O user device towards the network entity 150 when the video stream is received from the network entity 150 for the first communication service; 8) the resolution of the video displayed by the display screen of the I / O user device when the video stream is received from the network entity 150 for the first communication service; and 9) A user input interface key assignment used to convert user input via the user input interface into user input data sent towards the network entity 150 when the first communication service is provided via the I / O user device.

[0101] Use machine learning models to predict user proximity to I / O user devices We now describe various methods that can be used to train a machine learning model 252 to predict a user's proximity to one or more I / O user devices.

[0102] In some embodiments, machine learning models 252 include a decentralized federated learning architecture with hierarchical correspondence between layers of machine learning models. Layers of local machine learning models are processed and trained to track information indicative of a user's habits for using communication services (e.g., which I / O user devices a user typically uses as a function of various types of communication services, as a function of time of day and / or day of the week, as a function of how many people and / or which specific people participate in the communication service). As local machine learning models are updated based on observed user activity, the model parameters are also sent to higher-level machine learning models, which may reside within IODH 212, trained with knowledge about the relative location of the I / O user devices and associated local machine learning models that monitor I / O user device usage more locally. Each model may be configured as a deep neural network (DNN) or a convolutional neural network (CNN).

[0103] The division of responsibilities between layers in the model hierarchy can be configured according to geographic constraints; for example, a "sub-IODH" may have access to process information only for a city-constrained list of I / O user device locations and be trained based on user usage of I / O user devices within that city. That city-based model can then be directly connected to a higher-level "municipal model" encompassing multiple cities, or to a "country model" encompassing multiple municipalities, and so on. The architectural layout of the hierarchical machine learning model may be manually initiated by one or more model owners and / or may be dynamically self-configured depending on the number of users, the number of I / O user devices, observed patterns of movement between I / O user devices, etc. Cities, municipalities, etc. are non-limiting examples; any grouping of I / O user devices to machine learning models can be used. Grouping may be based on data rates (e.g., the number of I / O user devices communicating with the IODH 212), the number of users, and / or local / regional regulatory boundaries.

[0104] The mapping between I / O user devices and individual machine learning models may be remapped over time to reflect changes in the location of the I / O user devices, such as if some of the I / O user devices are not geographically fixed but instead mobile.

[0105] The repository database 120 (e.g., FIG. 1) containing the locations and UI capabilities of I / O user devices can be organized into a data structure similar to a lookup table that is continually updated with new locations of I / O user devices. Alternatively, an improved approach can use a network model database or hierarchical model that is built by the IODH 212 as new I / O user devices are added. This makes the repository database 120 better able to handle multiple simultaneous accesses, since the search starts traversing data points around it (geographically) and then searches from there until the search criteria is met.

[0106] The machine learning model 252 can be trained based on a time series of I / O user devices that have been observed in the past to become successively closer to a user, for example, a first I / O user device near a doorway detects proximity to a user, then a second I / O user device further down the hallway detects proximity to some or all of those users, then a third I / O user device further down the hallway detects proximity to some or all of those users, then a fourth I / O user device further down the hallway in the main conference room detects proximity to some or all of those users, etc. In one embodiment, the act of predicting that an I / O user device will come into proximity to a user (1204, 1008, 1012, 1102, 1104) includes processing information indicating the user's current proximity to another I / O user device via a machine learning model 252 trained based on a time series of I / O user devices that have previously been observed to come into proximity to the user (1012, 1104), and predicting that an I / O user device will come into proximity to the user based on the output of the machine learning model 252 from processing the information (1012, 1016, 1104, 1108).

[0107] The rate at which messages are repeatedly sent in the signaling (1208, 1018, 1110a-n) to prepare the I / O user device can be adjusted based on the output of the machine learning model 252 indicating the probability that the user will be in proximity to the I / O user device. In one embodiment, the operation repeatedly sends a message configured to trigger the I / O user device to prepare the I / O user device for use with the I / O user interface to provide the user with a first communication service (1110a-1110n). The operation processes information indicating the user's current proximity to another I / O user device via the machine learning model 252 trained based on a time series of I / O user devices identified in the repository that have been previously observed to be in proximity to the user to output an indicated probability that the user will be in proximity to the I / O user device (1012, 1104). The operation then adjusts the rate at which the messages are repeatedly sent based on the indicated probability.

[0108] The machine learning model 252 can be trained based on historical observations of which users have been in proximity to which I / O user devices as a function of time and date. In one embodiment, predicting that an I / O user device will come into proximity to a user includes processing a time and date (where “date” can be a day of the week, a date, or a month and a day) through the machine learning model 252 trained based on historically observed proximity between the identified user and the identified I / O user device at the identified time and date (1012, 1104) to output a probability prediction of which of the identified users is predicted to come into proximity to the identified I / O user device. The operation then predicts whether an I / O user device will come into proximity to the user based on the user's identity and the probability prediction output by the machine learning model 252 (1012, 1016, 1104, 1108).

[0109] The machine learning model 252 may be trained based on the geographic locations of the I / O user devices, so that the user's current geographic location can generate a prediction of which I / O user devices, if any, are likely to be proximate to the user. In one embodiment, predicting that an I / O user device will be proximate to the user includes processing (1012, 1104) the user's current geographic location through the machine learning model 252 trained based on the I / O user device's geographic location. The operation then predicts whether an I / O user device will be proximate to the user based on the output of the machine learning model 252 from processing the user's current geographic location (1012, 1016, 1104, 1108).

[0110] The machine learning model 252 can be trained based on the capabilities of the I / O user device required to fulfill a specified type of communication service. In one embodiment, determining that the I / O user interface of the I / O user device meets the capability criteria includes processing (1012, 1104) the user interface capabilities of the I / O user interface of the I / O user device and the indication of a first communication service among the communication services through a machine learning model 252 trained based on the user interface capabilities required to fulfill various types of communication services. The operation then determines whether the capability criteria are met based on the output of the machine learning model 252 from processing the user interface capabilities of the I / O user interface and the indication of the first communication service among the communication services (1012, 1016, 1104, 1108).

[0111] The machine learning model 252 can be trained based on a set of I / O user devices previously selected by the user when using the communication service. In one embodiment, operations process the user's predicted next location through the machine learning model 252, trained based on a previously observed set of I / O user devices selected for use by the user that were proximate to the next location when using the communication service (1204, 1012, 1104), to output a candidate set of I / O user devices. The operations then select (1016, 1108) from among the candidate set of I / O user devices a first set of I / O user devices having a set of I / O user interfaces that meet capability criteria that will enable the user to use a first one of the communication services. Before the user is predicted to be proximate to the first set of I / O user devices, operations signal the first set of I / O user devices via the network entity 150 to prepare them to use the set of I / O user interfaces to provide the first communication service to the user (1208, 1018, 1110a-n).

[0112] In some embodiments, input data is processed through machine learning model 252, which returns a set of I / O user devices that are predicted to be in proximity to one or more users at a defined frequency. Enhanced training of machine learning model 252 over time can include feedback indicating which of the I / O user devices listed in the set were selected and / or not selected by IODH 212 and / or the user for use as an interface for one or more communication services. Machine learning model parameters updated through training can be provided to one or more higher-level machine learning models in a hierarchical set of machine learning models as described above (e.g., a small geographic area layer of machine learning models, a connected upper layer of machine learning models for larger geographic areas, etc.).

[0113] Select a set of I / O user devices to use with the communication service As described above, the user terminal emulation server 100 can select, from among the candidate set of I / O user devices, a set of I / O user devices having a set of I / O user interfaces that meets a capability criterion that enables the user to use one of the communication services. Before the user is predicted to be in proximity to the set of I / O user devices, the user terminal emulation server 100 can signal the set of I / O user devices to prepare to use the set of I / O user interfaces to provide the communication service to the user via the network entity 150.

[0114] An example of a set of I / O user devices includes a large screen TV lacking a microphone operatively coupled to a user terminal emulator 110 along with a nearby smart speaker having a microphone operable to record user commands. Together, the set of I / O user devices fulfills the requirements of a single videoconferencing communication device. Another example includes a set of TV screens spaced along a building hallway, where the set of TV screens are sequentially prepared for use and then used to provide communication services to a user as the user walks along the building hallway, becoming proximate to each of the TV screens one at a time.

[0115] Which I / O user devices are selected for inclusion in the set may also be based on how many people and / or which particular people are participating in the communication service, such as to prepare a headset speaker for use by a single local user participant or a speaker for use by multiple local user participants. The selection may also be influenced by the time and / or date affecting the known availability of particular ones of the I / O user devices for use in providing the communication service.

[0116] A wide range of sensors may be used that are selectively included as part of the set of I / O user devices that are provisioned for communication services. For example, LED lights and environmental sensors (such as temperature or ventilation) may also be selected for inclusion in the set to allow, for example, adjustment of room lighting and / or temperature in preparation for a user participating in a communication service from inside the room.

[0117] Cloud Implementation Some or all of the operations described above as being performed by the user terminal emulation server 100 or the I / O user device 130 may instead be performed by other nodes and / or by another node that is part of a cloud computing resource. For example, the operations may be performed as a network function closer to the edge, such as in a cloud server or resource of a telecommunications network operator, e.g., in a CloudRAN or core network, and / or may be performed by a cloud server or resource of a media provider, e.g., the iTunes service provider or the Spotify service provider.

[0118] Examples of I / O user devices and user terminal emulation servers FIG. 8 is a block diagram of components of an I / O user device 130 configured to operate according to some embodiments. The I / O user device 130 may include a wired / wireless network interface circuit 902, a near-field communication circuit 920, at least one processor circuit 900 (processor), and at least one memory device circuit 910 (memory). The processor 900 is communicatively coupled to the other components. The memory 910 stores program code 912 that is executed by the processor 900 to perform the tasks disclosed herein. The processor 900 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 900 is configured to execute the program code 912 in the memory 910, described below as a computer-readable medium, to perform some or all of the tasks and / or methods for one or more of the embodiments disclosed herein with respect to a mobile electronic device. The I / O user devices 130 may include one or more UI devices, including, but not limited to, a microphone 940 , a speaker 950 , a camera 930 , a display device 960 , and a user input interface 970 .

[0119] FIG. 9 is a block diagram of components of a user terminal emulation server 100 configured to operate in accordance with some embodiments. The user terminal emulation server 100 may include a wired / wireless network interface circuit 1020, a repository 120 (e.g., listed I / O user devices, I / O user device UI capabilities, known proximity to user identities, etc.), a display device 1030, a user input interface 1040 (e.g., a keyboard or touch-sensitive display), at least one processor circuit 1000 (processor), and at least one memory circuit 1010 (memory). The processor 1000 is connected to communicate with the other components. The memory 1010 stores a user terminal emulation application 1012 that is executed by the processor 1000 to perform the tasks described in this disclosure. The memory 1010 also stores a proximity prediction and I / O user device (IOD) preparation module 250. In some embodiments, the module 250 includes a machine learning model 252. The processor 1000 may include one or more data processing circuits (e.g., microprocessors and / or digital signal processors), which may be collocated or distributed across one or more data networks. The processor 1000 is configured to execute computer program instructions in memory 1010, described below as a computer-readable medium, to perform some or all of the tasks and / or methods for one or more of the embodiments disclosed herein for mobile electronic devices. Abbreviation 3GPP 3rd Generation Partnership Project App An application, i.e. a program CNN Convolutional Neural Network DNN Deep Neural Network DRX Intermittent Reception eNB Evolved Node B (also known as RBS, Radio Base Station) GNSS Global Navigation Satellite System GPS Global Positioning System GW Gateway ICMP Internet Control Message Protocol IOD Input / Output Device IODH Input / output device handler ITU International Telecommunication Union RRC Radio Resource Control RTP Real Time Protocol RTCP Real-Time Control Protocol NTP Network Time Protocol SDP Session Description Protocol UE User Equipment

[0120] Further Definitions and Embodiments In the foregoing description of various embodiments of the inventive concept, it should be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the inventive concept. 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 the inventive concept belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted to have a meaning consistent with their meaning in the context of this specification and related art, and not in the idealized or overly formal sense so expressly defined herein.

[0121] When an element is referred to as being "connected," "coupled," "responsive," or variations thereof, to another element, the element may 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 variations thereof, to another element, there are no intervening elements present. Like numbers refer to like elements throughout. Furthermore, as used herein, "coupled," "connected," "responsive," or variations thereof may include wirelessly coupled, wirelessly connected, or wirelessly responsive. As used herein, the singular forms "a," "an," and "the" are intended to include the plural unless the context clearly dictates otherwise. For the sake of brevity and / or clarity, well-known functions or structures may not be described in detail. The term "and / or" includes any combination of one or more of the corresponding listed terms.

[0122] Although terms such as first, second, third, etc. may be used herein to describe various elements / operations, it will be understood that these elements / operations are not limited by these terms. These terms are used only to distinguish one element / operation from another. Thus, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments without departing from the teachings of the inventive concept. The same reference numbers or characters may refer to the same or similar elements throughout this specification.

[0123] As used herein, the terms "comprise," "comprising," "comprises," "include," "including," "includes," "have," "has," "having," or variations thereof, are open-ended and refer to the inclusion of one or more stated features, integers, elements, steps, components, or functions, but do not exclude 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 "eg," derived from the Latin phrase "exempli gratia," may be used to introduce or specifically name one or more general examples of the aforementioned items, without limiting such items. The common abbreviation "ie," derived from the Latin phrase "id est," may be used to specifically name a particular item from a more general statement.

[0124] Exemplary 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 should be understood that blocks of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by computer program instructions performed by one or more computer circuits. These computer program instructions can be provided to processor circuits of general-purpose computer circuits, special-purpose computer circuits, and / or other programmable data processing circuits to create a machine whereby the instructions executed 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 circuits to implement the functions / acts specified in one or more blocks of the block diagrams and / or flowcharts, and thereby create means (functions) and / or structures for implementing the functions / acts specified in the block diagrams and / or flowchart blocks.

[0125] The computer program instructions may also be stored on a tangible computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, whereby the instructions stored on the computer-readable medium produce an article of manufacture comprising instructions that implement the functions / acts specified in one or more blocks of the block diagrams and / or flowcharts. Thus, embodiments of the inventive concept may be embodied in the form of hardware and / or software (including firmware, resident software, microcode, etc.) running on a processor, such as a digital signal processor, which may be collectively referred to as a "circuit," "module," or variations thereof.

[0126] It should also be noted that in some alternative implementations, the functions / acts noted in the blocks may occur in an order other than that noted in the flowcharts. For example, depending on the functionality / acts involved, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order. Furthermore, the functionality of a given block in the flowcharts and / or block diagrams may be separated into multiple blocks, and / or the functionality of two or more blocks in the flowcharts and / or block diagrams may be at least partially integrated. Finally, other blocks may be added / inserted between the illustrated blocks, and / or blocks / acts may be omitted without departing from the scope of the inventive concepts. Furthermore, while some of the figures include arrows on communication paths to indicate a primary direction of communication, it should be understood that communication may occur in the opposite direction to that of the illustrated arrows.

[0127] Numerous variations and modifications can be made to the embodiments without substantially departing from the principles of the inventive concept. All such variations and modifications are intended to be included herein within the scope of the inventive concept. Accordingly, the above disclosed subject matter should be considered illustrative and not limiting, and the accompanying examples of embodiments are intended to encompass all such modifications, extensions, and other embodiments that fall within the spirit and scope of the inventive concept. Thereby, to the maximum extent permitted by law, the scope of the inventive concept should be determined by the broadest permissible interpretation of this disclosure, including the following examples of embodiments and their equivalents, and is not limited or restricted by the detailed description set forth above.

Claims

1. A method for providing communication services to a user via one or more input and / or output (I / O) user devices by a user terminal emulation server, comprising: registering (1202) said user with a network entity providing said communication services; predicting (1204, 1008, 1012, 1102, 1104) that an I / O user device will come into proximity with said user; based on the prediction that the I / O user device will be in proximity to the user; determining (1206, 1016, 1108) that the I / O user device has an I / O user interface that meets capability criteria that allows the user to use a first one of the communication services; signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity (150) based on satisfying the capability criteria and before the user is predicted to be in proximity to the I / O user device; Including, the step (1208, 1018, 1110a-n) of signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity (150), sending a message (1018, 1110a-n) configured to trigger said I / O user device to report to a user terminal emulation server (100) when said user comes into proximity; A method comprising:

2. repeatedly transmitting said message (1110a-n); adjusting the rate at which the message is repeatedly transmitted based on at least one of a determined probability that the I / O user device will be proximate to the user and a prediction of when the I / O user device will be proximate to the user; The method of claim 1 further comprising:

3. the step (1208, 1018, 1110a-n) of signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity (150), Initiating forwarding of communication traffic of the first communication service to the I / O user device before the user is predicted to come into proximity with the I / O user device.

3. The method of claim 1, wherein the I / O user device uses the communication traffic to do one of the following: initiate playback of the communication traffic via the I / O user interface; buffer the communication traffic for subsequent playback via the I / O user interface in response to the user coming into proximity of the I / O user device; and discard the communication traffic until the user comes into proximity of the I / O user device.

4. establishing a communication session with the I / O user device, connecting the I / O user device to a user terminal emulation server (100) before the user is predicted to be in proximity to the I / O user device; in response to determining that the user has come into proximity to the I / O user device, starting forwarding communication traffic of the first communication service over the communication session established with the I / O user device, and stopping forwarding the communication traffic of the first communication service over another communication session established with an I / O user device that was previously in proximity but is no longer in proximity to the user; The method of claim 1 , further comprising:

5. the step (1208, 1018, 1110a-n) of signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity (150), communicating to the I / O user device device configuration data that configures the I / O user device to provide the first communication service using the I / O user interface (1018); 5. The method of claim 1, comprising:

6. The device configuration data communicated to the I / O user device is used by the I / O user device to: the relative duration of a sleep cycle and a wake cycle, during which the I / O user device is unable to provide user interface (UI) capabilities to the user, and during which the I / O user device is able to provide UI capabilities to the user; a paging procedure for the I / O user device; a frame rate of video streamed from a camera of the I / O user device to the network entity (150) when the first communication service is provided via the I / O user device; a resolution of video streamed from the camera of the I / O user device to the network entity (150) when the first communication service is provided via the I / O user device; a coding format of video streamed from the camera of the I / O user device to the network entity (150) when the first communication service is provided via the I / O user device; a coding format for audio streamed from a microphone of the I / O user device to the network entity (150) when the first communication service is provided via the I / O user device; a frame rate of a video displayed by a display screen of the I / O user device towards the network entity (150) when a video stream is received from the network entity (150) for the first communication service; a video resolution displayed by a display screen of the I / O user device when a video stream is received from the network entity (150) for the first communication service; and a user input interface key assignment used to convert user input via a user input interface into user input data transmitted to the network entity (150) when the first communication service is provided via the I / O user device; a step of setting at least one of The method of claim 5 further comprising:

7. 12. The steps of predicting when the I / O user device will be in proximity to the user (1204, 1008, 1012, 1102, 1104), processing (1012, 1104) information indicative of the user's current proximity to another I / O user device via a machine learning model (252) trained based on a time series of I / O user devices that have been previously observed to be in proximity to the user; predicting (1012, 1016, 1104, 1108) that the I / O user device will be in proximity to the user based on the output of the machine learning model (252) by processing the information; 7. The method of claim 1, comprising:

8. training the machine learning model (252) based on the time series of I / O user devices that have been previously observed to be in proximity to a user; The method of claim 7 further comprising:

9. repeatedly sending a message (1110a-1110n) configured to trigger the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user; processing information indicating the user's current proximity to another I / O user device via a machine learning model (252) trained based on a time series of the I / O user devices identified in the repository that have been previously observed to come into proximity to the user, to output an indication of a probability that the user will come into proximity to the I / O user device (1012, 1104); adjusting a rate at which the message is repeatedly transmitted based on the indication probability; 9. The method of claim 1, further comprising:

10. The step of predicting when the I / O user device will be in proximity to the user comprises: processing the time and date through a machine learning model (252) trained based on previously observed proximity between the identified users and the identified I / O user device at the identified time and date to output a probability prediction of which of the identified users are predicted to be in proximity to the identified I / O user device (1012, 1104); predicting (1012, 1016, 1104, 1108) whether the I / O user device will be in proximity to the user based on the user's identity and the probability prediction output by the machine learning model (252); 10. The method of claim 1, comprising:

11. the step of predicting that the I / O user device will be in proximity to the user comprises: processing (1012, 1104) the user's current geographic location through a machine learning model (252) trained based on the geographic location of the I / O user device; predicting (1012, 1016, 1104, 1108) whether the I / O user device will be in proximity to the user based on the output of the machine learning model (252) by processing the user's current geographic location; 11. The method of claim 1, comprising:

12. determining that the I / O user interface of the I / O user device meets the capability criteria; processing (1012, 1104) an indication of user interface capabilities of the I / O user interface of the I / O user device and the first of the communication services via a machine learning model (252) trained based on user interface capabilities required to satisfy different types of communication services; determining whether the capability criteria are met based on an output of the machine learning model (252) by processing the user interface capabilities of the I / O user interface and the indication of the first communication service among the communication services (1012, 1016, 1104, 1108); 12. The method of any one of claims 1 to 11, comprising:

13. processing the user's predicted next location through a machine learning model (252) trained based on a previously observed set of I / O user devices that were selected for use by the user in proximity to the next location when using the communication service to output a candidate set of I / O user devices (1204, 1012, 1104); selecting (1016, 1108) from the candidate set of I / O user devices a first set of I / O user devices having a set of I / O user interfaces that meets the capability criteria that enables the user to use the first one of the communication services; signaling the first set of I / O user devices to prepare to use the set of I / O user interfaces to provide the first communication service to the user via the network entity (150) before the user is predicted to be in proximity to the first set of I / O user devices; 13. The method of any one of claims 1 to 12, further comprising:

14. A user terminal emulation server (100) for providing communication services to a user via one or more input and / or output (I / O) user devices, comprising: registering said user with a network entity (150) that provides said communication service; predicting that an I / O user device will be in proximity to said user; based on the prediction that the I / O user device will be in proximity to the user; determining that the I / O user device has an I / O user interface that meets capability criteria that allows the user to use a first one of the communication services; signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity (150) based on satisfying the capability criteria and before the user is predicted to be in proximity to the I / O user device; It is set as follows: signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity (150); sending a message configured to trigger said I / O user device to report to a user terminal emulation server (100) when said user comes into proximity; A user terminal emulation server (100) including:

15. A user terminal emulation server (100) according to claim 14, configured to carry out the method according to any one of claims 2 to 13.

16. 1. A computer program comprising program instructions executable by at least one processor of a user terminal emulation server for providing communication services to users via one or more input and / or output (I / O) user devices, the computer program comprising: When the program instructions are executed, the user terminal emulation server: registering the user with a network entity that provides the communication service; predicting when an I / O user device will be in proximity to said user; based on the prediction that the I / O user device will be in proximity to the user; determining that the I / O user device has an I / O user interface that meets capability criteria that enables the user to use a first one of the communication services; and signaling the I / O user device to prepare to use the I / O user interface to provide the first communication service to the user via the network entity based on satisfying the capability criteria and before the user is predicted to come into proximity of the I / O user device; Performing a process including signaling the I / O user device to prepare to use the I / O user interface to provide the first communications service to the user via the network entity; sending a message configured to trigger said I / O user device to report to a user terminal emulation server (100) when said user comes into proximity; a computer program comprising:

17. 17. A computer program product as claimed in claim 16, wherein the user terminal emulation server executes the method of any one of claims 2 to 13.

Images