Handling of incoming communication requests to an XR device

Abstract

There is provided techniques for handling an incoming communication request to an XR device. A method is performed by a controller. The method comprises obtaining an activity level pattern of an XR environment. The XR environment is rendered by the XR device. The method comprises predicting, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment. The method comprises handling the incoming communication request to the XR device. The incoming communication request is external to the XR environment. The incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

Description

[0001] HANDLING OF INCOMING COMMUNICATION REQUESTS TO AN XR DEVICE

[0002] TECHNICAL FIELD

[0003] Embodiments presented herein relate to a method, a controller, a computer program, and a computer program product for handling incoming communication requests to an extended reality device.

[0004] BACKGROUND

[0005] In the rapidly evolving landscape of Extended Reality (XR)— encompassing Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR)— devices are increasingly being integrated into both personal and professional settings. These technologies offer immersive experiences that blend digital content with the physical world, enabling a wide range of applications from entertainment and education to complex surgical procedures and remote work collaboration. However, the immersive nature of XR also presents unique challenges, particularly in terms of communication with device users without disrupting their experience.

[0006] One primary issue stems from the deep level of immersion that XR technologies provide. When users engage with XR devices, they are often fully absorbed in the digital environment, with sensory inputs from the real world either significantly diminished or entirely replaced by the virtual context. This immersion is a doubleedged sword: while it is the source of the powerful experiences that XR can offer, it also isolates the user from the external environment to a degree that can be problematic. This isolation becomes particularly pronounced in situations where external communication is necessary— whether for safety, coordination in professional settings, or personal reasons.

[0007] Traditional methods of communication, such as auditory cues or vibrations, can be jarring and disrupt the immersive experience, momentarily breaking the spell of the digital world and reminding the user of the artificial nature of their experience. Moreover, these interruptions can occur at critical moments, potentially compromising the user’s performance in a task or the enjoyment of an experience. For instance, in a professional training simulation, an untimely interruption could detract from the learning outcome. Similarly, in a gaming context, immersion is key to enjoyment and engagement, and interruptions can significantly detract from the user experience.

[0008] The issue is compounded by the lack of standardized protocols or interfaces for integrating real-world communications into the XR environment in a way that feels natural and minimally invasive.

[0009] Existing technology for addressing the above issues often adopt a one-size-fits-all approach, failing to account for the diverse contexts in which XR technologies are used or the varying degrees of immersion that different experiences provide. This gap highlights the need for a more nuanced approach to designing communication mechanisms that can adapt to the user’s context and the content of the XR experience.

[0010] Given these challenges, there is a need for effective communication with users of XR devices without compromising their immersive experience.

[0011] SUMMARY

[0012] An object of embodiments herein is to mitigate, or reduce, the above identified issues and challenges.

[0013] In this respect, unwanted interruptions might cause unnecessary pauses, or interruptions, in the XR environment engine. For this purpose, since the XR environment engine is not informed in advance regarding when any interruption will occur, the XR environment engine needs to constantly buffer large amounts of data, such that unwanted interruptions can be handled seamlessly, regardless of when in time they occur. In turn, this provides high demands for data buffering at the XR environment engine.

[0014] A particular object is therefore handling of incoming communication requests to an XR device that reduces the need of the XR environment engine to constantly buffer data.

[0015] Further, creating a totally immersive XR experience that prevents the user from being disturbed by outside phone calls, etc. requires the user to be exposed to high volume levels, etc. This could potentially hurt the user, as well as requiring a high power level at the XR device worn by the user. A particular object is therefore handling of incoming communication requests to an XR device that reduces the power levels needed in the XR device.

[0016] According to a first aspect there is presented a method for handling an incoming communication request to an XR device. The method is performed by a controller. The method comprises obtaining an activity level pattern of an XR environment. The XR environment is rendered by the XR device. The method comprises predicting, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment. The method comprises handling the incoming communication request to the XR device. The incoming communication request is external to the XR environment. The incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

[0017] According to a second aspect there is presented a controller for handling incoming communication requests to an XR device. The controller comprises processing circuitry. The processing circuitry is configured to cause the controller to obtain an activity level pattern of an XR environment. The XR environment is rendered by the XR device. The processing circuitry is configured to cause the controller to predict, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment. The processing circuitry is configured to cause the controller to handle the incoming communication request to the XR device. The incoming communication request is external to the XR environment. The incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

[0018] According to a third aspect there is presented a controller for handling incoming communication requests to an XR device. The controller comprises an obtain module configured to obtain an activity level pattern of an XR environment. The XR environment is rendered by the XR device. The controller comprises a predict module configured to predict, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment. The controller comprises a control module configured to handle the incoming communication request to the XR device. The incoming communication request is external to the XR environment. The incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

[0019] According to a fourth aspect there is presented a computer program for handling incoming communication requests to an XR device. The computer program comprises computer code which, when run on processing circuitry of a controller, causes the controller to perform actions. One action comprises the controller to obtain an activity level pattern of an XR environment. The XR environment is rendered by the XR device. One action comprises the controller to predict, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment. One action comprises the controller to handle the incoming communication request to the XR device. The incoming communication request is external to the XR environment. The incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

[0020] According to a fifth aspect there is presented a computer program product comprising a computer program according to the fourth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

[0021] Advantageously, these aspects provide efficient handling of incoming communication requests to an XR device.

[0022] Advantageously, according to these aspects, enable incoming communication requests to be handled in ways that do not impact the immersive XR experience of the user.

[0023] Advantageously, these aspects cause not all incoming communication requests to the XR device to be accepted. Hence, the probability of unwanted interruptions is reduced, thereby lowering the demands for data to be constantly buffered. In turn, these aspects therefore enable the need of the XR environment engine to constantly buffer data to be reduced. Further, since not all incoming communication requests to the XR device will be accepted, the probability of the user being disturbed is reduced. In turn, these aspects therefore enable the power levels needed in the XR device to be reduced.

[0024] Advantageously, these aspects enable indicators to be available of when in time communication would be available. In turn, this could limit the amount of times the XR device is contacted, thus possibly reducing the traffic over the air.

[0025] Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

[0026] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

[0027] BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

[0029] Fig. 1 is a schematic diagram illustrating a system according to embodiments;

[0030] Fig. 2 is a flowchart of methods according to embodiments;

[0031] Fig. 3 schematically illustrates an activity level pattern according to an embodiment;

[0032] Fig. 4 is a schematic diagram showing structural units of a controller according to an embodiment;

[0033] Fig. 5 is a schematic diagram showing functional modules of a controller according to an embodiment; and

[0034] Fig. 6 shows one example of a computer program product comprising computer readable storage medium according to an embodiment. DETAILED DESCRIPTION

[0035] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

[0036] Fig. i is a schematic diagram illustrating a system too where embodiments presented herein can be applied. The system too comprises an XR device no. The XR device no is assumed to be worn by a user. In some examples, the XR device no is an eyewear, such as a head-mounted display (HMD) device. In some examples, the XR device no is, or is part of, or comprises, a headphone, such as noise cancelling (reducing) headphones. The XR device no is operatively connected to an XR environment engine 120, for example placed in an external device (such as a server or computer) as in Fig. 1 or in the XR device no itself, or partly implemented in the external device and partly in the XR device 110. The XR environment engine 120 generates an XR environment (in terms of audio and / or video content) that is rendered, or played out, by the XR device 110. The user wearing the XR device 110 is thereby enabled to interact with the XR environment. It is assumed that a user of a communication device 130 intends to communicate with the user of the XR device no. The communication device 130 can therefore hereinafter represent a device from which an incoming communication request to the XR device no is originating. In some aspects it is assumed that the communication device 130 is disconnected from the XR environment, and hence the user of the communication device 130 is not enabled to interact with the user of the XR device 110 directly via the XR environment. However, in other aspects the communication device 130 is connected to the XR environment (and thus is another XR device), and hence the user of the communication device 130 is enabled to interact with the user of the XR device 110 directly via the XR environment. In any case, as will be disclosed in further detail below, communication between the XR device no and the communication device 130 is handled by a controller 150. Although illustrated as a separate entity in Fig. 1, in some examples, the controller 150 is part of the XR device 110. In other examples the controller 150 is part of the smart home controller 170. In this respect, the smart home controller 170 is a centralized device or software platform configured to manage and control various interconnected smart devices within a home. These devices can include lighting, thermostats, security cameras, entertainment systems (such as the XR environment engine 120 and / or the XR device 110), and more.

[0037] As will be further disclosed below, in some embodiments, sensor data is utilized when determining the activity level pattern of the XR environment. The sensor data is collected by at least one sensor 160. There could be different types of sensor data, such as eye-tracking data, pupil dilation data, eye-blinking data, pulse data, breathing data, skin conductance data, electroencephalogram (EEG) data, muscle tension, etc., depending on the type of sensor 160.

[0038] Communication by the different devices in Fig. 1 is facilitated by a communication network, that could be either wired, wireless, or partly wired and partly wireless. In Fig. 1, the communication network is represented by the communication link 140. It is therefore assumed that the different devices in Fig. 1 support one or more corresponding protocols.

[0039] As noted above, there is a need for effective communication with users of XR devices 110 without compromising their immersive experience.

[0040] The herein disclosed embodiments aim to address these challenges by introducing a novel approach to communication in XR environments. By leveraging context-aware technologies and adaptive interfaces, the herein disclosed embodiments seek to bridge the gap between the immersive digital world and the need for connectivity with the external environment, ensuring that the users of the XR devices can remain fully engaged in their experiences whilst still being accessible to the outside world.

[0041] The embodiments disclosed herein in particular relate to techniques for handling incoming communication requests to an XR device 110. In order to obtain such techniques, there is provided a controller 150, a method performed by the controller 150, a computer program product comprising code, for example in the form of a computer program, that when run on a controller 150, causes the controller 150 to perform the method.

[0042] One aspect involves to seamlessly integrate real-world communications into the XR environment, allowing messages or alerts to be conveyed in a manner that is contextually appropriate and minimally disruptive. This would not only enhance the usability and safety of XR technologies but also expand their potential applications by making them more adaptable to multi-tasking and collaborative settings. In general terms, by measuring the activity level of the XR environment and predicting pause events, it is possible to handle incoming communication requests to the XR device differently. Different examples of how the activity level can be estimated will be disclosed below. The obtained information can thereby be used by the controller 150 when determining whether to accept or decline an incoming communication request to the XR device or not, or more generally, to determine how an incoming communication request to the XR device should be treated, depending on if the communication request comes at pause event or not.

[0043] Fig. 2 is a flowchart illustrating embodiments of methods for handling incoming communication requests to an XR device 110. The methods are performed by the controller 150. The methods are advantageously provided as computer programs.

[0044] S102: The controller 150 obtains an activity level pattern of an XR environment. The XR environment is rendered by the XR device 110.

[0045] S104: The controller 150 predicts, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment.

[0046] S106: The controller 150 handles the incoming communication request to the XR device 110. The incoming communication request is external to the XR environment. The incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not. Embodiments relating to further details of handling incoming communication requests to an XR device no as performed by the controller 400, 500 will now be disclosed with continued reference to Fig. 2.

[0047] Different ways of how the controller 150 can obtain the activity level pattern of the XR environment will be disclosed next.

[0048] In some aspects, the activity level pattern represents a historical data behavior as defined by time series of activity level indications. That is, in some embodiments, the activity level pattern is represented by a time series of activity level indications. It is here noted that the activity level pattern does not need to be periodic. The time series of activity level indications can then be extrapolated for the controller 150 to predict the at least one upcoming point in time for a pause event in the XR environment will be disclosed next.

[0049] There can be different sources from which information that can define the activity level pattern can be obtained.

[0050] In some embodiments, the activity level pattern is obtained from video analytics data of the XR environment. In this respect, there could be different examples of video analytics data. In some non-limiting examples, the video analytics data pertains to any, or any combination of: measurements of user activity in the XR environment (e.g., from mouse, keyboard, or other type of user-controlled activity), measurements of movements of objects in the XR environment, data extracted from the XR device 110. For this purpose, the video analytics data could be obtained by measuring the activity level of the user and / or the XR environment itself (as defined by movements of the user or of objects in XR environment), by means of information displayed to user, and / or by means of sounds played out to user. Further, the activity level pattern could also be obtained from sensor data (with examples of sensor data as disclosed above) generated by at least one sensor 160 worn by a user of the XR device 110, or at least monitoring the user (if not worn by the user). For example, sensor data in terms of eye movement of the user is expected to behave differently while a game is played out in the XR environment compared to when a pause, or title, screen is displayed in the XR environment. Further, the level of activity can be estimated from the pupil dilation. From this information the controller 150 could identify passed downtimes in the XR environment (such as passed pause events), but also just measure the general activity amount. Here, general measurements of audio, image, and video features can be used by the controller 150 to classify whether any rendered, or played out, audio, image, and video of the XR environment represents a pause event. In addition to user activity and measurements of movements of objects in the XR environment, special content indicators, such as timers that are counting down, certain displayed objects (such as full-screen menus) certain keywords (such as “pause”, “loading” etc.) can be identified by the controller 150. Such classification can be achieved by using different classification algorithms.

[0051] Further, in some embodiments, the XR environment is run by an XR environment engine 120, and the activity level pattern is obtained from signals generated by, or being provided to, the XR environment engine 120. In this respect, there could be different examples of such signals. In some non-limiting examples, the signals pertain to any, or any combination of: game state information, start-up screen indications, menu screen indications, clock data (such as timers counting down, time of day), keywords, input and / or output as generated by XR environment engine 120, input and / or output defined by user interaction with the XR environment. For example, pause events and play events could be signaled from the game engine itself. Especially, for games with round-timers, this would make the pause-events be signaled with high precision before they occur.

[0052] In Fig. 3 is illustrated an example of an activity level pattern 300, where the activity level pattern 300 comprises a first part 300a representing the past activity levels over time and a second part 300b that represents the future predicted activity levels over time. The first part 300a and the second part 300b are separated by the point in time denoted “Now”. Passed pause events 310a, 310b and one predicted pause event 310c are also shown.

[0053] Different ways of how the controller 150 can handle the incoming communication request to the XR device 110 will be disclosed next. It is assumed that the incoming communication request is received from a communication device 130. The incoming communication request might be a request for a voice call, a video call, a chat, or other type of communication with the user of the XR device 110. In general terms, instead of directly alerting the user of the XR device no of the incoming communication request, the controller 150 first checks whether the incoming communication request coincides or not with the at least one upcoming point in time for the pause event.

[0054] In case the incoming communication request fails to coincide with the at least one upcoming point in time for the pause event, the controller 150 is configured to handle the incoming communication request to the XR device 110 by performing (optional) steps Sio6-a2 and Sio6-a4.

[0055] Sio6-a2: The controller 150 provides information of the at least one upcoming point in time for the pause event to the communication device 130.

[0056] Sio6-a4: The controller 150 declines the incoming communication request, or at least pauses the incoming communication request until the at least one upcoming point in time for the pause event.

[0057] Further, in case the incoming communication request coincides with the at least one upcoming point in time for the pause event, the controller 150 is configured to handle the incoming communication request to the XR device 110 by performing (optional) steps Sio6-b2 and Sio6-b4-

[0058] Sio6-b2: The controller 150 alerts the user of the XR device 110 of the incoming communication request.

[0059] Sio6-b4: The controller 150 accepts the incoming communication request from the communication device 130.

[0060] In this respect, if the pause event has a time duration that is too short for some type of communication, such as a voice call or a video call, then the incoming communication request should not be accepted. Therefore, in some embodiments, the control device 150, before accepting the incoming communication request, verifies that the pause event has a time duration that is longer than a threshold value.

[0061] There could be different ways to facilitate the incoming communication request once it has been accepted. Below will be provided two examples. In a first example, it is assumed that the communication device 130 is connected to the XR environment. In a second example, it is assumed that the communication device 130 is disconnected from the XR environment. In both examples it is for simplicity but without loss of generality assumed that the XR environment at least includes audio and that the incoming communication request is a request for a voice call.

[0062] In the first example, the user of the communication device 130 initiates the communication by uttering a wake-word, such as “hello X”, “hi X”, or the like, where “X” is the name of the user of the XR device 110. The wake-word can be detected by running natural language processing (NLP) and intent detection in the controller 150. Detection of the wake-word by the controller 150 could then represent the incoming communication request. The user of the XR device 110 is then made aware of the incoming communication request, as in step Sio6-b2 and the incoming communication request from the communication device 130 is accepted as in step Sio6-b4. The user of the XR device 110 could then respond similarly by saying “hello Y”, “hi Y”, or similar, where “Y” is the name of the user of the communication device 130. By using NLP, the controller 150 could detect that the response is towards person Y and not an in-game discussion. A voice channel can then be set up by the controller 150 between the XR device 110 and the communication device 130. This voice channel might interrupt all audio in the XR environment, or be overlayed on top (i.e., mixed) of the audio in the XR environment, possibly suppressing the ingame audio. Various audio-mixing could here be considered, for example keeping environment sounds in the XR environment but muting other voice channels in the XR environment. Then, upon termination of the communication, the audio settings in the XR environment can be reset to default values.

[0063] In the second example, the user of the communication device 130 initiates the communication by placing a call to the XR device 110. As the communication is controlled by the controller 150, the controller 150 receives the call to the XR device 110. The user of the XR device 110 is then made aware of the incoming communication request, as in step Sio6-b2 and the incoming communication request from the communication device 130 is accepted as in step Sio6-b4. The user of the XR device 110 could then respond by saying “hello Y”, “hi Y”, or similar, where “Y” is the name of the user of the communication device 130. By using NLP, the controller 150 could detect that the response is not an in-game discussion and hence instead directed to the user of the communication device 130. A voice channel can then be set up by the controller 150 between the XR device 110 and the communication device 130, in the same manner as disclosed above, but with the difference that the communication device 130 only has access to the voice channel and no other information of the XR environment.

[0064] Further, in case the incoming communication request fails to coincide with the at least one upcoming point in time for the pause event, the controller 150 is configured to handle the incoming communication request to the XR device 110 by performing (optional) step S106-C2.

[0065] S106-C2: The controller 150 provides an indication of the incoming communication request in the XR environment, without accepting the incoming communication request, to thereby alert a user of the XR device 110 of the incoming communication request.

[0066] In some examples, the indication is provided by changing appearance of at least one object in the XR environment. In this way, subtle changes can be made in the XR environment to indicate to the user of the XR device 110 that someone outside the XR environment needs their attention. Depending on what changes are available, coloring the sky of the in the XR environment red, changing the hue of external lighting, changing displayed objects or even adding textures to objects in the XR environment, writing messages on billboards, in the XR environment etc., could be some examples of alterations that can be made to the XR environment without distracting the user too much. In this way the user of the XR device 110 can continue to be immersed in the XR environment, or decide to accept the incoming communication request. The changes can also be based on the level of activity in the XR environment; the higher the activity level is, the more subtle the changes could be.

[0067] Further in this respect, in some embodiments, the type of indication of the incoming communication request provided in the XR environment depends on an identifier of the communication device 130, and / or on a priority level indicated in the incoming communication request. Hence, in this way, any alterations of the XR environment might be based on the originator (e.g., defined by an identifier of the communication device 130 or an identifier of the user of the communication device 130) of the communication request. In this way, customized indications can be used. In some examples, the XR device no comprises an indicator entity by means of which an indication of the activity level pattern can be provided. For example, the indicator entity might be a light-emitting diode display arranged to emit colored light, where the color of the emitted light, or the intensity of the emitted light, indicates the activity level pattern.

[0068] Fig. 4 schematically illustrates, in terms of a number of structural units, the components of a controller 400 according to an embodiment. Processing circuitry 410 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 610 (as in Fig. 6), e.g. in the form of a storage medium 430. The processing circuitry 410 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0069] Particularly, the processing circuitry 410 is configured to cause the controller 400 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 430 may store the set of operations, and the processing circuitry 410 may be configured to retrieve the set of operations from the storage medium 430 to cause the controller 400 to perform the set of operations. The set of operations may be provided as a set of executable instructions.

[0070] Thus the processing circuitry 410 is thereby arranged to execute methods as herein disclosed. The storage medium 430 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The controller 400 may further comprise a communications (comm.) interface 420 at least configured for communications with the entities in Fig. 1. As such the communications interface 420 may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry 410 controls the general operation of the controller 400 e.g. by sending data and control signals to the communications interface 420 and the storage medium 430, by receiving data and reports from the communications interface 420, and by retrieving data and instructions from the storage medium 430. Other components, as well as the related functionality, of the controller 400 are omitted in order not to obscure the concepts presented herein. Fig. 5 schematically illustrates, in terms of a number of functional modules, the components of a controller 500 according to an embodiment. The controller 500 of Fig. 5 comprises a number of functional modules; an obtain module 510 configured to perform step S102, a predict module 520 configured to perform step S104, and a control module 530 configured to perform step S106. The controller 500 of Fig. 5 may further comprise a number of optional functional modules, such as any of a provide module 540 configured to perform step Sio6-a2, a decline / pause module 550 configured to perform step Sio6-a4, an alert module 560 configured to perform step Sio6-b2, an accept module 570 configured to perform step Sio6-b4, and a provide module 580 configured to perform step S106-C2.

[0071] In general terms, each functional module 510:580 may in one embodiment be implemented only in hardware and in another embodiment with the help of software, i.e., the latter embodiment having computer program instructions stored on the storage medium 430 which when run on the processing circuitry makes the controller 400 perform the corresponding steps mentioned above in conjunction with Fig 2. It should also be mentioned that even though the modules correspond to parts of a computer program, they do not need to be separate modules therein, but the way in which they are implemented in software is dependent on the programming language used. Preferably, one or more or all functional modules 510:580 maybe implemented by the processing circuitry 410, possibly in cooperation with the communications interface 420 and / or the storage medium 430. The processing circuitry 410 may thus be configured to from the storage medium 430 fetch instructions as provided by a functional module 510:580 and to execute these instructions, thereby performing any steps as disclosed herein.

[0072] The controller 400, 500 may be provided as a standalone device or as a part of at least one further device. For example, as disclosed above the controller 400, 500 may be provided the XR device 110 or the smart home controller 170. Alternatively, functionality of the controller 400, 500 may be distributed between at least two devices, or nodes. Thus, a first portion of the instructions performed by the controller 400, 500 may be executed in a first device, and a second portion of the of the instructions performed by the controller 400, 500 may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the controller 400, 500 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a controller 400, 500 residing in a cloud computational environment. Therefore, although a single processing circuitry 410 is illustrated in Fig. 4 the processing circuitry 410 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 510:580 of Fig. 5 and the computer program 620 of Fig. 6.

[0073] Fig. 6 shows one example of a computer program product 610 comprising computer readable storage medium 630. On this computer readable storage medium 630, a computer program 620 can be stored, which computer program 620 can cause the processing circuitry 410 and thereto operatively coupled entities and devices, such as the communications interface 420 and the storage medium 430, to execute methods according to embodiments described herein. The computer program 620 and / or computer program product 610 may thus provide means for performing any steps as herein disclosed.

[0074] In the example of Fig. 6, the computer program product 610 is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 610 could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 620 is here schematically shown as a track on the depicted optical disk, the computer program 620 can be stored in any way which is suitable for the computer program product 610.

[0075] The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

CLAIMS1. A method for handling an incoming communication request to an extended reality, XR, device (no), wherein the method is performed by a controller (150, 400, 500), and wherein the method comprises: obtaining (S102) an activity level pattern of an extended reality, XR, environment, wherein the XR environment is rendered by the XR device (no); predicting (S104), based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment; and handling (S106) the incoming communication request to the XR device (no), wherein the incoming communication request is external to the XR environment, and wherein the incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

2. The method according to claim 1, wherein the activity level pattern is represented by a time series of activity level indications.

3. The method according to any claim 1 or 2, wherein the activity level pattern is obtained from video analytics data of the XR environment.

4. The method according to claim 3, wherein the video analytics data pertains to any, or any combination of: measurements of user activity in the XR environment, measurements of movements of objects in the XR environment, data extracted from the XR device (110).

5. The method according to any preceding claim, wherein the activity level pattern is obtained from sensor data generated by at least one sensor (160) worn by a user of the XR device (110).

6. The method according to claim 5, wherein the sensor data pertains to any, or any combination of: eye-tracking data, pupil dilation data, eye-blinking data, pulse data, breathing data, skin conductance data, EEG data.

7. The method according to any preceding claim, wherein the XR environment is run by an XR environment engine (120), and wherein the activity level pattern is obtained from signals generated by, or being provided to, the XR environment engine (120).

8. The method according to claim 7, wherein the signals pertain to any, or any combination of: game state information, start-up screen indications, menu screen indications, clock data, keywords, input and / or output as generated by XR environment engine (120), input and / or output defined by user interaction with the XR environment.

9. The method according to any preceding claim, wherein the incoming communication request is received from a communication device (130), and wherein, in case the incoming communication request fails to coincide with the at least one upcoming point in time for the pause event, handling the incoming communication request to the XR device (110) comprises: providing (Sio6-a2) information of the at least one upcoming point in time for the pause event to the communication device (130); and / or declining (Sio6-a4) the incoming communication request, or at least pausing the incoming communication request until the at least one upcoming point in time for the pause event.

10. The method according to any of claims 1 to 8, wherein the incoming communication request is received from a communication device (130), and wherein, in case the incoming communication request coincides with the at least one upcoming point in time for the pause event, handling the incoming communication request to the XR device (110) comprises: alerting (Sio6-b2) a user of the XR device (110) of the incoming communication request; and accepting (Sio6-b4) the incoming communication request from the communication device (130).

11. The method according to claim io, wherein the control device, before accepting the incoming communication request, verifies that the pause event has a time duration that is longer than a threshold value.

12. The method according to any of claims 1 to 8, wherein the incoming communication request is received from a communication device (130), and wherein, in case the incoming communication request fails to coincide with the at least one upcoming point in time for the pause event, handling the incoming communication request to the XR device (110) comprises: providing (S106-C2) an indication of the incoming communication request in the XR environment, without accepting the incoming communication request, to thereby alert a user of the XR device (110) of the incoming communication request.

13. The method according to claim 12, wherein the indication is provided by changing appearance of at least one object in the XR environment.

14. The method according to claim 12, or 13, wherein what type of indication of the incoming communication request that is provided in the XR environment depends on an identifier of the communication device (130), and / or on a priority level indicated in the incoming communication request.

15. The method according to any preceding claim, wherein the XR device (110) is an eyewear, such as a head-mounted display, HMD, device.

16. The method according to any preceding claim, wherein the controller (150, 400, 500) is part of the XR device (110).

17. The method according to any of claims 1 to 16, wherein the controller (150, 400, 500) is part of a smart home controller (170).

18. A controller (150, 400, 500) for handling incoming communication requests to an extended reality, XR, device (110), the controller (150, 400, 500) comprising processing circuitry (410), the processing circuitry being configured to cause the controller (150, 400, 500) to: obtain an activity level pattern of an extended reality, XR, environment, wherein the XR environment is rendered by the XR device (110);predict, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment; and handle the incoming communication request to the XR device (no), wherein the incoming communication request is external to the XR environment, and wherein the incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

19. A controller (150, 400, 500) for handling incoming communication requests to an extended reality, XR, device (110), the controller (150, 400, 500) comprising: an obtain module (510) configured to obtain an activity level pattern of an extended reality, XR, environment, wherein the XR environment is rendered by the XR device (110); a predict module (520) configured to predict, based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment; and a control module (530) configured to handle the incoming communication request to the XR device (110), wherein the incoming communication request is external to the XR environment, and wherein the incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

20. The controller (150, 400, 500) according to claim 18 or 19, further being configured to perform the method according to any of claims 2 to 17.

21. A computer program (620) for handling incoming communication requests to an extended reality, XR, device (110), the computer program comprising computer code which, when run on processing circuitry (410) of a controller (150, 400, 500), causes the controller (150, 400, 500) to: obtain (S102) an activity level pattern of an extended reality, XR, environment, wherein the XR environment is rendered by the XR device (110); predict (S104), based on the activity level pattern, at least one upcoming point in time for a pause event in the XR environment; andhandle (S106) the incoming communication request to the XR device (no), wherein the incoming communication request is external to the XR environment, and wherein the incoming communication request is handled differently depending on whether the incoming communication request coincides with the at least one upcoming point in time for the pause event or not.

22. A computer program product (610) comprising a computer program (620) according to claim 21, and a computer readable storage medium (630) on which the computer program is stored.

Images