Enhanced metaverse communication

Abstract

This invention describes methods and systems for providing users, that are virtually present in a metaverse, with communications capabilities on their own real-life network and account by using an expanded metaverse authentication identity and / or credentials. This may include a communications credentialing process which can be performed from within the metaverse for communicating directly or indirectly with a user's mobile phone and a biometric process operating in a portal device (e.g., a virtual reality headset) that can be invoked from within the metaverse, and a specific unique metaverse identity.

Description

[0001] ENHANCED METAVERSE COMMUNICATION

[0002] FIELD OF THE INVENTION

[0003] This invention relates to a communications system which may be applied to communications devices or other data generating devices (e.g., sensors) used in aug- mented / virtual reality (AR / VR) or metaverse applications.

[0004] BACKGROUND OF THE INVENTION

[0005] With the emergence of digital media represented by the Internet, scattered media of text, audio, pictures and images have been integrated into an interconnected communication system, and individuals can also create free connections and diverse interactions through the Internet. The integration of media functions and the "decentralized" nature of the Internet has weakened the power of mass communication and made interpersonal communication increasingly important. This integration and decentralization will be further enhanced in the next-generation version of the Internet, the "metaverse". Although there is no standard conceptual definition of the metaverse, it is recognized that the metaverse virtual space and the real world maintain a high degree of synchronization and intercommunication with interaction effects close to the real. Through technology open source and platform open source, users can carry out independent innovation and creation in the metaverse to build an original virtual world. The metaverse will continue to evolve indefinitely as economic system with closed-loop operation.

[0006] The metaverse is not different to real-life in terms of its needs for communications. Within the metaverse users may wish to call, or take calls, from their friends, perhaps to organise to meet within the metaverse or conduct their normal business. They would wish to remain in communication whilst in the metaverse, particularly if they are spending considerable time there. There may also be a need to conduct a banking transaction or purchase real world or virtual products in the metaverse. Currently this may be handled by specific applications (apps) provided by the metaverse provider. For example, messaging services may be provided for voice, text and / or video communication between users both within and outside of their metaverse (e.g., on dedicated headsets).

[0007] However, users may wish to use their customary communications accounts to communicate within one or more metaverses. This may include global communications whilst within a metaverse without stepping out and without having to rely on communications provided by the metaverse provider / owner. Virtual communications devices in the metaverse should provide a link to a user's own network account / subscription, not an account provided by the metaverse provider. Moreover, during a metaverse session, communications should be routed to them in the metaverse, not to their actual device outside the metaverse. Communication senders outside the metaverse (e.g., in a 5G network) communicating with someone within a metaverse may wish to have settings whereby their metaverse avatar is displayed instead of their real-world appearance. A user, while in the metaverse, may receive a call or data through a device in the real world, and the user may wish to access the call or the information through a device in the real world or make it available in the metaverse.

[0008] SUMMARY OF THE INVENTION

[0009] It is an object of the present invention to provide generic communications capabilities through use of a virtual communications device within the metaverse, such that the virtual communications device can represent and duplicate functionalities of a real phone device as if it were operated in the real world.

[0010] It is also an object of the present invention to handle privacy aspects whilst communicating with users inside and outside the metaverse.

[0011] This object is achieved by an apparatus, by a communication device, by a metaverse implementation, by a communication system, by a method , and by a computer program product as claimed in in the appended claims.

[0012] According to a first aspect (directed e.g. to a controller of a communication device), an apparatus for registering a virtual communication device in a metaverse implementation is provided, wherein the apparatus is configured to: obtain authentication and credential information of a user; package the authentication and credential information; generate an extended authentication code based on the packaged authentication and credential information; and access the metaverse implementation and register the virtual communication device in the metaverse implementation by using the extended authentication code.

[0013] According to a second aspect (directed e.g. to a registration function of a metaverse application / implementation), an apparatus for registering a virtual communication device in a metaverse implementation is provided, wherein the apparatus is configured to: receive an extended authentication code of a user from a real-world communication device; register a virtual communication device for the user in the metaverse implementation by using the extended authentication code; extract authentication and credential information of the user from the extended authentication code; attach the extracted authentication and credential information to the registered virtual communication device; and register the virtual communication device for the user in a real-world communication network by using the extracted credential information.

[0014] According to a third aspect, a communication device comprising the apparatus of the first aspect is provided.

[0015] According to a fourth aspect, a metaverse implementation comprising the apparatus of the second aspect is provided.

[0016] According to a fifth aspect (directed e.g. to a control procedure of a communication device), a method of registering a virtual communication device in a metaverse implementation is provided, wherein the method comprises: obtaining authentication and credential information of a user; packaging the authentication and credential information; generating an extended authentication code based on the packaged authentication and credential information; and accessing the metaverse implementation and registering the virtual communication in the metaverse implementation by using the extended authentication code.

[0017] According to a sixth aspect (directed to a registration procedure of a metaverse application / implementation), a method of registering a virtual communication device in a metaverse implementation is provided, wherein the method comprises: receiving an extended authentication code of a user from a real-world communication device; registering a virtual communication device for the user in the metaverse implementation by using the extended authentication code; extracting authentication and credential information of the user from the extended authentication code; attaching the extracted authentication and credential information to the registered virtual communication device; and registering the virtual communication device for the user in a real-world communication network by using the extracted credential information.

[0018] According to a seventh aspect, a computer program product is provided, which comprises code means for producing the steps of the method of the fifth or sixth aspect when run on a computer device.

[0019] Accordingly, an enhanced communication with improved metaverse authentication can be provided based on an existing network authentication (e.g., authentication by a subscriber identity module or an embedded subscriber identity module of a user's real- world communication device). The metaverse communication device (virtual communication device) can invoke a registration process (e.g., biometric registration) which is performed on the actual user in the real-world as part of authenticating both for logging into the metaverse and on the metaverse communication device within the metaverse. The metaverse communication device can clone functions of a user's real-world communication device without the user having to leave the metaverse e.g., to perform any additional authentication. Thereby, a powerful communications capability can be provided to the user, enabling full and seamless network capabilities within a metaverse.

[0020] According to a first option that can be combined with any one of the first to seventh aspects, the credential information may be derived from a subscriber identity module of the real-world communication device or a copy of the subscriber identity module, e.g., a clone of an embedded subscriber identity module running in a virtual embedded universal integrated circuit card.

[0021] According to a second option that can be combined with the first option or any one of the first to seventh aspects, the authentication information may be obtained from a biometric method performed at a paired portal device, e.g., a virtual reality headset, wherein the biometric method can be invoked from within the metaverse implementation.

[0022] According to a third option that can be combined with the first or second op- tion or any one of the first to seventh aspects, the credential information may comprise a unique metaverse identity of the user, e.g., a unique username and password of the user. According to a fourth option that can be combined with any one of the first to third options or any one of the first to seventh aspects, the apparatus of the second aspect may be configured to communicate with a subscriber identity module of the real-world communication device.

[0023] According to a fifth option that can be combined with any one of the first to fourth options or any one of the first to seventh aspects, communication capabilities of the real-world communication network may be provided within the metaverse implementation, wherein the virtual communication device can be used to initiate a communication session with other entities and / or users inside or outside the metaverse implementation.

[0024] According to a sixth option that can be combined with any one of the first to fifth options or any one of the first to seventh aspects, authorization and / or privacy control over data that is exposed to metaverse applications or providers or other users within the metaverse implementation may be provided, wherein the authorization and / or privacy control may be based on access tokens for ensuring that virtual communications services are part of the user's subscription plan and / or for requesting security materials from the real-world communication network, and / or privacy profiles for determining which data the user allows to share in which context and with which entities.

[0025] According to a seventh option that can be combined with any one of the first to sixth options or any one of the first to seventh aspects, porting predetermined tasks and / or data to the virtual communications device may be allowed, wherein the predetermined tasks and / or data may comprise one or more of: receiving and sending calls by the virtual communication device over the real- world communication network assigned to the user's standard network account and / or subscription; transferring a biometric method and / or result conducted on the user for authentication purposes to the virtual communications device for use by the virtual communications device to establish authentication of a user's identity using real-world biometrics; or using the credential and authentication information to establish an identity authentication for the user when logging into the metaverse implementation and allowing the virtual communication device to be used as primary and / main communication device.

[0026] According to an eighth aspect of the invention, it is proposed a method for managing privacy preferences for use of digital assets, comprising the apparatus storing privacy preferences for a user that owns / oper- ates a set of digital assets, wherein the privacy preferences include one or more parameters indicative of whether or not the user allows: sharing information about digital / virtual assets to metaverse applications and / or to other users in the metaverse and / or rendering of digital / virtual assets in metaverse applications, and / or by the network, and / or at other users' UEs; or sharing contact information, communication preferences, communication history and / or usage data stored in a User Equipment, UE, or a metaverse virtual communications device, MVCD, with metaverse applications and / or with other users in the metaverse; or sharing audio / video input / output of an application running on, or a communication session / call from, a UE or MVCD with metaverse applications and / or with other users in the metaverse; or sharing information related to biometric methods and / or results thereof, or other biometric data of the user, or 5GS authentication creden- tials / information, user / UE / MVCD related identities, and / or username / passwords, and / or any credentials associated with the UE, user, and / or MVCD with metaverse applications and / or with other users in the metaverse; the apparatus using one or more digital asset identifiers to identify the digital assets.

[0027] In a first variant of the eighth aspect, the apparatus storing information about whether a confirmation by the user is to be requested for one or more of the stored privacy preferences or for one or more privacy parameters for which no privacy preference is stored .

[0028] Optionally, the apparatus uses a subscription identifier or UE identifier or user identifier to identify the user. The method may then comprise the apparatus transmitting a request to a UE related to the stored subscription identifier or to the stored UE identifier of the user.

[0029] In another variant, the method comprises the apparatus storing privacy preferences in relation to at least one metaverse application or in relation to a particular UE / MVCD or in relation to a virtual area / location in the virtual environment or in relation to a Public Land Mobile Network, PLMN, or non-public network (NPN) and / or network entities within a PLMN or NPN, or in relation to a usage scenario or in relation to a set of users.

[0030] In another variant, the method comprises retrieving and / or checking the privacy preferences.

[0031] Optionally, the method may comprise the apparatus causing a UE or a MVCD to render a user interface dialog, said UE or MVCD being related to the stored subscription identifier or the stored UE or MVCD identifier of the user, wherein the user interface dialog enables to check the privacy preference for one or more of the stored privacy preferences for which confirmation by the user is requested or for one or more privacy parameters for which no privacy preference is stored.

[0032] In another variant, the step of retrieving and / or checking the privacy preferences includes receiving a request from a first device to retrieve a privacy preference for use of one or more digital assets by the first or second device, and to provide the result of the retrieval or check to the first device. For example, the method may comprise retrieving the preferences for sharing information pertaining to a set of digital assets, based on a request from a first device, and verifying by the apparatus or by the first device whether or not sharing of the requested information (or subset thereof) to a second device is allowed or not.

[0033] In an example, the method may also comprise, upon determination that sharing of the requested information to the second device is allowed, sharing the requested sharing information to the second device and upon determination that sharing of the requested information to the second device is not allowed, providing an error message to the second device.

[0034] Optionally, the method may comprise the apparatus authenticating the first and / or second device.

[0035] In another variant, the method comprises storing digital assets, and if the privacy preferences allow sharing of the digital assets to the first or second device, allowing retrieval of stored digital assets by the first or second device and / or transmitting the stored digital asset to the first or second device and if the privacy preferences do not allow sharing of the digital assets to the first or second device, providing an error message.

[0036] Optionally, the apparatus may be a digital asset repository and / or a UE.

[0037] In a variant, the set of digital assets includes a virtual communication device (MVCD).

[0038] In a variant, the step of retrieving and / or checking the privacy preferences is performed after receiving a request from a first device or second device to retrieve one or more digital assets, and to provide the result of the retrieval or check to the first device or second device.

[0039] In another variant, the method comprises the apparatus obtaining authentication information from a subscriber identity module operated by a real-world communication device (10) associated with the user, or a part thereof, or a copy of the subscribed identity module operated by a virtual communication device in a metaverse implementation (30) or from a biometric method performed at a paired portal device (20).

[0040] In accordance with a ninth aspect of the invention, it is proposed an apparatus, comprising a communication unit including a receiver and a transmitter; a controller, a data storage including instructions which when executed cause the apparatus to: store privacy preferences for a user that owns / operates a set of digital assets, wherein the privacy preferences include one or more parameters indicative of whether or not the user allows: sharing information about digital / virtual assets to metaverse applications and / or to other users in the metaverse and / or rendering of digital / virtual assets in metaverse applications, and / or by the network, and / or at other users' UEs; or sharing contact information, communication preferences, communication history and / or usage data stored in a User Equipment, UE, or a metaverse virtual communications device, MVCD, with metaverse applications and / or with other users in the metaverse; or sharing audio / video input / output of an application running on, or a communication session / call from, a UE or MVCD with metaverse applications and / or with other users in the metaverse; or sharing information related to biometric methods and / or results thereof, or other biometric data of the user, or 5GS authentication creden- tials / information, user / UE / MVCD related identities, and / or username / passwords, and / or any credentials associated with the UE, user, and / or MVCD with metaverse applications and / or with other users in the metaverse; using one or more digital asset identifiers to identify the digital assets.

[0041] In accordance with a tenth aspect of the invention, it is proposed an apparatus for operating a virtual communication device (MVCD) in a metaverse implementation (30), wherein the apparatus is configured to: perform an IP Multimedia Subsystem, IMS, communication session with other communication devices on behalf of a real-world communication device (10); render A / V input received from other communication devices or from the real-world communication device; generate A / V output from input received from one or more users or digital assets related to a user, and application layer rendering information.

[0042] In accordance with an eleventh aspect of the invention, it is proposed a method for operating a virtual communication device (MVCD) in a metaverse implementation (30), wherein the method comprises: perform an IMS communication session with other communication devices on behalf of a real-world communication device (10); render A / V input received from other communication devices or from the real-world communication device; and generate A / V output from input received from one or more users or digital assets related to a user, and application layer rendering information. In accordance with a twelfth aspect of the invention, it is proposed a method for operating a virtual communication device (MVCD) in a metaverse implementation (30), comprising: establishing a secure communication channel with a real-world communication device (10); synchronizing state information between the real-world communication device and the virtual communication device through the secure communication channel; performing one or more of the following operations: perform an action on behalf of the real-world communication device, or perform the same operations as the real-world communication device, or perform a simulation of the real-world communication device.

[0043] In accordance with a thirteenth aspect of the invention, it is proposed an apparatus for operating a virtual communication device (MVCD) in a metaverse implementation (30), wherein the apparatus is configured to:

[0044] Establish a secure communication channel with a real-world communication device (10);

[0045] Synchronize state information between the real-world communication device and the virtual communication device through the secure communication channel

[0046] Perform one or more of the following operations:

[0047] Perform an action on behalf of the real-world communication device,

[0048] Perform the same operations as the real-world communication device,

[0049] Perform a simulation of the real-world communication device.

[0050] In accordance with a fourteenth aspect of the invention, it is proposed a method, comprising establishing an end-to-end communication channel between a real-world communication device (UE) and a virtual communication device (MVCD) based on a shared symmetric key and secret or decapsulation keys, wherein said shared symmetric key is derived through a key exchange or a key encapsulation mechanism using public or encapsulation keys, wherein thesecret or decapsulation keys are associated with the real-world communication device (UE) and a virtual communication device (MVCD), wherein the public key pair generated by the MVCD is ephemeral.

[0051] In a variant, the end-to-end communication channel is established between a core network and a virtual communication device (MVCD) through a third party metaverse services provider.

[0052] In another variant, the virtual communication device is a digital twin of the real-world communication device (UE).

[0053] In accordance with a fifteenth aspect of the invention, it is proposed an apparatus, comprising a transmitter, a receiver, a controller and a data storage including instructions which cause the apparatus to establish an end-to-end communication channel between a real-world communication device (UE) and a virtual communication device (MVCD) based on a shared symmetric key and secret or decapsulation keys, wherein said shared symmetric key is derived through a key exchange or a key encapsulation mechanism using public or encapsulation keys, wherein thesecret or decapsulation keys are associated with the real-world communication device (UE) and a virtual communication device (MVCD), wherein the public key pair generated by the MVCD is ephemeral.

[0054] In accordance with a sixteenth aspect of the invention, it is proposed a method comprising, deriving a fresh root security key by a real-world communication device (UE) wherein the derivation of said root security key comprises one or more, or a combination of at least two of the following parameters:

[0055] Master Key, which may be stored in a USIM UE identifier, digital asset identifier, vertical application layer server and / or client identifier(s), synchronization parameter, freshness parameter, which may be a random nonce, or a time value, wherein, said root security key is provided to the virtual communication device to serve as the root of security for the communication link to be established between the virtual communication device and the network.

[0056] In accordance with a seventeenth aspect of the invention, it is proposed an apparatus comprising, a transmitter, a receiver, a controller and a data storage including instructions which cause the apparatus to derive a fresh root security key by a real-world communication device (UE) wherein the derivation of said root security key comprises one or more, or a combination of at least two of the following parameters:

[0057] Master Key, which may be stored in a USIM

[0058] UE identifier, digital asset identifier, vertical application layer server and / or client identifier(s), synchronization parameter, freshness parameter, which may be a random nonce, or a time value, wherein, said root security key is provided to the virtual communication device to serve as the root of security for the communication link to be established between the virtual communication device and the network.

[0059] In accordance with an eighteenth aspect of the invention, it is proposed a method comprising, splitting control plane and / or user plane traffic data between a real-world communication device (UE) and a virtual communication device, wherein the subset of control plane and / or user plane traffic to be routed to the virtual communication device is determined based on a network policy or configuration, said network policy or configuration authorizing services for consumption within a metaverse im- plementation / application. Optionally, the method may comprise suspending or terminating the control / user plane traffic data split, based on the fulfillment of at least one of the following conditions: service authorization revocation by the network, metaverse service provider, or the user, service authorization expiry, activity detected, by the network, on the real-world communication device, inactivity for a pre-configured duration, detected by the metaverse service provider and indicated to the network.

[0060] In accordance with a nineteenth aspect of the invention, it is proposed an apparatus, comprising a transmitter, a receiver, a controller and a data storage including instructions which cause the apparatus to split control plane and / or user plane traffic data between a real-world communication device (UE) and a virtual communication device, wherein the subset of control plane and / or user plane traffic to be routed to the virtual communication device is determined based on a network policy or configuration which authorizes services for consumption within a metaverse implementation / application.

[0061] It shall be understood that the apparatus, the communication device, the metaverse implementation, the communication system, the method, and the computer program product of the appended claims may have similar and / or identical embodiments, in particular, as defined in the dependent claims.

[0062] It shall be understood that a preferred embodiment can also be any combination of the dependent claims or above embodiments with the respective independent claim.

[0063] These and other aspects will be apparent from and elucidated with reference to the embodiments described hereinafter.

[0064] BRIEF DESCRIPTION OF THE DRAWINGS

[0065] In the following drawings: Fig. 1 schematically shows a block diagram of a communications system with signaling for metaverse login and device instantiation according to various embodiments;

[0066] Fig. 2 schematically shows a block diagram of a communications system with signaling for metaverse communication and close-out according to various embodiments;

[0067] Fig. 3 schematically shows a flow diagram of a metaverse communications procedure according to various embodiments;

[0068] Fig. 4 schematically shows instantiation of a virtual communications device as a holographic display, according to an embodiment;

[0069] Fig. 5 schematically shows a processing and signaling diagram of a procedure for establishing a call, communication link and / or session, according to an embodiment;

[0070] Fig. 6 schematically shows a communications system that provides a distributed ledger for tracking user-owned or user-associated virtual assets, according to an embodiment; and

[0071] Fig. 7 schematically shows a system and flow diagram of another procedure for establishing a call, communication link and / or session, according to an embodiment.

[0072] Fig. 8 is a communication exchange chart representing a procedure in accordance with another embodiment.

[0073] DETAILED DESCRIPTION OF EMBODIMENTS

[0074] Embodiments of the present invention are now described based on a cellular communication network environment, such as 5G. However, the present invention may also be used in connection with other wireless technologies in which metaverse applications are provided or can be introduced.

[0075] A cellular or wireless network or system (which may be called "5GS" in 5G terminology) can be accessed from a communication or user device (e.g., a mobile phone or smartphone or laptop or computer etc., which may be called "user equipment" (UE) in 5G terminology) via a wireless access device such as a cellular base station or a WiFi access point or a ultrawide band (UWB) personal area network (PAN) coordinator. The wireless access device is part of a radio access network (RAN, which may be called "5GRAN" in 5G terminology), which provides an interface to functions in the core network (CN, which may be called "5GC" in 5G terminology). The RAN implements a radio access technology (RAT). Conceptually, it resides between the communication device and the core network which offers numerous services to customers who are interconnected via the RAN. More specifically, the core network may direct communication streams over the communication network and possibly other networks.

[0076] Throughout this disclosure, the term "network" may be used as synonym for "access device" in this disclosure. This means for example that when it is written that the "network" performs a certain operation it may be performed by a CN function of a wireless communication network, or by one or more access devices that are part of such a wireless communication network, and vice versa. It can also mean that part of the functionality is performed by a CN function of the wireless communication network and part of the functionality by the base station.

[0077] Moreover, the term "metaverse" is understood as referring to a shared set of interactable spaces, within which users may interact with one another alongside mutually perceived real-world and virtual features (i.e., augmented reality (AR)) or where those spaces are entirely composed of virtual features (i.e., virtual reality (VR)). VR and AR may generally be referred to as "mixed reality" (MR). Additionally a metaverse application and metaverse server may be understood as referring to a Vertical Application Layer (VAL) client and VAL server, as defined in TS 23.434. Such a metaverse application and metaverse server may be connected / linked to and / observed by 3GPP system using Service Layer Architecture Layer (SEAL) client (e.g., on the UE's side) and SEAL server(s) on the network / 3rdparty service provider side, following the general architecture and procedures defined in TS 23.434, and in particular the SEAL / VAL client / server functionalities and procedures pertaining to the discovery and media / profile management of digital assets defined in TS 23.438. It is to be noted that the terms "VAL Client" and "VAL Server" are understood as referring to the entity providing client-side functionalities corresponding to the virtual applications, and server application function of a specific VAL service (e.g., metaverse service), and the terms "SEAL Client" and "SEAL Server" are understood as referring to the entity providing client-side and server-side functionalities corresponding to a specific SEAL service (e.g., digital assets, identity management, etc).

[0078] Additionally, the term "data" is understood as referring to a representation according to a known or agreed format of information to be stored, transferred or otherwise processed. The information may particularly comprise one or more channels of audio, video, image, haptic, motion or other form of multimedia information that may be synchronized. Such multimedia information may be derived from sensors (e.g., microphones, cameras, motion detectors, etc.) or may be partially or wholly synthesized (e.g., live actor in front of a synthetic background).

[0079] Additionally, the term "digital asset" may be understood as referring to any piece of digitally storable information that may be used to realize value, as described in TS 22.156, and that may be uniquely identifiable using a "digital asset identifier". Such a "digital asset identifier" may be understood, as per TS 23.438, as referring to an identifier that is unique to the digital asset across different mobile metaverse services. Additionally, the term "digital twin" is understood, as per TS 22.156, as referring to a real-time representation of a physical asset in a digital world.

[0080] It is noted that throughout the present disclosure only those blocks, components and / or devices that are relevant for the proposed data distribution function are shown in the accompanying drawings. Other blocks have been omitted for reasons of brevity. Furthermore, blocks designated by same reference numbers are intended to have the same or at least a similar function, so that their function is not described again later.

[0081] Metaverse providers may present a generic Internet interface with a user interface (U I ) and input-output (IO) facility, within the metaverse to access a set of apps via this interface, enabling them to perform certain tasks that person would otherwise do with an app on their mobile phone, e.g. check weather forecast, read news, follow social media etc. However, this is not necessarily well integrated in the sense that they would need to access that interface, load the app, log into the app with their username and password and then communicate. The available interface capability (e.g., collecting voice data of a person or several persons nearby in the metaverse) may be completely dependent on the nature of the interface provided by the metaverse provider. If login requires e.g. two-factor authentication, they may need to step outside the metaverse to access their phone, memorise a one-time password (OTP) and then re-enter the metaverse to enter it into the interface. The provider may not provide a very capable interface to perform voice calls, video calls and text messaging, as their desire might be for users to use their own provided communication means (e.g., messaging service of the metaverse operator or voice interaction with other users within the metaverse registered via Metaverse servers). As described in Huidong Bai et al.: "Bringing full- featured mobile phone interaction into virtual reality", Computers & Graphics, Vol. 97, June 2021, pages 42-53 (https: / / doi.Org / 10.1016 / j.cag.2021.04.004) and patents US11182953B2 and US20180113669, the interface of a mobile phone may be provided inside the metaverse using a screencast representation of smartphone, which could partially solve this problem.

[0082] Companies can provide specific video conferencing 'facilities' within a 'location' within the metaverse, where conference calls could take place (to those inside and outside the metaverse), with the cooperation of the metaverse provider. Some companies provide metaverse 'phone numbers' on an Ethereum blockchain, while it is unclear how these could be sensibly integrated with metaverse communications without relying on a specific app and / or by a high level of cooperation with the metaverse provider(s).

[0083] Companies can also provide voice / video-over-IP services, which may offer an identity or a phone number that users can use on various devices for making calls, sending messages, and receiving / sending voicemails, wherein an app for mobile devices can be used by anyone who wants a single number to ring all their devices. Calling may be performed over the Internet, IP Multimedia System (IMS) or legacy cellular or other wireless communication (e.g. if initial or final leg is needed using a legacy cellular network connection). The app loaded on e.g. a user's mobile phone may be configured to inform dedicated servers about the user's IP location and to forward calls (e.g., on a 5G communications systems to a (assigned) network telephone number) to predetermined destinations for that number. In this case, the call may be forwarded to the dedicated servers and these route the call through the Internet, IMS (or other cellular infrastructure) to the receiving devices. Thus, networks need to collaborate with metaverse servers and serve them calls and vice versa.

[0084] As described in 3GPP TR 22.856 (“Feasibility Study on Localized Mobile Metaverse Services" , V19.1.0), a mobile network may facilitate a harmonized representation, identification and authentication of users in multiple metaverses. The mobile network could be seen as an identity provider, which may also store digital assets of a user (such as an avatar representation) e.g. as part of its mobile phone subscription data that is normally used for access to mobile network services only, such as IMS for communication with other users. Mobile network operators may also provide the required QoS for low latency communication required for operating metaverse applications and their related communication services.

[0085] There is a trend that subscriber identity modules (SIMs) are replaced by eSIMs (embedded Subscriber Identity Modules) which are a form of SIM card that is embedded directly into a device. Instead of an integrated circuit located on a removable SIM card, an eSIM consists of software installed onto a chip permanently attached to a device. If the eSIM is eUlCC-compatible, it can be re-programmed with new SIM information. Otherwise, the eSIM is programmed with its integrated circuit card identifier (ICCID) and / or international mobile subscriber identity (I MSI ) and other information at the time it is manufactured and cannot be changed. The eSIM thus allows to activate a mobile data plan from a network provider without having to use a physical SIM. For example, several mobile network profiles (also known as eSIM profiles) could be installed on a mobile phone with an eSIM and two phone numbers may be used at the same time. In the eSIM system, a hardware device is included in the mobile phone onto which a digital SIM can be loadedThe eSIM can be responsible for security features of the SIM authentication process, for example hosting the encryption algorithms used. In the context of this patent application, the term eSIM is sometimes used to denote a eSIM profile.

[0086] Another trend is rapid transfer of eSIMS between phones without carrier involvement (as is possible with physical SIM movement between phones). The eSIM can be transferred from one mobile phone to another, or an eSIM can be dynamically loaded (e.g., when moving from one to another country). More than one eSIM can be present on a mobile phone and a user can switch between them.

[0087] Moreover, an eSIM quick transfer service may be provided, by which a user's phone number can be from a previous mobile phone to a new mobile phone without contacting the network provider. Moving an eSIM between devices may be done locally over Bluetooth.

[0088] An alternative to eSIMs for smaller devices and the Internet of Things has been provided by so-called "integrated SIMs" (iSIMs) which may be fully integrated into a security enclave of a system on chip (SoC). Moreover, so-called "nuSIMs" are smaller, cheaper and more eco-friendly since no extra hardware and plastic is required. In addition, they can meet the same security requirements as a classical SIM or eSIM and thereby ease logistics and production of small devices.

[0089] Digital fraud and impersonation are increasing in the metaverse and therefore there is an ever-present need for high levels of authentication when entering a metaverse. If users are intending to interact with other metaverse users and all they perceive is their avatar and voice (which may also be cloned or adapted), then they need a high level of assurance that a metaverse individual is really the representation of a real (specific) person. A variety of authentication processes, beyond username and password, are being considered for the metaverse. For example, non-fungible tokens (NFTs) on a blockchain are one proposal for a universal metaverse identity (ID).

[0090] In general, users may wish to use their customary communications accounts to communicate within one or more metaverses. This may include global communications whilst within a metaverse without stepping out and without having to rely on communications provided by the metaverse provider / owner. Virtual communications devices in the metaverse should provide a link to a user's own network account / subscription, not an account provided by the metaverse provider. Moreover, during a metaverse session, communications should be routed to them in the metaverse, not to their actual device outside the metaverse. Communication senders outside the metaverse (e.g., in a 5G network) communicating with someone within a metaverse may wish to have settings whereby their metaverse avatar is displayed instead of their real-world appearance. A user, while in the metaverse, may receive a call or data through a device in the real world, and the user may wish to access the call or the information through a device in the real world or make it available in the metaverse. In embodiments, this can be achieved through the use of a metaverse virtual communications device (MVCD) which is configured to be able to represent and duplicate desired functionalities (or a subset thereof) of a real phone device as if it were operated in the real world. These functionalities may include the following:

[0091] • Sending data captured (i.e., extracted from components of the metaverse) in the metaverse (e.g., the sound of a user's voice and the sound of another metaverse user's voice if this user is 'sufficiently close' in the metaverse (e.g. within the same virtual interaction space) or part of an ongoing communication interaction between this and another user within the metaverse, video of what the MVCD (e.g., through its virtual cameras) is viewing in the metaverse etc.) by communication from the MVCD to the 5G network;

[0092] • sending data generated in the real-world and received from devices contacted by or contacting the device on the 5G network to the MVCD and depicting within the metaverse in a form associated with that virtual device (e.g., sound is made to emanate from the MVCD as a source, a virtual screen associated with the MVCD displays video); and / or

[0093] • video data (e.g., 3D capture data) may be converted by the metaverse application / provider into a 3D form or other enhanced display format, wherein a user interface may be rendered for the virtual device within the metaverse, and data communications, such that the user may, for example, perform telephone banking, including authentication (such as two-factor authentication via a short message service (SMS) message whose results appear on the MVCD or using an authentication app, also visible on the MVCD) and being able to interact e.g. with the banking web pages 'as normal' implies that their banking app may need to appear on the MVCD.

[0094] The ability of other metaverse users to talk to, to be seen by, and / or to hear and see the output of the MVCD may be established by the user, e.g., they may explicitly 'share' their device with specific other users. Users within the metaverse may provide their MVCD to other metaverse users for their temporary use, in which case it is the voice and appearance if the other user to which the device is shared is 'transmitted' by the MVCD. To do this, the MVCD owner may need to have explicitly 'shared' the MVCD with that other user. Presumably the device output, Ul etc. may be invisible and inaudible to unshared metaverse actors, in particular the MVCD (in whatever form presented) may also be invisible.

[0095] In examples, the MVCD may not need to be 'carried' in the metaverse but could be 'invoked' by the owner, in which case its Ul, inputs and outputs may become visible and / or audible. It may then be 'uninvoked' and may disappear.

[0096] An aim may be for someone to call a user on a normal (real-world) phone system (e.g., voice or video call). If that user is in the real world they get / take the call on the standard smartphone. If they are in any metaverse, the call may be routed to them in the metaverse, and they may take the call on their MVCD. When they leave the metaverse, the calls may then be normally routed again to their real-world phone system. Thus, no app-spe- cific connectivity is required and there is no need to step outside the metaverse for setting up or using any functionality provided on the MVCD.

[0097] In the above scenarios, it is important to ensure that user consent is obtained and privacy of users is respected and their data is not breached. This may be achieved by providing improved metaverse authentication and authorization methods. Authentication methods are necessary for ensuring that users enter the metaverse as their own entity, and individuals within the metaverse cannot be impersonated by others. Authorization methods are necessary for ensuring that a user is authorized to use standard communication services within the metaverse.

[0098] MVCD registration, invocation and authentication The following embodiments are directed to enhanced communication within the metaverse or between the metaverse and the real world.

[0099] Fig. 1 schematically shows a block diagram of a communications system with signaling for metaverse login and device instantiation according to various embodiments.

[0100] The communications system comprises a user equipment (UE) 10, a portal device (PD) 20, a metaverse (MV) implementation 30 and a communication network (NW) 40.

[0101] Optionally, the portal device 20 (e.g., HMD, VR headset etc.) may be provided with or without a UE and may comprise a biometric function (BF) 204 configured to carry out a portal biometric such as iris recognition, voice recognition, face recognition or the like.

[0102] Additionally, the portal device 20 may comprise a UE portal biometric registration functionality or means 202 configured to provide an ability to pair to the user's UE 10 and enable registration of this biometric by the UE 10.

[0103] Furthermore, the portal device 20 may comprise an invoke biometric method (BM) functionality or means 206 configured to provide an ability to perform the biometric function when called (e.g., by an MVCD from the metaverse or by the UE 10) and return the result.

[0104] The UE 10 may comprise a communications credentials packaging (CCP) functionality or means 104 (e.g., implemented by a software-controlled processor) for communications or other device / user specific credentials, which is configured to obtain one or more communications or device / user specific credentials packets for transfer to the metaverse (e.g., the metaverse implementation 30), for example in one of the following ways:

[0105] In a first embodiment, eSIM digital details or a subset thereof may be copied from an eSIM of the UE 10 and may be formed into a packet and transferred (e.g. to be stored and used by an MVCD instance e.g. for authentication / authorization purposes). After successful transfer, the eSIM may be removed from the UE. If transferred and removed, risks (e.g., eSIM hijacking, corruption, tampering etc.) need to be mitigated. For instance, as the eSIM is intended to be transferred back to the UE (e.g. once a metaverse session is concluded), the UE may maintain a digest (i.e., output of a cryptographic hash function which takes as input the content of the eSIM) of the eSIM content, such that when the eSIM is transferred back to the UE, this latter could verify its integrity by comparing the stored digest against a digest computed using the eSIM received. Additionally, to mitigate eSIM hijacking (e.g., within the metaverse), the eSIM may be associated with a specific user and performs continuous (user) authentication (e.g., performing biometric authentication periodically, or based on its configuration, as determined by the network and / or the user), or conditionally-triggered re-authen- tication (e.g., if the MVCD is held by a different user and data (e.g., SMS / Call) is received, or based on its configuration, as determined by the network and / or by the user), to ensure it is being operated, and / or the data receiving is shown to the user with whom the eSIM is associated. Additionally or alternatively, the transfer of each eSIM profile is registered in a database whereby each eSIM profile may be linked to a set of trusted MVCDs or devices, and each time an MVCD or other device sets up a communication session or registers to a network or registers to the metaverse, the use of the eSIM profile needs to be authorized / checked by the database (e.g. by authenticating the MVCD or other device and verify if the MVCD or other device is part of the list of trusted MVCDs and / or devices).

[0106] In a second embodiment, the UE 10 may provide an identity and / or link to a digital copy and / or representation of an eSIM (e.g., an address of a subscription manager Data preparation (SM-DP+) server on which the UE's eSIM profile is stored) or an identity and / or link to a digital twin of the UE 10 which may operate a digital copy and / or representation of the eSIM, possibly augmented with credentials to enable access to such a digital copy and / or representation of the eSIM. The identity and / or link possibly augmented with credentials may be formed into a packet and transferred (e.g. to be used by an MVCD instance e.g. for authen- tication / authorization purposes). Note that a communication channel between the digital copy and / or representation of the eSIM may be established with the UE 10 that has stored the eSIM in a secure hardware element to invoke security processes and communicate results back and forth.

[0107] In a third embodiment, a credential exchange may be performed by communicating with a (e)SIM on the UE 10 e.g. using a local API available to a metaverse application (e.g. invoked by an MVCD instance running as part of the metaverse application) to directly or indirectly communicate with a UE's (e)SIM and / or by using 3GPP protocols (e.g., using a primary / secondary authentication procedure as described in 3GPP TS 33.501 between the UE and an authentication server (e.g. AAA server) operated by or linked to the metaverse provider), and (part of) that credential exchange and / or the result of that credential exchange may be formed into a packet and transferred to the metaverse (e.g., the metaverse implementation 30). For example, the UE's (e)SIM could provide credential information stored within the UE(s) (e)SIM, such as particular security keys or identities or derivatives thereof, or other information stored within the UE(s) (e)SIM, such as communication capabilities, preferences or contact information.

[0108] In a fourth embodiment, a credential exchange may be performed between a portal device 10 (e.g. head mounted display (HMD)) and the UE 10 (or a digital copy and / or representation of an eSIM of the UE 10 or a digital twin of the UE 10) e.g. in a similar manner to Bluetooth pairing of a UE and a remote device (such as smart watch or earpiece), but which may include video and data transfer, and (part of) that credential exchange and / or the result of that credential exchange may be formed into a packet and transferred. For example, the UE 10 may request the HMD to perform biometric authentication of the user by using sensors and / or a camera of the HMD (e.g., the HMD may perform an iris scan of the user since the HMD may have an eye-tracking sensor and / or camera). As a result of successful biometric authentication of the user, the UE may transfer e.g. communication credentials to the metaverse (e.g. to be used by an MVCD instance) or the HMD.

[0109] In a fifth embodiment, a credential exchange between the UE 10 (or digital copy and / or representation of an eSIM of the UE 10 or a digital twin of the UE) and the network (e.g., 5GC) may be initiated to perform authentication of the UE 10, after which an authenticated generic voice-over-IP (VoIP) telephone number, or IMSI or subscriber permanent identifier (SUPI) or generic public subscriber identifier (GPSI) or other device identifier related to the UE 10 or a metaverse / application-related identifier (e.g., related to the user / UE) or a IMS related Private / Public Identity may be formed into a packet and transferred (e.g., by the 5GC through an external interface, e.g., NEF), e.g. to a trusted metaverse application server operated by the cellular core network or indirectly to a metaverse application server that may be connected to the 5GC through an external interface (e.g. NEF), after which the identity related information in the packet may be used by an MVCD instance.

[0110] In a sixth embodiment, a credential exchange between the UE 10 (or a digital copy and / or representation of the eSIM of the UE 10 or a digital twin of the UE 10) and the network (e.g., 5GC) may be initiated to perform authentication of the UE 10, after which parameters (e.g., cryptographic keys, nonces, counters, or access tokens) used to establish a security context between the network and the UE may be formed into a packet and transferred to a metaverse application and / or an MVCD (e.g., upon a user, application or UE invoking a metaverse session or invoking the use of an MVCD in the metaverse or a communication session between an MVCD and another entity). This transfer may be done through a local application programming interface (API) or an interface between the UE 10 and a metaverse application, or via an external interface (e.g., network exposure function (NEF)) between the network and a metaverse application and / or server.

[0111] In at least some of the above first to sixth embodiments, the communications credentials or device / user specific packet may be protected (e.g., encrypted using Authentication and Key Management for Applications (AKMA), or a metaverse session key (e.g., key pair established at metaverse account setup or generated upon starting the metaverse session), or a public key provided by a metaverse application) upon transfer to the metaverse (e.g., metaverse application 30).

[0112] In an additional embodiment that may be combined with the above first to sixth embodiments, the UE 10 and / or portal device 20 may comprise a biometric method / re- sult packaging (BM / BR-P) functionality or means 102 (e.g., implemented by a software-con- trolled processor) for a biometric method and a biometric result. This comprises a biometric method packaging (BM-P) functionality or means 1024 of packaging a method to obtain a user's biometric into a packet (i.e., biometric method packet) and transferring this to a metaverse (e.g., the metaverse implementation 30). Additionally, the biometric method / re- sult packaging functionality or means 102 comprises a biometric result packaging (BR-P) functionality or means 1026 of packaging a biometric result of a user of the UE 10 and / or portal device 20 that invokes the biometric method into a results packet (i.e., biometric result packet) and transferring this to a metaverse (e.g., the metaverse implementation 30).

[0113] As indicated in Fig. 1, the biometric measurement may be performed (BP) and the result may be obtained by the UE 10, through communication between the biometric function 204 of the portal device 20 and the biometric result packaging functionality or means 1026 of the UE 10.

[0114] In order to trigger invocation and / or registration of a biometric method that is required and / or requested and / or preferred, the biometric method / result packaging functionality or means 102 (BM / BR-P) of the UE 10 may comprise a biometric invocation and / or registration (B-REG) functionality or means 1022 of invoking and / or registering a biometric method on the UE 10 where that biometric may be obtained on the UE 10 (e.g., if the metaverse portal device 20 is itself a UE) or may be obtained on another device (e.g., a head mounted display (HMD) paired with the UE 10) but may be called from the UE 10. As indicated in Fig. 1, a biometric registration (BR) may be achieved by a communication between the UE portal biometric registration functionality or means 202 of the portal device 20 and the biometric invocation and / or registration functionality or means 1022 of the UE 10.

[0115] Additionally, the UE 10 may comprise an extended authentication code (EAC) generation functionality or means 106 (e.g., implemented by a software-controlled processor) for generating an extended authentication code for entry into a metaverse (e.g., the metaverse implementation 30). The extended authentication code may comprise at least one of the biometric method, the biometric result, communications credentials or other de- vice / user-specific credentials obtained by interacting with the (e)SIM of the UE, communications credentials or other device / user-specific credentials obtained from a cellular network provider (e.g. based on subscription data and / or credentials stored for that user in the cellular core network, e.g. obtained via a Network Exposure Function (NEF)), and a unique metaverse ID such as a unique username and password (e.g., username / password related to a specific metaverse application (e.g., the metaverse implementation 30)), and / or a Soulbound token (SBT), i.e., a non-transferable digital asset (e.g., non-transferable NFT), which may be permanently tied to an individual owner and may represent a digital identifier). Credentials may include device identities or user identities that may be used to uniquely identify a particular device or user.

[0116] As indicated in Fig. 1, the extended authentication code generation functionality or means 106 collects packets (PC) from at least one of the credentials packaging (CCP) functionality or means 104, the biometric method packaging functionality or means 1024 and the biometric result packaging functionality or means 1026.

[0117] The extended authentication code may be protected (e.g., encrypted using AKMA, or a metaverse session key (e.g., key pair established at metaverse account setup or generated upon starting the metaverse session), or a public key provided by a metaverse application) upon transfer to the metaverse (e.g., the metaverse implementation 30).

[0118] The metaverse implementation 30 may comprise a metaverse authentication process (MVAP) capability 302 configured to use an extended authentication code (e.g., as obtained from the extended authentication code generation functionality or means 106 of the UE 10) as authentication for entering into that metaverse, and / or to invoke the use of an MVCD in the metaverse, and / or to initiate a communication session between an MVCD and another entity, and / or to store the extended authentication code for use with any MVCD set up for that user.

[0119] The metaverse authentication process may be a two-step process wherein, e.g. initially the user / UE authenticates to the metaverse with a set of credentials (e.g., username / password, digital ID (e.g., SBT), and upon invoking an MVCD, a second authentication takes place wherein the user authenticates to the network 40 (e.g., 5GS) (e.g., through one of the methods of the above first to sixth embodiments) to setup a communication session with / via the MVCD.

[0120] Furthermore, the metaverse implementation 30 may comprise an MVCD Instantiation process (MVCD-IP) capability 304 to instantiate and / or invoke MVCDs within the metaverse.

[0121] In an embodiment that may be combined with other embodiments, the MVCD instantiation process capability 304 may comprise a biometric MVCD attachment (B MVCD- A) functionality or means 3042 of 'attaching' a biometric method and / or result for a user with an MVCD for that particular user, e.g., by matching the user's identity with an MVCD (e.g., using a database in the metaverse application or the network (e.g., 5GC) which may link a user's identity with a set of MVCDs) or by using an ability to call the transferred biometric method by an MVCD from within the metaverse (i.e., a real-world method is then called) using MVCD biometric invocation (e.g. by triggering the portal device 20 to obtain a biometric result to enable user authentication using the respective biometric method) and / or an additional communication credentials MVCD attachment (CC MVCD-A) functionality or means 3044 of attaching the user-specific communications credentials or other device / user-specific credentials to a specific MVCD for that particular user. The biometric method and / or result, communications credentials or other device / user-specific credentials or unique metaverse ID may be obtained from the EAC. As part of this attachment process, the user may be prompted on the UE 10 or a HMD (e.g., a visual notification rendered inside the metaverse application and / or rendered as part of the normal and / or native Ul of the UE / HMD) used to invoke the metaverse or invoking the use of an MVCD in the metaverse to select a particular MVCD to use, if multiple MVCDs are registered for the user or the UE 10, and / or to select a new MVCD or particular visualization of an MVCD or set of capabilities of an MVCD, which may include initiating a purchasing or (payment) approval process by the user. T1

[0122] Additionally, in a related embodiment the MVCD instantiation process capability 304 may comprise an MVCD network registration (MVCD-NW REG) functionality or means 3046 of establishing the MVCD as part of the network 40 (e.g., 5GC) by employing the communications credentials or other device / user specific credentials and / or biometric method and / or results. For example, the MVCD or UE 10 or the metaverse application may perform an authentication and / or registration procedure with a 5G network (e.g. performing a pri- mary / secondary authentication procedure with the 5G network, e.g. via an IP connection with the 5G network and / or through communication via a NEF or other external interface and / or by triggering UE 10 (e.g. via local API) or a UE operated by the metaverse application provider to establish a communication session with the 5G network via a 5G RAT), which may include an MVCD specific identity or credential that may be derived from the biometric method and / or result, communications credentials or other device / user-specific credentials or unique metaverse ID.

[0123] In another embodiment, the communications credentials or other device / user- specific credentials may be a user eSIM profile copied from the eSIM of the UE 10 (or a subset thereof) or may be a link to a digital copy and / or representation of the UE's eSIM profile (e.g., stored on a SM-DP+ server) or a digital twin of the UE 10. The metaverse application and / or provider may load the eSIM profile on a physical eSIM located within the metaverse servers or on an emulation of an eSIM, or may use the link to a digital copy and / or representation of the UE's eSIM or digital twin of the UE 10. This may then be 'attached' to the MVCD and communications between the network 40, and the metaverse servers use this copy / represen- tation of the eSIM to authenticate and route calls or other communication sessions. In other words, a user's eSIM is set up and / or transferred onto the MVCD through eSIM emulation by the metaverse provider or large numbers of physical eSIMs (to which a single eSIM profile can be transferred for a temporary period) within the computer facilities of the metaverse provider, linked to the virtual MVCD simulation, and the simulated or copied / transferred eSIM may be directly used to perform a primary / secondary authentication procedure with the 5G network. The MVCD simulation may run within its own security context / environment (e.g., a protected virtual machine) so that its calculations and / or algorithms are not visible to other parts of the metaverse system. For additional security, the MVCD simulation may be hosted on computing infrastructure (e.g., an edge compute) of a public land mobile network (PLMN) to which the user is subscribed. In another embodiment, the communications credentials or other device / user-specific credentials may be a method to link to the (e)SIM on the UE 10 via a local API and / or by using 3GPP protocols and an (initial) result of that link. In a first option, the network 40 (e.g., 5GC) may be connected to the metaverse servers which may interrogate the UE's (e)SIM via this link to establish its credentials using network protocols (e.g., 5G protocols) The metaverse servers and the UE's (e)SIM may communicate via this link such that network communication data which requires SIM authentication is sent to the user's UE 10 (e.g. via local API between a metaverse application running on the UE and underlying UE's hardware / software functions) and confirmed by the UE's SIM. Additionally or alternatively, a biometric authentication method may be invoked / triggered to be performed via the UE / HMD. Additionally or alternatively, the SIM credentials from the user's UE 10 may be invoked from within the metaverse using an API call from the metaverse to the portal device 20 (and then possibly to the UE 10 if the portal device is not itself a UE), i.e., the MVCD uses the SIM credentials on the user's UE as its SIM credentials (e.g., a non-access stratum (NAS) authentication response may be computed on the user's UE and then transferred to the MVCD), but all other aspects of the communication session may be handled by the metaverse servers (e.g., by operating / configuring an MVCD). In effect, the metaverse simulates an MVCD as if it has an internal SIM, but in this case the connection is via the portal device 20 to the real-world SIM on the UE 10. In a second option, UE 10 may already be registered to the network 40 or the network 40 is able to establish a link to the UE 10 (e.g. through network triggered registration). The network 40 (e.g. 5GC) may authenticate the UE 10 or may have authenticated the UE 10 already by authenticating credentials stored on the UE's (e)SIM (e.g., on behalf of a request received from a metaverse application and / or server, e.g. via NEF, which may e.g. contain a GPSI or metaverse / application-related identifier that may be recognized and / or linked to a 5G internal identifier such as SUPI by the 5GC) and, upon successful authentication of the UE 10, the network may provide an authenticated generic VoIP telephone number, or I MSI / SUPI or GPSI or other device identifier related to that UE 10 or metaverse / application- related identifier related to the user / UE to the metaverse servers. Additionally or alternatively, a biometric authentication method may be invoked / triggered to be performed via the UE / HMD. In a third option, a metaverse application running on the UE / HMD may trigger (e.g. through local API) the UE / HMD to register and / or initiate communication session with the network 40, upon which the UE's (e)SIM credentials will be used directly for performing authentication with the network. Additionally or alternatively, a biometric authentication method may be invoked / triggered to be performed via the UE / HMD.

[0124] Once the UE / user is authenticated and a connection between the UE and / or metaverse servers with the network has been established, the metaverse application running on the UE / HMD may initiate (e.g. through a local API or via NEF) calls or other communication session(s) from the MVCD / UE to other entities (e.g., other UEs), where the data related to the communication session / call or e.g. the display output, audio / video input / output, human interaction device (HID) input may be transferred between the MVCD and the UE, i.e. the 5G network communicates with the user's UE and the latter then sends / receives data to and from the metaverse application (e.g. via local API) hosting the MVCD, and the metaverse ap- plication / provider handles the communication links to the MVCD. The data related to the communication session / call between the MVCD / UE to the other entities (e.g., other UEs) may be transferred via a 5GC / IMS framework or transferred (e.g., over-the-top) via the metaverse application / servers, and may need to be end-to-end protected (e.g., encrypted and integrity- protected). According to a network policy / configuration of service level agreements, or the like, a metaverse application may be configured to route the communication session traffic (e.g., call) through the UE to thee 5GC / IMS framework or (e.g., over-the-top) via the metaverse application / servers and through a NEF to the 5GS (or both).

[0125] In a further embodiment that may be combined with other embodiments, the communications credentials may include a 5G generic VoIP-authenticated telephone number, or I MSI / SU PI or GPSI or other device identifier related to the UE 10 or metaverse / application- related identifier (e.g., related to the user / UE) or IMS related Private / Public Identity which the metaverse servers and / or the network (e.g., depending on how and where the MVCD, as a digital asset, is stored) may store and link / map to the user's MVCD. The 5G network 40 may be connected to the metaverse servers through a NEF or the Internet and the data may be routed from there, via the metaverse servers, to the user's MVCD. These communication credentials may be obtained via a credential exchange performed between a portal device 10 (e.g. head mounted display (HMD)) and the UE 10 (or a digital copy and / or representation of an eSIM of the UE 10 or a digital twin of the UE 10).

[0126] In a further embodiment that may be combined with other embodiments, the communications credentials or other device / user-specific credentials may include a set of parameters (e.g., cryptographic keys, nonces, (time) counters, access tokens) provided by the network 40 (e.g., 5GS) to the metaverse servers upon authenticating the UE 10 (or a digital copy and / or representation of the UE's eSIM or a digital twin of the UE 10) and / or upon requesting the invocation of an MVCD and / or upon requesting the establishment of a communications session with / via the UE or MVCD. The parameters may be used by the MVCD to request and / or derive security materials and establish a security context with the network 40 (e.g., 5GS).

[0127] In a further embodiment that may be combined with other embodiments, if a biometric method and / or results thereof are used, then, upon successful biometric authentication of a user by the network 40 or metaverse application or MVCD or the UE 10, the network 40 or metaverse application or the UE 10 may select (e.g., possibly based on user input, ownership status, authorization status (i.e., granted or not), subscription data or, policy) an MVCD that can be used by that user in the metaverse environment, and may provide a set of credentials or a reference to a set of credentials related to the (selected) MVCD that can be used by the metaverse application to establish communication sessions between the (selected) MVCD and the network.

[0128] In a further embodiment that may be combined with other embodiments, the UE 10 may send a request to establish a communications session and receive an access token from the network 40. The access token may be securely transferred to the MVCD, which then uses it (e.g., to authenticate to the network e.g., 5GS) to establish a communication link with the network 40 and establish a security context in the process. The MVCD may send a key request with the parameters provided by the UE 10 (e.g., access token) in addition to identifiers (e.g., MVCD identifier, UE's identifier e.g., GPSI) to a Virtual Communications Anchor Function (VCAF) (e.g., a SEAL Server) (e.g., through a NEF) and then establish a security context with the network 40, upon which, traffic intended for the UE 10 may be fully or partially routed towards the MVCD. Additionally, or alternatively, the MVCD may use information (e.g., parameters such as nonces, security materials, identifiers, etc) included in the access token, to derive the security materials (e.g., symmetric keys for confidentiality and integrity) to be used when communicating with the network 40.

[0129] In another embodiment that may be combined with other embodiments or operated independently, UE 10 and an MVCD associated with the same physical user may have separate subscriptions or a shared subscription but with different SUPIs linked to that shared description (with a separate set of credentials) and hence separate (e)SIM profiles associated with them. The (e)SIM profile for the MVCD may be provided to the MVCD as if the MVCD were a UE itself (even though it may just be an emulated UE running in software), e.g. by using its own credentials and bootstrap profile to register to an SM-DP+ server to obtain an (e)SIM profile. The UE and MVCD may be able to operate two separate connections with the network in parallel and / or whereby switching / steering and splitting of traffic between UE and MVCD may depend on whether a metaverse application is active on the respective UE device or not. Such switching / steering and splitting of traffic may be configured through a set of URSP, ATSSS or DualSteer policies (e.g. as specified in 3GPP TS 23.501 or TS 23.503).

[0130] In an embodiment that may be combined with other embodiments, the metaverse implementation 30 may comprise a metaverse network MVCD communication process (MV-NW MVCD-CP) capability 306 of creating representation of the MVCD (e.g., a 3D visual representation of a mobile phone) inside the metaverse to enable interaction with the user (e.g., speech interaction, gestures, invoking actions / commands / apps), whereby the metaverse application may run or render its output on an HMD (which may or may not be attached / connected directly to the UE 10). When a call is made to or from the MVCD, the metaverse implementation 30 may be configured to organize communications between the network 40 and the MVCD by directing data to and from the appropriate sources and / or destinations. For example, it may render A / V input received from other communication devices or from UE 10, e.g. during such call and / or generate A / V output from input received from one or more users or digital assets (e.g. avatar) related to a user, and application layer rendering information, and transmit such generated A / V output to other communication devices or to UE 10. This may depend on the MVCD instantiation process capability 304. As part of such MVCD-network communications, the MVCD may be authenticated (again) using the set of credentials that was established / received during the registration of the MVCD to the network 40.

[0131] MVCD credentials operated by the UE

[0132] In some cases, communication / network credentials may not be "transferred" to the MVCD or metaverse application / server, but instead MVCD credentials may be "transferred", or are already known, to the UE 10, and are subsequently used to establish a security context for communications between the network 40 and the MVCD. This may be performed as described in the following embodiments. In an embodiment that may be combined with other embodiments or used independently, the communications credentials or other device / user-specific credentials may use a method to link to the (e)SIM on the UE 10 via a local API and / or by using 3GPP protocols and an (initial) result of that link. In a first option, the network 40 (e.g., 5GC) may be connected to the metaverse servers which may interrogate the UE's (e)SIM via this link to establish its credentials using network protocols (e.g., 5G protocols) The metaverse servers and the UE's (e)SIM may communicate via this link such that network communication data which requires SIM authentication is sent to the user's UE 10 (e.g. via local API between a metaverse application running on the UE and underlying UE's hardware / software functions) and confirmed by the UE's SIM. Additionally or alternatively, a biometric authentication method may be in- voked / triggered to be performed via the UE / HMD. Additionally or alternatively, the SIM credentials from the user's UE 10 may be invoked from within the metaverse using an API call from the metaverse to the portal device 20 (and then possibly to the UE 10 if the portal device is not itself a UE), i.e., the MVCD uses the SIM credentials on the user's UE as its SIM credentials (e.g., a non-access stratum (NAS) authentication response may be computed on the user's UE and then transferred to the MVCD), but all other aspects of the communication session may be handled by the metaverse servers (e.g., by operating / configuring an MVCD). In effect, the metaverse simulates an MVCD as if it has an internal SIM, but in this case the connection is via the portal device 20 to the real-world SIM on the UE 10. In a second option, UE 10 may already be registered to the network 40 or the network 40 is able to establish a link to the UE 10 (e.g. through network triggered registration). The network 40 (e.g. 5GC) may authenticate the UE 10 or may have authenticated the UE 10 already by authenticating credentials stored on the UE's (e)SIM (e.g., on behalf of a request received from a metaverse application and / or server, e.g. via NEF, which may e.g. contain a GPSI or metaverse / applica- tion-related identifier that may be recognized and / or linked to a 5G internal identifier such as SUPI by the 5GC) and, upon successful authentication of the UE 10, the network may provide an authenticated generic VoIP telephone number, or I MSI / SU PI or GPSI or other device identifier related to that UE 10 or metaverse / application-related identifier related to the user / UE to the metaverse servers. Additionally or alternatively, a biometric authentication method may be invoked / triggered to be performed via the UE / HMD. In a third option, a metaverse application running on the UE / HMD may trigger (e.g. through local API) the UE / HMD to register and / or initiate communication session with the network 40, upon which the UE's (e)SIM credentials will be used directly for performing authentication with the network. Additionally or alternatively, a biometric authentication method may be invoked / triggered to be performed via the UE / HMD.

[0133] In another embodiment that may be combined with other embodiments or operated independently, UE 10 and an MVCD associated with the same physical user may have separate subscriptions or a shared subscription but with different SUPIs linked to that shared description (with a separate set of credentials) and hence separate (e)SIM profiles associated with them. The (e)SIM profile forthe MVCD may be provided to the UE 10, e.g. by using MVCD related credentials and bootstrap profile to register to an SM-DP+ server to obtain an (e)SIM profile. The (e)SIM profile may be fetched and stored on the UE's eSIM hardware (e.g., UICC) as a second (e)SIM profile next to a UE's own (e)SIM profile. In this case, the UE may offer a local API through which the MVCD / Metaverse application can gain access to and operate / use the MVCD's (e)SIM profile, whereby the UE and MVCD may be able to operate two separate connections with the network in parallel and / or whereby switching / steering and splitting of traffic between UE and MVCD may depend on whether a metaverse application is active on the respective UE device or not. Such switching / steering and splitting of traffic may be configured through a set of URSP, ATSSS or DualSteer policies (e.g. as specified in 3GPP TS 23.501 or TS 23.503).

[0134] Fig. 2 schematically shows a block diagram of a communications system with signaling for metaverse communication and close-out according to various embodiments.

[0135] As indicated by the arrows in Fig. 2, the biometric MVCD attachment functionality or means 3042 of the metaverse implementation 30 can invoke performance (BI+BP) of a biometric authentication by the UE portal biometric registration functionality or means 202 of the portal device 20, which returns biometric results (R) of the biometric method functionality or means 206 of the portal device 20 to the biometric MVCD attachment functionality or means 3042. As indicated by the dotted arrows, communication may then be performed between the metaverse network MVCD communication process capability 306 of the metaverse implementation 30 and the UE 10 directly or via the network 40.

[0136] When the user leaves the metaverse, the metaverse may activate / trigger an MVCD close-down (MVCD CD) functionality or means 308 configured to remove the presence of the user within the metaverse at the network 40. To achieve this, a UE metaverse communications close-down (UE-MV CD) functionality or means 108 at the UE 10 may be triggered by the MVCD close-down functionality or means 308.

[0137] In a first embodiment associated with metaverse session termination, which may be combined with other embodiments, the eSIM profile may be removed from its associated physical eSIM or emulated eSIM running on the metaverse servers and the user's UE 10 may reload the eSIM profile back onto the UE 10.

[0138] In a second embodiment associated with metaverse session termination, which may be combined with other embodiments, the protocol link from the metaverse to the user's (e)SIM on the UE 10 and the information related to that (e)SIM in the metaverse may be removed.

[0139] In a third embodiment associated with metaverse session termination, which may be combined with other embodiments, information of the telephone number of the user or I MSI / SU PI or GPSI or other device identifier related to the UE 10 in the metaverse and / or the related link to the network 40 (e.g., 5GC), e.g., via NEF, may be removed, so that the network 40 would no longer direct calls to that user's MVCD.

[0140] In all the above cases, communications credentials or biometric method / re- sults may be encrypted during transfer to the metaverse servers, whereby these servers may only be able to decrypt the data using established credentials (e.g., cryptographic key pair) associated with the concerned user (e.g., set up when the user initially sets up their account) , such that each MVCD operates in its own security domain. To ensure traffic between the UE 10 and / or the network 40 (e.g., 5GS) and MVCD is private and hence not visible to the metaverse servers, the MVCD may be pre-configured such that, when invoked, a fresh ephemeral public key pair is generated and used to establish security materials (e.g., session keys) to protect the communication links between the UE 10 and / or the network 40 and MVCD. Additionally or alternatively, to ensure that traffic between the UE 10 and / or the network 40 and metaverse application / server is private and hence not visible to other metaverse appli- cations / servers or entities within the metaverse, the metaverse application / server may be pre-configured such that, when invoked, fresh ephemeral credentials (e.g., public key pair) are generated and used to establish security materials to protect the communication links between the UE 10 and / or the network 40 and the metaverse application / server. In another embodiment that may be combined with other embodiments or operated independently, the MVCD may communicate (e.g. via a local API) a permanent identifier (e.g., SUPI, Metaverse application ID, Vertical Application Layer ID or NFT ID, or a digital asset identifier, or the like, or a combination of any two or more of the aforementioned ), or a generated transient ID associated with it (i.e., MVCD) to the UE / HMD, and possibly a set of communication credentials of the MVCD (e.g., after establishing an end-to-end secure communications link with UE / HMD). The UE / HMD may then request the establishment of a communications session with the network 40 (e.g., on behalf of MVCD), and relevant parameters (e.g., nonce, (time) counter, cryptographic keys, tokens) received from the MVCD are used to obtain / de- rive security materials (e.g., session dependent) that may subsequently be transferred back to the the MVCD via the end-to-end secure communication link. The UE may forward any further data received from the network to the MVCD in a transparent manner (i.e. without unprotecting it) via the end-to-end secure communication link or a new communication link, whereby the MVCD will decrypt the data from the network. Additionally, or alternatively, the UE (e.g., working as a relay) decrypts and verifies the data received from the network and forwards the decrypted data to the MVCD via the end-to-end secure communication link (e.g. by re-encrypting the decrypted data). The MVCD may protect follow-on data to be sent to the network, using established security credentials between MVCD and the network, or may protect data using established security credentials between MVCD and UE, such that the UE protects the data on MVCD behalf before sending it to the network. Additionally or alternatively, the MVCD identity information and / or set of security keys obtained from the network may be protected using security keys established only between the MVCD and the network, and hence cannot be decrypted / verified by the UE / HMD.

[0141] In a further embodiment that may be combined with other embodiments or operated independently, the UE may have stored (e.g. as part of its own subscription information stored in its (e)SIM profile, or may be able to fetch or receive configuration information from the network (e.g. through policy provisioning invoked by metaverse server via NEF)) an identifier of the MVCD (e.g., SUPI, GPSI, Metaverse application ID, or NFT ID (assigned by e.g., the metaverse store, in case the MVCD is an NFT) as described in previous embodiments) and / or a set of communication credentials of the MVCD, that may be used by the UE / HMD to establish of a communications session with the network 40. Additionally, or alternatively, the MVCD identifier and / or set of communication credentials of the MVCD may partly be stored by the UE and partly retrieved from the MVCD upon establishing the end-to- end protected communication link between the UE and MVCD. This ensures reliable freshness parameters (e.g., timestamp, random nonce, synchronization values) of the communication credentials pertaining to the MVCD are requested on-demand.

[0142] Terminating / de-registering the MVCD

[0143] Fig. 2 schematically shows a block diagram of a communications system with signaling for metaverse communication and close-out according to various embodiments.

[0144] As indicated by the arrows in Fig. 2, the biometric MVCD attachment functionality or means 3042 of the metaverse implementation 30 can invoke performance (BI+BP) of a biometric authentication by the UE portal biometric registration functionality or means 202 of the portal device 20, which returns biometric results (R) of the biometric method functionality or means 206 of the portal device 20 to the biometric MVCD attachment functionality or means 3042. As indicated by the dotted arrows, communication may then be performed between the metaverse network MVCD communication process capability 306 of the metaverse implementation 30 and the UE 10 directly or via the network 40.

[0145] When the user leaves the metaverse, the metaverse may activate / trigger an MVCD close-down (MVCD CD) functionality or means 308 configured to remove the presence of the user within the metaverse at the network 40. To achieve this, a UE metaverse communications close-down (UE-MV CD) functionality or means 108 at the UE 10 may be triggered by the MVCD close-down functionality or means 308.

[0146] In a first embodiment associated with metaverse session termination, which may be combined with other embodiments, the eSIM profile may be removed from its associated physical eSIM or emulated eSIM running on the metaverse servers and the user's UE 10 may reload the eSIM profile back onto the UE 10.

[0147] In a second embodiment associated with metaverse session termination, which may be combined with other embodiments, the protocol link from the metaverse to the user's (e)SIM on the UE 10 and the information related to that (e)SIM in the metaverse may be removed.

[0148] In a third embodiment associated with metaverse session termination, which may be combined with other embodiments, information of the telephone number of the user or I MSI / SU PI or GPSI or other device identifier related to the UE 10 in the metaverse and / or the related link to the network 40 (e.g., 5GC), e.g., via NEF, may be removed, so that the network 40 would no longer direct calls to that user's MVCD.

[0149] In all the above cases, communications credentials or biometric method / re- sults may be encrypted during transfer to the metaverse servers, whereby these servers may only be able to decrypt the data using established credentials (e.g., cryptographic key pair) associated with the concerned user (e.g., set up when the user initially sets up their account) , such that each MVCD operates in its own security domain. To ensure traffic between the UE 10 and / or the network 40 (e.g., 5GS) and MVCD is private and hence not visible to the metaverse servers, the MVCD may be pre-configured such that, when invoked, a fresh ephemeral public key pair is generated and used to establish security materials (e.g., session keys) to protect the communication links between the UE 10 and / or the network 40 and MVCD. Additionally or alternatively, to ensure that traffic between the UE 10 and / or the network 40 and metaverse application / server is private and hence not visible to other metaverse appli- cations / servers or entities within the metaverse, the metaverse application / server may be pre-configured such that, when invoked, fresh ephemeral credentials (e.g., public key pair) are generated and used to establish security materials to protect the communication links between the UE 10 and / or the network 40 and the metaverse application / server.

[0150] Detailed communication procedures using MVCD

[0151] Fig. 3 schematically shows a flow diagram of a metaverse communications procedure according to various embodiments. The steps of the flow diagram are described below based on the components, functionalities and capabilities indicated in Figs. 1 and 2.

[0152] Optionally, in step S301 (PR UE-PD), if the portal device 20 is not a UE, a user may pair the portal device 20 to the UE 10 using the UE portal biometric registration functionality or means 202, and the UE 10 may perform biometric registration (BR) enabling the biometric function 204 of the portal device 20 to be called from the UE 10.

[0153] In step S302 (BMP + BRP + CP), if the UE 10 supports biometric authentication, then the UE 10 may carry out biometric method packaging at the biometric method packaging functionality or means 1024 to obtain a biometric method packet, may invoke the biometric function 204 at the portal device 20 via its biometric registration functionality or means 1022, and may subject a received biometric result to its biometric result packaging functionality or means 1026 to obtain a biometric result packet. The UE 10 may further generate communications credentials or other user / device specific credentials (e.g. based on the UE's (e)SIM profile) and may use its credentials packaging functionality or means 104 to obtain a communications credentials or device / user specific credentials packet.

[0154] Then, in step S303 (EACG), the UE 10 may use the biometric method and / or result packet, the communications credentials or device / user specific credentials packet and / or a unique metaverse ID forgenerating an extended authentication code by its extended authentication code generation functionality or means 106 and may use this extended authentication code for authentication to log into the metaverse implementation 30.

[0155] In step S304 (ST EAC), the metaverse implementation 30 may store the extended authentication code in association with the user.

[0156] In step S305 (MVCD), the user (if not done yet) may obtain an MVCD, which is registered to him / her in the metaverse implementation 30 or the network 40 (e.g., 5GC), e.g., as part of a subscription information, and / or in the UE 10, e.g., as MVCD identity stored in (e)SIM.

[0157] In step S306 (B MVCD-A), the metaverse implementation 30 may use its biometric MVCD attachment functionality or means 3042 to enable the MVCD to call the invoke biometric method functionality or means 206 of the portal device 20 based on information extracted from the extended authentication code.

[0158] In an alternative or additional step S307 (CC MVCD-A), the metaverse implementation 30 may use its communication credentials MVCD attachment functionality or means 3044 to attach the user's communication credentials or other device / user-specific credentials extracted from the extended authentication code to the MVCD (to attach credentials to a (selected) MVCD of the user).

[0159] In step S308 (MVCD-NW REG), the metaverse implementation 30 may use its MVCD-network registration functionality or means 3046 to register the MVCD with the network 40 (i.e., to register MVCD credentials such that it is visible to the network 40 (e.g., 5G network)).

[0160] In step S309 (MVCD-BI), when the user logs into his / her MVCD in the metaverse implementation 30, the metaverse implementation 30 may call the associated MVCD biometric method invoked by the invoke biometric method functionality or means 206 of the portal device 20 to obtain a biometric result to enable authentication on the MVCD (or not).

[0161] In step S310 (AUTH MVCD), when a call is made or other communication session is set up to or from the MVCD, the metaverse implementation 30 may use its MVCD- network communications capability 306 to authenticate the MVCD on the network 40 and to send or receive data from sources / destinations depending on the communication credentials embodiment.

[0162] Thus, the metaverse implementation 30 may initiate a use of the MVCD, e.g., upon successful registration of the MVCD with the network 40. When a call is made to / from or via the MVCD, the metaverse implementation 30 may use its MVCD-network communications capability 306 to send or receive data from sources / destinations. In an alternative step S310, the MVCD requests (e.g. through local API) the UE / HMD to establish the call / communi- cation session on its behalf using the mechanisms as described in earlier embodiments.

[0163] In step S311 (MVCD CD), when the user logs out of the metaverse implementation 30, the metaverse implementation 30 may initiate a signaling generated by its MVCD close-down functionality or means 308 towards the UE metaverse communications closedown functionality or means 108 of the UE 10, which may include removing the user's eSIM profile from its associated physical eSIM or emulated eSIM running within metaverse servers and / or may include reloading the eSIM onto / within the user's UE 10.

[0164] In an embodiment variant, the real-world device (e.g., portal device 20) allowing a user to operate in a metaverse may be a UE itself or may link to a UE (e.g., the user's UE 10, e.g., smartphone). A biometric method on the portal device 20 may be registered with the UE 10 for that user as the biometric method. The communications credentials plus the user unique metaverse ID may be formed into an authentication measure, along with the biometric result, for entry into the metaverse.

[0165] In an embodiment variant, within the metaverse, a user may be able to obtain or instantiate an MVCD, e.g., provided by the metaverse application / provider, or purchased e.g., from a metaverse store, which, when used, may take the communications credentials and biometric method, obtain a real-world biometric (e.g., invoking the portal device 20 and / or the UE 10) for authentication, and a communication from that device may then be 'tunneled' to the network 40, as if it originated from the UE 10. In an embodiment variant, the metaverse implementation 30 and / or the UE 10 (e.g., with HMD) may need to be configured to provide a communication interface or API to trigger and / or call and / or initiate a biometric method on the portal device 20 (e.g., VR glasses) (e.g., perform sensing of brain waves, iris scan, voice or face scan etc.) for example by sending a message or invoking an API call, whereby the message or API call may include security information (e.g., secret key) and / or a user identity. After receiving the message or API call, the UE 10 may invoke a biometric scan on the portal device and the UE 10 may perform the biometric method. This may include a comparison with a biometric associated with a certain user or a user identified by the given user identity. A result (e.g., biometric method and / or result or biometric result package), e.g. a user identity, or a binary information (e.g., true or false) as to whether the result matches a given user identity, or a biometric measurement may be suitably encrypted and integrity-protected with the security information (e.g., secret key) and passed back to the metaverse implementation 30, where it may be decrypted, integrity-verified, and checked.

[0166] Therefore, the biometric functionality of the metaverse implementation 30 may involve a method and / or link for invoking the biometric scan and result (such as an API call to the portal device 20) and security information (security materials) for decrypting the protection of biometric method results. Furthermore, in the metaverse implementation 30, a user identity and / or a set of security materials (e.g., keys or the like) may be associated with an MVCD. At appropriate times (e.g., accessing the device after some time period has lapsed, for secure logins etc.) the metaverse implementation 30 or MVCD may invoke the biometric method, undo the protection of the results and thereby determine if the biometric is correct and matches a given user.

[0167] It should be noted that handing over of an MVCD to another metaverse user may then invoke the biometric method on the MVCD's owner and may therefore not represent a correct authentication. Therefore, the metaverse implementation may comprise a policy (e.g., determined by metaverse service provider or a network operator) ensuring that a biometric call is prevented (or returns an error message) when the MVCD is 'shared'. Therefore, a sharing of the MVCD needs to be noted and / or registered by the MVCD, as its behav- ior / functionality may change depending on whether it is shared or not.

[0168] In an embodiment variant, the eSIM of a user's UE may be cloned into the MVCD, e.g., by the metaverse application / provider hosting the eSIM profile on a physical eSIM or on an emulated eSIM and using this eSIM in the 5G communication process, with communication being routed between the metaverse servers and the 5G network. This may involve invoking a function on the UE (e.g., by a trusted entity such as a 5GC or API call from an authorized metaverse application or the UE's operating system) that can read the eSIM's profile information and / or the data files stored on the eSIM's file system and create a copy of the eSIM profile for use by the metaverse application. A communication channel between the digital copy and / or representation of the eSIM profile in an emulated eSIM or physical eSIM hosted by the metaverse application / provider may need to be established with the UE that has stored the eSIM in a secure hardware element to invoke necessary security processes and communicate the results back and forth. This communication channel may be protected using security mechanisms as described in other embodiments. Additionally, or alternatively, the UE may provide an identity and / or link to a digital copy and / or representation of the eSIM (e.g., an address of a Subscription Manager Data Preparation (SM-DP+) server on which the respective UE's eSIM profile is stored) and may include credentials (e.g., information from an eUlCC bootstrap profile) to the metaverse application, to enable the metaverse application to fetch the eSIM. Fetching a clone of the eSIM by the metaverse application may include forwarding messages between the SM-DP+ server and the UE's eSIM to enable proper authentication (e.g. a metaverse application operating an MVCD may use a local API on the UE to forward authentication requests from the SM-DP+ server to the UE's eSIM, and the UE may return the respective authentication responses to the metaverse application operating the MVCD which may forward the information to the SM-DP+ server). The use of a UE's eSIM profile may be bound to a limited time period (e.g., one hour or a single metaverse application session), after which an MVCD close-down operation may be performed.

[0169] In an embodiment variant, a pairing may be performed between the user UE and the MVCD such that they can exchange data in a secure manner in both directions. Communication between the 5G network and the user's UE may therefore be performed and the data may then be routed from the UE (or via the portal device), through the metaverse service provider server, to the MVCD (e.g., instantiated within the metaverse servers). When operating on the MVCD, users are then actually interacting on their UEs.

[0170] In an embodiment variant, authorization may be required from the user and / or the 5GS to route user communication through the metaverse servers onto an MVCD. Such authorization may for instance be pre-configured to a default option in the user's subscription data (e.g., as part of a user's privacy profile), wherein the default behavior may be set to e.g. authorize, ask before authorizing, or deny the automatic routing of communication traffic upon establishing a link between the MVCD and 5GC. Note that this may either concern all, or part, of the communication traffic intended for the UE and / or MVCD.

[0171] In an embodiment variant, a generic Internet-based (e.g., VoIP, data-over-IP etc.) extension of the 5G system may be established such that (contact) numbers indicated to the 5G network can be present and accessible by the metaverse application / servers, given sufficient authentication. Such (contact) numbers may be the same as the user's UE telephone number or the like. The metaverse service provider may indicate to the 5G network, or a component thereof, that the number is present on their servers (i.e., in the metaverse) and the 5G network may route calls or data communication via the metaverse servers to the MVCD, as described in other embodiments. In this case, it may be possible / probable that an incoming call is routed by this process to the MVCD and also via the standard 5G network to an associated UE, unless the 5G network and / or the UE are subject to a policy / configuration disabling this duplication of communications and / or its related notifications whilst an MVCD is established. As an example, a field (e.g., flag) may be provided in the subscription data of the UE, and / or network / metaverse provider definedpolicy, to indicate that when a communication session (e.g., call) is routed to an MVCD / UE, it may (or may not) also be routed to the UE / MVCD, or at least a notification thereof is transmitted (or not) to the UE / MVCD (e.g., during the time that the UE and / or MVCD are involved in and / or connected to / used in a metaverse application).

[0172] In an embodiment variant, implementation of a metaverse-to-network communication 'tunnelling' may be performed via standardized metaverse APIs linking with the 5G network through an external interface offered by the 5G network e.g. an NEF. Such communications may be provided from the 5G network to the metaverse servers and hence to the user and / or user's portal device, from the 5G network to the metaverse servers (whereby the metaverse servers may communicate with the UE SIM (e.g. through a local API on the UE such as a SEAL client) as part of the communications process), and / or from the 5G network to the user UE and / or to the portal device and hence to the metaverse servers (e.g., VAL servers).

[0173] MVCD as digital asset, and linking to IMS In an embodiment that may be combined with other embodiments or operated independently, a list of registered MVCDs for a user and / or a selection thereof (e.g., for use in a specific metaverse application) may be stored as part of a user's profile which is associ- ated / linked with a subscription and which may be stored by the 5GC (e.g., in the Unified Data Management (UDM) or the Unified Data Repository (UDR)) and / or may be stored as part of the user's subscription data (e.g., stored in the UDM / UDR), or a digital asset repository e.g., as part of a SEAL server hosted by the network as specified in 3GPP TS 23.434 / TS 23.438, or Base Avatar Repository (BAR) as specified in 3GPP TS 23.228). The list of registered MVCDs may include an identifier of the MVCD, a storage location (e.g. URL, or database query) and / or metadata or a description of the MVCD. The 5GC may provide information about the registered MVCDs and / or a selection thereof to a metaverse application (e.g., via NEF, or via the UE (e.g. via local API) or a specific network-metaverse application interface), for example after successfully authenticating the UE of the user, after authenticating the user (e.g., using biometrics), or after a request received from a metaverse application (e.g., VAL server) (e.g., via NEF), whereby the request may include a GPSI, user identifier, application identifier, or other identifier related to the subscription, and may include credentials that allow access to this information (e.g., a biometric result from a biometric identification of the user). Additionally or alternatively, the above mentioned list of registered MVCDs or a subset thereof (e.g. the currently selected MVCD) may be stored as part of the UE's (e)SIM or configured on the UE through a policy (e.g. using UE Parameter Update or UE Configuration Update procedures as specified in 3GPP TS 23.501), whereby the stored information may be made available to an application on the UE (e.g., VAL client) through a local API. Additionally or alternatively, the above mentioned list of registered MVCD or a subset thereof (e.g. the currently selected MVCD) may be stored as part of an avatar repository or digital asset repository that is associated with or that is made available to or that is part of the IMS framework, such as the avatar repository as described in solution #23 and #25 of 3GPP TR 23.700-77, also known as Base Avatar Repository (BAR) as specified in 3GPP TS 23.228. When an AR / VR or avatar communication session is set up between the UE (and / or MVCD) and a UE (and / or MVCD) of another user, the IMS framework can access the respective avatar / digital asset repository to obtain the list of registered MVCD or a subset thereof (e.g. the currently selected MVCD), or alternatively the respective avatar / digital asset repository provides the list of registered MVCD or a subset thereof to the IMS framework. The UE (and / or MVCD) may include information about which MVCD(s) should be used as part of the communication session, e.g. by including an identifier of the MVCD, a storage location (e.g. URL, or database query) and / or metadata or a description of the MVCD during communication session setup (i.e. using the IMS framework). In this way, the list of MVCDs or subset thereof (e.g. the currently selected MVCD) can be made part of the rendering of the scene and / or user's avatar during AR / VR or avatar communication session, e.g for rendering at a UE , the network, or a 3rdparty metaverse service provider, for example using UE-centric or network-centric rendering as described in Annex AC.9 or AC.11 of 3GPP TS 23.228, or (authorized) 3rdparty metaverse service provider-centric rendering.

[0174] Generic section on user consent for use of digital assets

[0175] In another embodiment that may be combined with other embodiments or implemented independently, access to information about the user or UE, such as a user's digi- tal / virtual assets (e.g., MVCD) by a metaverse application (e.g., via NEF, or local API / interface) or other entities (e.g., 5G network entities, such as IMS framework for example for rendering a user's digital / virtual assets such as MVCD onto another user's UE, or by metaverse service provider) may be subject to the user's consent, which may be based on a generic policy (e.g., defined by the 5G network or network operator) and / or defined based on user preferences (e.g., as part of a user's privacy profile) and / or be requested from the user on a case-by-case basis (e.g., by the core network (e.g., Access and Mobility Management Function (AM F)) requesting input from the user of the UE by sending a notification request to the UE or by a metaverse application requesting for user confirmation through a local API). Before sharing information about the user or UE, such as sharing of the user's digital / virtual assets (e.g., MVCD), the 5G network or UE may need to check whether or not the information can be shared with a metaverse application or other entity by verifying whether or not user consent for sharing the information is required and / or whether it is granted. If the information is subject to user consent, the 5G network or UE may be configured to access and check user preference information stored in relation to sharing the respective information. The stored user preference information may indicate that sharing with a particular metaverse application or other entity or other user is allowed or disallowed and / or that user confirmation is requested (e.g., by sending a notification to the UE, which the user can then confirm or reject). The user preferences (including e.g. whether or not to send a notification for user confirmation or rejection to the UE) may be stored by the network (e.g., in the UDM / UDR) as part of a user's profile which is associated / linked with a subscription, or may be stored as part of a user's privacy profile within a user's subscription data, or may be stored directly as part of the user's subscription data, or as part of metadata associated with the digital asset in question (e.g., the MVCD)(e.g. stored in a digital asset / avatar repository). Additionally or alternatively, the user preferences may be stored at a user's UE. Additionally or alternatively, an invocation of a local API by a (metaverse) application (e.g., VAL client) running at the UE that directly or indirectly requires sharing information (e.g. information about digital / virtual assets) for which user consent is required, may trigger checking the user preferences stored in the network or UE and / or requesting confirmation (e.g. through a user interface dialog with the user using the display of the UE or by rendering a user interface dialog with the user within the metaverse (e.g. on the MVCD virtual display)) by the user (e.g., through SEAL client), before the information is shared with the respective (metaverse) application (e.g., VAL server). Additionally or alternatively, the (metaverse) application (e.g., VAL client) may be required to perform an authentication / authorization step, e.g. with the UE's operating system or UE's (e)SIM (for example by providing a secure token), and / or require specific operating system permissions / privileges (e.g. Android application permissions) before accessing certain local APIs or certain local API method calls.

[0176] Particular examples of user preference information in case of metaverse applications that may be stored as part of a user's privacy profile and / or part of a user's subscription (e.g., on the network side) and / or as part of metadata associated with the digital asset in question and / or at the user's UE may include:

[0177] • preferences related to sharing of information about a user's digital / virtual assets (e.g., list of MVCDs or avatars registered for a user, or a preferred MVCD or avatar to use, or access to information about which digital / virtual assets (e.g., virtual objects / enti- ties for use in the metaverse, NFTs, tokens, games, extra features) the user owns, information about a user's purchase history, or information stored in a digital wallet) and / or rendering thereof (e.g. rendering at another user's UE or rendering inside a metaverse application (i.e., by metaverse service provider), or rendering by the network);

[0178] • communication preferences for calls or data communication sessions between the UE or MVCD and other entities e.g., other UEs / MVCDs (e.g., which avatar to use in communication (for example in an AR / VR or metaverse communication session with another user), which language to use or translate the communication into, QoS parameters, etc);

[0179] • preferences related to sharing contact information of the user (e.g., phone numbers of friends / acquaintances), which may be subdivided into contact information stored in the UE for communication outside the metaverse and metaverse contact information stored in the UE or MVCD or metaverse or 5GC about contacts within the metaverse (e.g., other metaverse users), or related to sharing information of blocked contacts and / or telephone numbers;

[0180] • preferences related to sharing call history and / or usage data information of the user, which may be subdivided into call history and / or usage data information stored in the UE for communication outside the metaverse and metaverse call history and / or usage data information stored in the UE or MVCD or metaverse or 5GC about call history / usage data within the metaverse (e.g., with other metaverse users);

[0181] • preferences related to sharing information about which metaverse applications the user has subscribed to and / or registered with (e.g., a metaverse applica- tion / provider (e.g., a first VAL server) may not be allowed to access information associ- ated / related to a user's (history of) use of other metaverse applications / providers (e.g., a second, or more, VAL server(s);

[0182] • preferences related to which other users in the metaverse (e.g., users involved (or not) in a shared activity e.g., multi-party communication session / call ) are allowed to access to the data (i.e. perceptual output / input data such as visuals, sounds, etc) pertaining to the shared activity e.g., the (multi-party) communication session / call running on the UE and / or MVCD; In an example, this may include preferences related to which other users in the metaverse (e.g. which users involved in a shared activity / application or users not involved in a shared activity / application) are allowed to hear / see the data (i.e. output / input data) of an application (e.g. chat application) running on the UE or MVCD; and / or

[0183] • preferences related to sharing information related to biometric methods and / or results thereof or other biometric data of the user, 5GS authentication creden- tials / information, user / UE / MVCD related identities, and / or username / password, or generally any type of credentials that are associated with the UE, user, and / or MVCD. As mentioned earlier, these preferences may include information about whether a confirmation by the user (e.g. through a user interface dialog) is to be requested for one or more of the stored privacy preferences. Additionally or alternatively, the preferences may include information or general policy parameter that indicates that a confirmation by the user is to be requested for one or more privacy parameters for which no privacy preference is stored. After the user has confirmed or declined a privacy parameter (e.g. related to one or more of the stored privacy preferences, e.g. whether or not sharing information related to a digital asset is allowed or not), the result of the confirmation / declination may be stored as part of the stored privacy preferences for subsequent verification of the respective privacy parameter.

[0184] Such user preferences may be provided / stored per metaverse application e.g., VAL server (e.g., user preferences may hold for a particular metaverse, but not for another one) and / or per UE / MVCD and / or per area / location (e.g. geographical area / location or area / location within a virtual environment (e.g. a set of coordinates or play area or shared interaction space within the metaverse virtual object space) or per PLMN and / or non-public network (NPN) (e.g., different for Home PLMN (HPLMN) versus Visitor PLMN (VPLMN)) and / or network entities within a PLMN or NPN, or per usage scenario (e.g., emergency call or normal call) or per set of users. Additionally or alternatively, the user preferences may be associated with a set of metaverse applications (e.g., a set of metaverse identifiers for which sharing the related information is allowed or disallowed) and / or with a certain set of UEs / MVCDs and / or with a set of areas / locations (e.g. geographical areas / locations or areas / locations within the metaverse (e.g. a set of coordinates or play area or shared interaction space within the metaverse virtual object space) and / or with a set of PLMNs / NPNs and / or network entities within a PLMN or NPN , and / or with a set of usage scenarios and / or with a set of users (e.g. other users / UEs involved in a shared activity in the metaverse, or part of an AR / VR / avatar communication session) for which these user preferences apply.

[0185] In other words, it is proposed a method, system and device comprising storing privacy preferences for use of digital / virtual assets and other privacy sensitive information of a user, including one or more of: sharing information about digital / virtual assets to metaverse applications and / or to other users in the metaverse and / or rendering of digital / virtual assets in metaverse applications, and / or by the network, and / or at other users' UEs; sharing contact information, communication preferences, communication history and / or usage data stored in the UE or MVCD with metaverse applications and / or with other users in the metaverse; sharing audio / video input / output of an application running on, or a communication session / call from, a UE or MVCD with metaverse applications and / or with other users in the metaverse; or sharing information related to biometric methods and / or results thereof, or other biometric data of the user, or 5GS authentication credentials / in- formation, user / UE / MVCD related identities, and / or username / passwords, and / or any credentials associated with the UE, user, and / or MVCD with metaverse applications and / or with other users in the metaverse.

[0186] It described a method whereby, the sharing preferences of information pertaining to a user, UE, MVCD, a set of digital assets, or data related to at least one of them, or a subset thereof, may be stored as part of a user / UE subscription data and / or UE policy or UE configuration, or in relation to a (set of) metaverse application(s) or in relation to a particular UE / MVCD or in relation to an area / location in the virtual environment or in relation to a PLMN or non-public network (NPN) and / or network entities within a PLMN or NPN, or in relation to a usage scenario or in relation to a set of users.

[0187] It is described a method, system and device further comprising retrieving the preferences for sharing information (or subset thereof), pertaining to a user, UE, MVCD, or data related to at least one of them, based on a request from a (metaverse) application or 5G network entity or a UE's operating system or another UE / user, to share one or more digital / virtual assets and / or other privacy sensitive information of a user with the requesting (metaverse) application, 5G network entity, UE's operating system and / or another UE / user, whereby it is verified by the UE / MVCD / user or against a policy / configuration whether or not sharing of the requested information (or subset thereof) is allowed or not, where if allowed, the method may comprise sharing the requested sharing information and if not allowed, not sharing the requested information or providing an error message.

[0188] MVCD as a holographic display Fig. 4 schematically shows an example of an instantiation of an MVCD 50 as a holographic display, according to an embodiment.

[0189] A user with HMD (e.g., VR glasses) 22 as portal device wishes to instantiate the MVCD 50 as holographic display that creates a hologram 52 in a metaverse 32. To achieve this, the HMD 22 pairs with a mobile phone (UE) 12 of the user and initiate a biometric registration process (REG). Biometric information (BIO) is obtained and collected by the HMD (22) and / or the UE (12). Collected biometric information (COLL) from the HMD / UE 22 / 12 and e- SIM information from the mobile phone 12 are provided to the metaverse 32 to allow instantiation of and communication with the MVCD 50 with support of a wireless network 40 (e.g., a 5G network) to which the mobile phone 12 is subscribed, as described in embodiments herein. The user may now communicate with the MVCD (i.e., holographic display) via the HMD 22 and the mobile phone 12 to create the hologram 52.

[0190] Network-MVCD communication link establishment

[0191] Fig. 5 schematically shows a processing and signaling diagram of a procedure for establishing a call, communication link and / or session, according to an embodiment.

[0192] The diagram indicates involved network entities (i.e., a UE 501 (e.g, a VAL client), a 3GPP system (e.g., 5GS) 502, an authentication server function (AUSF) 503 (e.g., integral part of 502), a virtual communication anchor function (VCAF) 504 (e.g., an application function which may be an integral part of 502, or an external AF in the data network, or a SEAL server), a metaverse application / provider (e.g., VAL server) 505, and an MVCD (e.g., digital asset) 506) at the top, wherein arrows indicate a possible successive message flow in timedependent order and wherein blocks indicate processing steps with time passing from the top to the bottom. It is worth noting that not all steps may be executed, some steps may be repeated, skipped, or performed in a different order.

[0193] The AUSF 503 is a 3GPP compliant network function of 502, which provides access and management support for 5G services. 503 is used for secured network access and may be responsible for the security procedure for SIM authentication using the 5G-AKA authentication method, or the like. In 502, it may perform various actions, such as handling routing based on SUCI and SUPI, managing authentication confirmation timeout, supporting a re-synchronization procedure, triggering home network based (re-)authentication procedure, perform key derivation (e.g., based on K_AUSF) during an authentication procedure.

[0194] The VCAF 504 is another network function that may be hosted within / outside of 502, which handles the communication session establishment for virtual communication. A VCAF may be introduced in 502 to facilitate the deployment of MVCDs and establishment of communication links between 502 and 506 through 505.

[0195] In the diagram of Fig. 5, a call or communication link and / or session is established as follows:

[0196] In step 510, the UE 501 is authenticated to the 3GPP system (e.g., 5GS) 502.

[0197] Then, in step 511, using the extended authentication code, as described in previous embodiments, which may include / incorporate a biometric result, communication credentials and / or metaverse credentials (e.g., username / password, and / or digital wallet ID, and / or an access token e.g., SBT / NFT, or VAL client / server ID, etc.), the user authenticates with the UE 501 to the metaverse application / provider 505.

[0198] In step 512, upon authentication to a metaverse session with the metaverse application / provider 505, the user may invoke the MVCD 506 using an MVCD instantiation process (e.g., as described in connection with the MVCD instantiation process capability 304 of Figs. 1 and 2). In an example of the MVCD instantiation process, the MVCD 506 (or the metaverse application / provider 505) may be provided with a public / encapsulation key (e.g., received from the UE 501 or the 5GS 502) which is subsequently used to establish a shared symmetric key.

[0199] In step 513, upon initiation, the MVCD 506 (or the metaverse application / provider 505) generates an (ephemeral) public key pair, and using the public key provided in step 512 and its ephemeral private key or a key encapsulation mechanism (e.g., ML-KEM), the MVCD 506 (or the metaverse application / provider 505) derives a shared symmetric ephemeral key (e.g., K) that may then be used to derive ciphering and integrity protection keys (e.g., K_enc, K_int) . The MVCD 506 may also randomly generate, or be assigned a bitstring (BS_1), which may subsequently serve as the least significant bits / bytes (LSBs) and / or most significant bits / bytes (MSBs) of the session ID. The bitstring may be protected (e.g., ciphered and integrity-protected) using K_enc and K_int. In addition to the protected bitstring, the MVCD 506 may also include a (permanent) identifier and / or a transient ID of the MVCD 506 and / or an identifier of the metaverse application / provider 505, and its ephemeral public key or a ciphertext encapsulating a secret key in a message to the UE 501 or the 5GS 502. This message may e.g. be a message with a request to initiate a communication session (e.g., an IMS communication session between the MVCD 506 (or the metaverse application / provider 505) and another entity(e.g. an MVCD or UE of another user) or to invoke a credential (e.g., bio- metric) / authentication exchange.

[0200] In step 514, the MVCD 506 sends the protected message to the UE 501 e.g., through 505 and / or the 5GS 502.

[0201] In a subsequent step 515, the UE 501 or the 5GS 502 receives the message and uses the MVCD's public key or ciphertext (received together with the message in step 514 or that it may have received earlier or via / from another entity (e.g., UDR, NEF) along with its private (or decapsulation) key to derive the shared symmetric key (K), and then derive the ciphering and integrity keys (K_enc, and KJ nt). The UE or 5GS (e.g., a core network function such as the AUSF 503) may then decrypt the protection of the bitstring sent by the MVCD 506 (or the metaverse application / provider 505), and / or the MVCD's (or metaverse applica- tion / provider's) permanent / transient ID. The UE 501 or the 5GS 502 may then randomly generate or be assigned (in case of UE) a bitstring (e.g., BS_2) which may be concatenated with BS_1 to construct a session ID.

[0202] In step 516, the UE 501 may use the information obtained in step 515 (e.g., the constructed Session ID and / or the MVCD's permanent / transient ID and / or other information received in step 515 from the MVCD 506 or the metaverse application / provider 505 to request establishment of a communication session (e.g., by the UE 501 sending a protected message to the 5GS 502 containing the indicated information). Additionally, or alternatively, UE 501 may be requested to use its own credentials for setting up a communication session, on behalf of the MVCD, as described in other embodiments. In that case, steps 513, 514 and 515 may be optional.

[0203] In step 517, the 5GS 502 verifies whether the user and / or the UE 501 and / or the MVCD 506 and / or the metaverse application / provider 505 is / are authorized to establish a communications session (e.g., verify whether it / they is / are subscribed to a metaverse communications service) and / or whether the user is authorized to use the MVCD 506 associated with the received MVCD ID (e.g., the UDR may keep a record and / or have access to a ledger / digital asset repository which associates UEs / users with digital / virtual assets (e.g., SBTs, NFTs) they own). Upon successfully verifying that it / they is / are authorized to establish a communications session and / or whether the user is authorized to use the MVCD 506 associated with MVCD ID to establish a communications session, the AUSF 503 may derive a related communications anchor key (e.g., K_VC) based on K_AUSF and UE's and / or MVCD's identifiers or subscription identifier related to the metaverse application / provider 505 and / or the session ID, or the like. Additionally, the AUSF 503 may derive a communications session temporary identifier (e.g., VCS_TID) based on K_AUSF and the session ID received in the previous step. A mapping between UE identifier (e.g, SUPI), MVCDJD, session ID, VCS_TID may be maintained (cf. step 520 below). Additionally, 502 (or a NF therein) may determine through which route the communication session may be established (e.g., through UE-metaverse service provider server(s), or directly through metaverse service provider) between the network and MVCD.

[0204] In step 518, upon successfully verifying authorizations of the user and / or the UE 501 and / or the MVCD 506 and / or the metaverse application / provider 505 and deriving K_VC and VCS_TID, the 5GS 502 may send an acknowledgment to the UE 501 or to the metaverse application / provider 505 to initiate the communications session, e.g. with the MVCD 506.

[0205] In step 519, based on K_AUSF, and the other parameters detailed in step 517 (e.g., UE's SUPI, MVCD identifier, and the constructed session ID, etc), the UE 501 may derive K_VC and VCS_TID.

[0206] Then, in step 520, the AUSF 503 may transfer the security context (e.g., security materials and identifiers such as K_VC, VCS_TID, MVCD ID, Session ID, and SUPI) to the VCAF 504 which handles the communication session establishment with the MVCD 506 and other entities. Note that this may be performed following the derivation of the aforementioned parameters in step 517, and does not necessarily depend on steps 518 or 519.

[0207] In step 521, the UE 501 may provide the MVCD 506 with the security materials and identifiers (i.e., K_VC, VCS_TID, Session ID, and HNJD) derived in steps 515 and 519 protected (e.g., ciphered and integrity protected) using the end-to-end security keys K_enc and KJ nt.

[0208] In step 522, upon receiving the security materials and identifiers, the MVCD 506 may derive a communication session key K_VCS based on the received K_VC and Session ID. Then, it may send a communications initiation message to the VCAF 504 containing VCS_TID and the session ID protected (e.g., ciphered and / or integrity protected) using K_VCS and / or keys derived therefrom (e.g., K_VCSenc, K_VCSint).

[0209] In step 523, the VCAF 504 may retrieve the security context associated with VCS_TID, and based on K_VC and session ID it may derive K_VCS and / or the ciphering / integ- rity keys derived therefrom (e.g., K_VCSenc, K_VCSint). Then the VCAF 504 may unprotect (e.g, decrypt and verify the session ID, VCS_TID and their association with MVCD ID and the UE 501. Upon successfully verifying that they are associated with the security context identified by VCS_TID, the VCAF 504 may initiate a communications session by rerouting traffic towards the MVCD 506 and use K_VCS as the security root key and the security keys derived therefrom (e.g., K_VCSenc, _VCSint) to protect traffic (e.g., UP data).

[0210] In an embodiment variant, the session ID may be partially or fully determined by the 5GS 502 and provided to the UE 501 (e.g., in step 518), which then forwards it to the MVCD 506 (e.g., in step 521).

[0211] In another embodiment variant, the VCAF 504 may derive K_VCS and the keys associated with / derived from it before receiving the request from the MVCD 506. The security materials may be provided to a Lawful Interception Network Function (LI NF) and only upon receiving an acknowledgment from the LI NF the VCAF 504 may establish the communications session with MVCD 506 and start routing traffic towards it.

[0212] In an embodiment variant, in step 517, upon successful verification of user authorizations, the 5GS 502 may provide the UE 501 with an access token in step 518, which is forwarded and used by MVCD 506 (e.g., in step 522) to establish a security context. It is worth noting that this may require a link between the MVCD 506 and the 5GS 502 to be end-to-end protected, e.g., steps equivalent to 512, 513, and 514 may be performed between the MVCD 506 and the 5GS 502 prior to sending the access token to the 5GS 502. For instance, the UE 501 (in step 521) provides the MVCD 506 with the public / encapsulation key of the home network (e.g., HPLMN), the MVCD 506 derives a shared symmetric key and / or other keys e.g., for ciphering / integrity protection, and uses it / them to protect the access token, which is then transmitted along with MVCD's public key / ciphertext to the 5GS 502. The VCAF 504 may then transfer the access token to the 5GC (e.g., UDM) which de-conceal / decapsulates the secret key it and verifies the unprotected VC access token validity. Upon successful verification, the 5GC authorizes traffic to be routed toward the MVCD 506. In another embodiment that may be combined with other embodiment or used independently, the root of security (e.g., equivalent to long-term key K) to be used by the MVCD may be a metaverse service / application-specific key (K_ms) derived from a Master Key (MK) maintained by both the network and the UE, and using as input parameters one or more, or a combination of parameters that include, but are not limited to, the following: metaverse provider (VAL server) and / or application (VAL client) ID, Service Application Enabler Layer (SEAL) server / Client ID, synchronization value (e.g., similar to SEQ maintained by USIM), fresh value (e.g., random nonce), session ID, MVCD ID, SUPI (e.g., IMSI / NAI), User Identity, etc. whereby the key (K_ms) is derived by the USIM / UE and used (e.g., if the HMD is the UE hosting the USIM itself), or provided to a second UE (e.g., HMD) or to the MVCD through the end-to-end protected channel established between the UE and MVCD, as described in previous embodiments, to be used as the root of security. This circumvents the need to incorporate a VCAF, and the derivation of the different parameters (e.g., VCS_TID, K_VCS, K_VC, etc) and simplifies MVCD authentication / authorization by the network using (K_ms), which may be used to protect a token (e.g., incorporating session ID, UE ID, MVCD ID, freshness parameter, etc) provided by the network to the UE, and from the latter to the MVCD. Additionally, or alternatively, K_ms may be used directly between MVCD and the Core Network to perform a primary-like authentication procedure, whereby the MVCD is authenticated by means of its ownership / access to K_ms. This has the advantage of ensuring key separation while still rooting security in credentials associated with the USIM associated with user subscription.

[0213] Using distributed ledger

[0214] Fig. 6 schematically shows a communications system that provides a distributed ledger for tracking user-owned or user-associated virtual assets, according to an embodiment.

[0215] In the system of Fig. 6, a UE 600 may be linked (e.g., through a PC5 communication link) to an HMD 601, which may also have UE capabilities. The UE 600 and the HMD 601 may be connected to a 5G network which may host an AUSF 610, a UDM / UDR 611, a VCAF 612, and a NEF 613. Furthermore, a metaverse is represented by metaverse server(s) 620, within which an invokable MVCD 621 resides. Both metaverse server(s) 620 and UDM / UDR 611 may have access to a record (e.g., a distributed ledger) 615, which may be privately owned and managed by metaverse applications / providers or the mobile network operators (MNOs) or a standardization body (e.g., 3GPP) and which determines access rights (e.g., read, write, update, revoke, etc.) that other entities may have. Alternatively, the record 615 may comprise several interworking ledgers (e.g., blockchains) owned by different entities (e.g., metaverse and MNOs) in the system.

[0216] As indicated by the upper continuous data flow line, the UE 600 can access the UDM / UDR 611 via the AUSF 610. As indicated by the dashed line in the middle of Fig. 6, the VCAF 612 can access the MVCD 621 via the metaverse server(s) 620 and the NEF 613. As indicated by the lower dotted line, the UE 600 can access the MVCD 621 via the HMD 601 and the metaverse server(s) 620,

[0217] In an embodiment that may be combined with other embodiments or implemented independently, the record 615 may be used to record / store and track digital / virtual assets (e.g., NFTs, SBTs) which may be associated with and / or owned by a user and serving as e.g., digital identity / avatar, and / or a virtual item e.g., clothes, communication device(s), plots of virtual land, etc., in addition to recording / storing virtual environments (e.g., metaverse applications / providers IDs) in which a user is active.

[0218] In another embodiment that may be combined with the previous embodiment, the access rights to the information stored in the record 615 may either be set by the 5G network and / or the users themselves as part of their privacy profile. For instance, sensitive information which may reveal a user's identity and / or enable user tracking e.g., digital identity, may be set to remain private.

[0219] More details on call setup and user interaction.

[0220] Fig. 7 schematically shows a system and flow diagram of another procedure for establishing a call, communication link and / or session, according to an embodiment.

[0221] In the system of Fig.7, a metaverse client (MV-CL), a client app (CL-A), a metaverse server application (MVS-A), a 5G system (5GS), a database (DB), other metaverse clients (MV-CL(s)), and an external UE (Ext-UE) outside the metaverse are provided.

[0222] According to Fig. 7, a call / communication link and / or session is established as follows (step numbers are indicated in brackets behind the respective signaling flows): In step 1, a first metaverse client (e.g., a UE or a combination of UE and an AR / VR rendering device) authenticates with the 5GS and sets up a packet data unit (PDU) session (PDU-S). Then, a metaverse client app is started.

[0223] In 5G, a PDU session is used to provide end-to-end user plane connectivity between a UE and a data network through a user plane function. A PDU session supports one or more quality of service (QoS) flows. There is a one-to-one mapping between a QoS flow and a QoS profile, i.e., all packets belonging to a specific QoS flow have the same 5G quality of service Identifier (5QI).

[0224] In examples, the metaverse client for 5GS-supported metaverses may be an AR / VR rendering device (i.e., portal device) acting as UE with own eSIM, or a mobile phone acting as UE with eSIM connected via wire or Wi-Fi to an external AR / VR rendering device (e.g., HMD). Both options are equivalent from 3GPP perspective. If both mobile phone and AR / VR rendering device have their own eSIM and act as UE, then it may depend on the subscription whether both devices may take part in a phone call when being called or may act as an individual UE.

[0225] Furthermore, a Ul offered by the client app may be more capable than any actual real-world device (e.g., it could show a 3D image of a scene or object, such as rendering a 3D representation of a mobile phone ( e.g. an MVCD) and its output (e.g. the 2D video / dis- play output of a real-world mobile phone) embedded within a metaverse scene) and the metaverse may be responsible (e.g., via the MVCD) for converting the real communications result (e.g., video) into a 3D display for the virtual user.

[0226] In step 2, the 5GS informs the metaverse server application via NEF / IMS interface that the UE or the user associated with metaverse client is successfully authenticated and / or provides metaverse user ID or GPSI. Optionally, additional user authentication (e.g., biometric authentication) may be needed over a metaverse interface (MVI) between the metaverse client app and the metaverse server application. Additionally or alternatively, the 5GS may inform the UE that the UE or the user associated with metaverse client is successfully authenticated and / or provides metaverse user ID or GPSI, upon which the UE may forward information about the successful authentication and / or metaverse ID or GPSI to the local metaverse client app, e.g. via a local API, which may in turn inform a metaverse server application. If needed / requested (e.g. by 5GS or metaverse application), the local client app or UE (together with the HMD) may perform additional user authentication (e.g. biometric authentication) and provide the output of the user authentication or information obtained during the user authentication process to the requesting entity.

[0227] In step 3, the metaverse server application may fetch avatar and assets information from the database (based on the metaverse user ID provided in step 2). The asset information may include information about a virtual mobile phone (MVCD) carried by the avatar. Alternatively, the 5GS may provide a link to the database or may provide the avatar and assets information via the NEF / IMS interface to the metaverse server application or to the metaverse client which may then provide the information to the client app, which in turn may provide the information to the metaverse server application. Additionally or alternatively, the UE may provide the avatar and asset information via a local API to a metaverse client.

[0228] In step 4, information about new user and / or rendering information (e.g., avatar and assets information) may be provided to other metaverse clients via a metaverse interface (MVI). Additionally or alternatively, information about new user and / or rendering information (e.g. avatar and assets information) may be provided to the IMS framework, such as to the avatar repository as described in solution #23 and #25 of 3GPP TR 23.700-77.

[0229] In step 5, the external UE or other metaverse clients may initiate a regular phone call via the 5GS with the first metaverse client via PDU sessions (PDU-S) with the 5GS.

[0230] In step 6, such a phone call gets routed by the 5GS to the first metaverse client and informs the first metaverse client about the incoming call via the PDU session established in step 1. If a "virtual" call is set up inside the metaverse itself using the metaverse interface between another metaverse client and the first metaverse client, then this call may be forwarded by the metaverse server application to the 5GS via the NEF / IMS interface, which can then route it to the first metaverse client.

[0231] Steps 7(a) and 7(b) indicate different options that can be implemented to handle the call.

[0232] In step 7(a), the UE's operating system (OS) interrupts / pauses the metaverse client app so that the user can take the call using a local application / user interface of the UE.

[0233] In step 7(b), the UE's OS notifies the metaverse client app using the OS's local API (e.g., Android API), which can then show notification in the metaverse and / or inform the metaverse server application about the incoming call, which can then decide to render a phone in the avatar's hand. The user may decide to accept the incoming call. An IMS data channel may be established between the metaverse clients to establish the streaming of audio / video / data between the metaverse clients involved in the call, whereby the data channel and / or the AR / VR / Meta verse rendering components in the network or UE may use the rendering information (e.g. avatar and assets information) that may have been provided to the IMS framework, such as to the avatar repository as described in solution #23 and #25 of 3GPP TR 23.700-77. The UE's OS and / or metaverse client app can mute the audio or lower the volume of the audio received from the metaverse and / or mix the audio from the metaverse with the audio from the call (at lower volume or spatially coming from different direction).

[0234] As a first sub-option of step 7(b), audio from the phone call may be routed to the metaverse (e.g. via local API to the metaverse client app) and rendered together with the metaverse audio.

[0235] As a second sub-option of step 7(b), since uploading and rendering of audio to the metaverse server application may lead to be privacy leakage, the audio may be muted or obfuscated in the metaverse. This may also hold for a microphone input from the user. The avatar may be visually changed to show that the user is speaking privately (e.g., showing mobile phone blocking the mouth and / or showing some red exclamation marks).

[0236] As another option of step 6 and / or step 7 (not shown in Fig. 7), the 5GS may inform the metaverse server app about an incoming phone call to the user, which can then provide notification to the user and adjust the user's avatar representation, inform the metaverse client app, reroute audio etc. In this case, the audio may also be muted or obfuscated to other metaverse clients.

[0237] Steps 8(a) and 8(b) indicate different options that can be implemented to handle a call if the user itself initiates the call whilst inside the metaverse (e.g., by picking up virtual representation of the phone and e.g. dialing phone number the in metaverse).

[0238] In step 8(a), the user interrupts / pauses the metaverse client app and switches to a local app to make the call.

[0239] In step 8(b), the metaverse client app that may render the MVCD can use the UE's OS API to initiate the outgoing call (e.g., using the dialed phone number or contact as argument). The outgoing call may then use a regular 5GS PDU session between the UE and the 5GS. Since the metaverse client app initiated the call, it can also change the representation of the user, mute the microphone or metaverse audio etc. As another option of step 8 (not shown in Fig. 7), the metaverse server app may initiate the call via the NEF / IMS interface to the 5GS, e.g., using the metaverse ID or GPSI provided in step 2 to identify the UE of the metaverse client as initiator of the call, and using the dialed phone number or contact as destination of the call.

[0240] In another embodiment that may be combined with other embodiments or implemented independently, in case the communication link between the user (e.g., through the HMD) and the MVCD is disrupted or lost (e.g. metaverse client app is stopped at the UE), an indication of link disruption may be transmitted to the 5GS, which decides whether to maintain the link with the MVCD and suspend communications for a (pre-)configured period of time or drop the link instantly and route traffic towards the UE. In such a case, the 5GS may require the UE to re-authenticate, hence a Home Network Triggered Reauthentication (HON- TRA) may be triggered by the 5GC network.

[0241] In another embodiment that may be combined with other embodiments or implemented independently, the metaverse implementation may support a process to clone the apps or other data (photographs, videos etc.) from the UE onto the MVCD and vice-versa, and to safely transfer passwords and user ids for these apps. This may include contacts, messages, and call logs, which may need to be transferred between to / from the virtual phone and the UE. For example, metaverse contacts may be stored onto a smartphone SIM and contacts of the smartphone may be imported into metaverse.

[0242] In embodiments, sound and video captured in the metaverse (e.g., the sound of a user's voice and the sound of another metaverse user's voice if such another metaverse user is 'sufficiently close' in the metaverse (e.g. within the same virtual interaction space) or part of an ongoing communication interaction between this and another user within the metaverse, video of what the virtual device (through its virtual cameras) is viewing in the metaverse etc.) may be 'captured' (i.e., extracted from components of the metaverse) and sent by communication from the MVCD to the 5G network. Similarly, sound and video from the real-world may be sent from those contacted by or contacting the device on the 5G network to the virtual device (e.g. via a local API to a metaverse client app that runs an MVCD) and depicted within the metaverse in a form associated with that virtual device (e.g. MVCD), such as sound may be made to emanate from the virtual device as a source, a virtual screen associated with the device may display video, a video (or 3D capture data) may be converted by the metaverse application / provider into a 3D form or other enhanced display format. In other situations, a user may be in a communication session, e.g., in an immersive communication session using avatars, e.g, in a metaverse session, e.g., when wearing or using a first UE that may be, e.g., AR / VR glasses. When doing that, the user may receive a call or data in the real world, e.g., through the user's smart phone, i.e., a second UE, whereby the second UE may be UE 10 as depicted in Fig. 1 and the first UE may be portal device 20 as depicted in Fig. 1. The user may need or want to access the real world call or data (as handled in the second UE) from the Metaverse (handled in the first UE). There are however multiple challenges. For instance, how to access the data, e.g., because if the AR / VR glasses just record the phone screen or a recording of the phone screen is streamed via a local wireless interface (e.g. Bluetooth or 3GPP PC5 interface) to the AR / VR glasses, and reproduce it in the AR / VR glasses, the quality may be lower, also how to interact with the smart phone through the AR / VR glasses, or how to link the identity of the user using the first UE to the second UE, etc.

[0243] To address these and other issues, the following embodiments may be applicable wherein AR / VR glasses and smart phone are used to refer to a first and second UE, respectively, without loss of generality:

[0244] In an embodiment that may be combined with other embodiments or used independently, the AR / VR glasses may verify that they are authorized to retrieve the information from the smart phone, e.g., by one or more of the following mechanisms:

[0245] A) establishing a pairing or having established a pairing between smart phone and AR / VR glasses, wherein this pairing may be based on an out-of-band protocol, or a UE-to-UE security procedure, etc and / or

[0246] B) verifying that they are attached and / or are being used by the same user (e.g., if the measured heart rate is correlated as described in other embodiments), and / or

[0247] C) verifying that they share a common user subscription, and / or

[0248] D) determining, by the smart phone, that the user is wearing the AR / VR glasses, e.g., by means of biometric identification / authentication,

[0249] E) Etc.

[0250] In a further embodiment that may be combined with other embodiments, e.g., the previous one, or used independently, once successfully verifying that they are authorized to share the information, the smart phone (and / or AR / VR glasses) may do one or more of the following actions: A) share the digital information (e.g., screen data, sound, etc) that would be / is displayed on the smart phone, so that this digital information can be provided through the AR / VR glasses, where sharing may be done through a wireless interface such as Bluetooth or the 3GPP PC5 interface, and / or

[0251] B) adapt / configure the Ul / speakers or other actuators in the smart phone, e.g., switch off the screen of the smart phone since the information is displayed through the AR / VR glasses even if the user is handling the phone, and / or

[0252] C) Configure the input means when interacting with the real world smart phone through the AR / VR glasses. For instance, a user may interact with the information displayed on screen of the smart phone (that is off (i.e., displays nothing), or with a very low brightness level) where the information is actually displayed through the AR / VR glasses. This can serve to reduce energy consumption of the smart phone while improving potential interferences between the smart phone displayed information and the AR / VR glasses displayed information overlaying the location of the smart phone screen, it may also serve as a means to preserve the privacy of the information typically displayed on the smart phone screen., and / or

[0253] D) The AR / VR glasses may then use as input information for the handling of the smart phone a combination of the following: a. the input from the smart phone touchscreen (e.g., even if it is off or with a very low brightness level, the touchscreen capability may still be active, and be used to determine the instructions by the user), and b. the visual information retrieved by sensors (e.g., camera) in the AR / VR glasses that may interpret the finger actions of the user on the smart phone screen, and c. visual information retrieved from sensors (e.g., cameras) inside the AR / VR glasses which monitor and track eye movements and actions (e.g., blinking), such that the input information of the data sources may be integrated, e.g., by means of data fusion techniques, and / or

[0254] E) Transfer the state of the smart phone (e.g., open apps, information displayed on them, cache, etc) to the AR / VR glasses that will then create a Metaverse Virtual Communication Device (MVCD) overlaying the real-world smart phone screen. The user may then open an app, and interact with the information last used in the real-word session. For instance, assume that a user used a location service such as Google maps in the smart phone performing a given search, then the user started using the AR / VR glasses, then the service information (Google maps app, in this case) is transferred to the AR / VR glasses. The user may then visualize the service information through the AR / VR glasses, but the information may still be rendered over the real world smart phone by means of the AR / VR glasses, similarly, once the user stops using the AR / VR glasses, the state of the service may be transferred back to the smart phone, and / or

[0255] F) The user subscription of the smart phone may be transferred to or shared with the AR / VR glasses so that the user can make use of the subscription whilst using the AR / VR glasses. This also allows the user to make use of the AR / VR glasses and, e.g., re- ceive / make calls through the AR / VR glasses in addition to or instead of through the smart phone. The transferring of the subscription may be done in multiple ways, a way may be to transfer a token from the smart phone to the AR / VR glasses, e.g., by means of an out of band channel, e.g., displaying a QR code on the smart phone that is scanned by the glasses where the QR code includes credentials, exchanging credentials by blinking the screen of the smart phone, etc. These credentials (which may include, e.g., an authorization token, public-key of the core network, networking information to route a connection request, etc) may then be used by the AR / VR glasses to access the core network of the telecommunication's system and be authenticated / authorized. For instance, the same credentials may be shared by the smart phone with the core network (e.g., AMF / AUSF), e.g., in a secure way since the smart phone is already connected. The AR / VR glasses may send a message (e.g., access request) including the credentials towards the same core network including the credentials, e.g., it may be securely sent encrypting an authorization token with the public-key of the core network as a one-time SUPI linked to the AR / VR glasses. Upon reception of these credentials, the core network may further authenticate the AR / VR glasses (e.g., following a procedure similar to HON- TRA) and / or may associate the AR / VR glasses to the subscription, e.g., in a given context, e.g., for a given amount of time. Upon succesfull authentication and / or authorization of the AR / VR glasses, the core network may also inform a service, e.g., IMS, with details on how to route the service, e.g., the Avatar-based IMS call to the AR / VR glasses.

[0256] In a further embodiment that may be combined with other embodiments, e.g., the previous one, or used independently, the communication profile of the user may be adapted with switching the connection for the second UE (e.g., smart phone) to the first UE (e.g., AR / VR glasses). In an example, the subscription profile may determine whether the user is allowed to transfer the service from a second UE to a first UE, and / or under which conditions it may be allowed to do so.

[0257] In a further embodiment that may be combined with other embodiments, e.g., the previous one, the authorization to use certain resources, e.g., an Avatar model, may be transferred when switching the connection for the second UE (e.g., smart phone) to the first UE (e.g., AR / VR glasses), so that the first UE gets the authorization to store said resources.

[0258] In a further embodiment that may be combined with previous embodiments, the first UE may be establishing the connection through a non-3GPP access, e.g., WiFi.

[0259] In a further embodiment that may be combined with other embodiments, the credentials shared with the first UE may include:

[0260] An authorization token provided by / through the second UE and generated by the second UE or core network. For instance, the second UE may request moving the connection from the second UE to the first UE, the core network may authorize it and generate an authorization token, and share it with the seocnd UE, and then the second UE may share this token with the first UE (e.g., securely). The first UE may then send it to the network for network access.

[0261] A symmetric key or a public / private key pair to establish a secure link. For example, a symmetric key derived from credentials in the UE, e.g., derived from the root keying material or from the current K_AUSF.

[0262] In an embodiment that may be combined with other embodiments or used independently, billing to the user may be performed via the registered communications credentials, i.e., the same as the user's UE device. Users may be able to select (e.g., on the UE or with policy / UE subscription data) whether they wish to be charged by the MNO or metaverse operator for outgoing calls. Additionally or alternatively, an MVCD may be given a (temporary) VoIP telephone number assigned e.g. by a generic VoIP service (e.g., such as Google Voice). When making a call with the (temporary) VoIP telephone number, the generic VoIP service may route the calls to / from a PLMN to which the user of the MVCD has subscribed, whereby the (temporary) VoIP telephone number may be replaced by an actual telephone number assigned to the user and / or the user may be charged by the PLMN accordingly. Additionally or alternatively, a (temporary) VoIP telephone that is assigned to the MVCD may be provided to the UE of the user (e.g., by the metaverse application accessing the UE via local API or local interface), which may replace the (temporary) VoIP telephone number with its own telephone number and / or provide the (temporary) VoIP telephone number to the 5G System, which may replace the (temporary) VoIP telephone number with an actual telephone number assigned to the user, after which the replacement telephone number is used to set up the communication with other entities, and the user may be charged accordingly.

[0263] In an embodiment that may be combined with other embodiments or used independently, other users may be invited to a metaverse session, and a representation may be switched from a virtual phone to a complete avatar representation, while the audio may also be adjusted to not come from the remote phone but from the avatar standing nearby the avatar of the person carrying the virtual phone.

[0264] In an embodiment that may be combined with other embodiments or used independently, a smartphone model may be rented and / or bought and / or tried in the metaverse as an MVCD, without owning the physical smartphone model in the real world.

[0265] In an embodiment that may be combined with other embodiments or used independently, an AR / VR device (e.g., VR headset) may recognize that you are looking at your smartphone and may offer a Ul to switch to route the communication via the smartphone or route the communication of the smartphone, phone audio, etc. via the metaverse (e.g., for better integration of rendering by the VR device).

[0266] Further details on MVCD and USIM as digital assets

[0267] In an embodiment that may be combined with other embodiments or used independently, the MVCD may be a digital asset stored and / or managed by the network and / or a 3rdparty (e.g., the metaverse service provider), such that invoking (e.g., access to and / or retrieval) the MVCD e.g., from a digital asset repository (e.g., maintained by the network and / or a 3rdparty e.g., metaverse service provider) requires authenticating the UE and / or the user identity, as described in previous embodiments. Additionally, based on network authorization policies / configurations and / or user preference-based (pre-)authoriza- tion(s), and upon successful authentication to the metaverse service(s) including (e.g., UE, and / or user identity authentication) and invocation of the MVCD within the metaverse (application), subsequent communication traffic (e.g., User Plane data) may be redirected to the MVCD within the virtual environment (metaverse application) where the user is immersed; it is worth noting that signaling traffic (e.g., Control Plane data), or a subset thereof, may go through the UE. For instance, the CP traffic may be split between the UE and the MVCD, such that for signaling associated with services provided and / or allowed by the network operator to be consumed within the metaverse environment (e.g., phone call), may be routed through the metaverse service provider, where the communication channel(s) between the MVCD and the network are protected (e.g., end-to-end protected) based on e.g., service level agreement between the network operator and the metaverse service provider. Signaling associated with services that are not consumed by, allowed in, or compatible with the metaverse environment (e.g., RRC signaling) is maintained with the UE. Additionally, or alternatively, signaling associated with services allowed and / or to be consumed within the virtual environment may be duplicated and sent to both the UE and the MVCD, and based on the device (e.g., UE or MVCD) from which feedback (e.g., answering a call) is received, signaling and / or user plane data is routed (i.e., as usual when feedback is received from UE, split and / or entirely through the metaverse service provider, if feedback is received from MVCD).

[0268] In another embodiment that may be combined with other embodiments, or used independently, the establishment of communication channel(s) between the network (e.g., Network Functions within 5GC) and an MVCD, for control and / or user plane data, may require a multi-step authentication and / or authorization procedure. For instance, Upon authentication to a metaverse application (e.g., on a VR / AR / XR capable device), and following the invocation of an MVCD within the metaverse environment (i.e., accessing / retrieving MVCD as a Digital Asset (DA) from the digital asset repository managed by the network / 3rdparty), the user may be requested to perform a secondary authentication procedure using e.g., user-specific credentials (e.g., associated with the user identity), a one-time password (OTP) communicated by the network to the UE, biometric-based credentials (e.g., iris scan), or the like, and only upon performing successfully the multi-step authentication procedure, the network may allow the establishment of the aforementioned communication channels.

[0269] In another embodiment that may be combined with other embodiments or used independently, the USIM or SIM profile content, or a part thereof, or a virtual equivalent thereof (referred to as a virtual SIM (vSIM)), may be a digital asset stored and / or managed by the network operator and accessible e.g., by 3rdparty metaverse service providers, such that upon being authenticated and accessing a metaverse application, invoking (e.g., by the user) the MVCD may implicitly require invoking (e.g., accessing / retrieving) the digital asset associated with the vSIM, to enable the MVCD to operate (e.g., perform a primary authentication, or a part thereof) similarly to a UE within the virtual environment. It is worth noting that the digital asset associated with the vSIM may be locked (e.g., similar to a SIM card), and may only be unlocked upon introducing a PIN (or the like), which may be similar or different from the PIN (if any) associated with the USIM hosted on the UE, or a random PIN that may be communicated to the UE and expected to be provided by the user within the metaverse application. Note that this procedure may serve as the secondary authentication procedure described in previous embodiments.

[0270] In another embodiment that may be combined with other embodiments or used independently, traffic (e.g., control and user plane data, or a subset thereof) flowing through the communication channels established between the network (e.g., Network Functions therein) and the MVCD in the virtual environment (e.g., metaverse application) may be routed to the UE upon the expiry and / or revocation of authorization(s) associated with access / use of at least one of the two digital assets (i.e., MVCD and vSIM) by the network operator, metaverse service provider, or the user themselves, and / or detecting the MVCD is held by a different user in the virtual environment (e.g., based on authorization policies defined by the network, metaverse service provider, or user preferences (e.g., allow list of users), and / or prolonged inactivity within the metaverse application, where the inactivity duration is determined by a network, or metaverse provider policy / configuration or user preferences, and / or based on the network detecting UE activity (e.g., browsing, calling), etc. MVCD as digital twin

[0271] In an embodiment related to Fig. 1 that may be combined with other embodiments or used independently, the MVCD is a digital twin of UE 10, whereby application layer related state information, operating system related state information, user interface related information, A / V streaming / rendering related information, and / or hardware / memory / (e)SIM related state information is kept synchronized through a secure communication channel between UE 10 and the MVCD or a management entity thereof (e.g. based on the UE 10's (e)SIM credentials, or by using a set of pre-shared keys or by using a public key infrastructure based mechanism). The MVCD may be identified by using the same subscription identifier as UE 10 (e.g. SUPI) possibly augmented with an MVCD identifier, or by using the same device identifier (e.g. I MEI) possibly augmented with an MVCD identifier, or using a different identifier that may link the MVCD uniquely to UE 10 and / or its subscription (and vice versa). In this embodiment, the metaverse implementation 30 can be a secure server operating a set of digital twins of UE, which may run inside or outside a cellular core network, and which may not necessarily offer AR / VR functions / rendering to access the digital twins. In a variant, the (e)SIM is not operated as part of the digital twin, but resides only on UE 10. In such variant, every time the (e)SIM needs to be invoked (e.g. to establish a secure communication session, perform authentication) the MVCD acting as digital twin may communicate with a (e)SIM on the UE 10 e.g. using a local API available to a metaverse application (e.g. invoked by the MVCD acting as a digital twin) to directly or indirectly communicate with a UE's (e)SIM and / or by using 3GPP protocols (e.g., using a primary / secondary authentication procedure as described in 3GPP TS 33.501 between the UE and an authentication server (e.g. AAA server) operated by or linked to the metaverse provider), and (part of) that credential exchange and / or the result of that credential exchange may be formed into a packet and transferred to the MVCD acting as digital twin (or other UE or network with which the MVCD wishes to communicate). The communication interface (e.g. local API) may be protected by using a set of pre-shared keys or by using a public key infrastructure based mechanism or by using AKMA or a metaverse session key, and / or may be protected by the MVCD acting as digital twin operating behind an external API (e.g. northbound API of a cellular core network (e.g. via NEF)), whereby the MVCD acting as digital twin can only communicate indirectly with UE 10 when UE 10 has established a secure connection with the cellular core network). The MVCD acting as digital twin of UE 10 may act on behalf of UE 10 and may perform the same operations as UE 10, e.g. set up a call with another UE via the IMS framework as described in other embodiments, when operated within a metaverse environment with AR / VR functions / rendering, after which UE 10 may be updated with state information from the MVCD (e.g. using the same synchronization mechanism as described above. Additionally or alternatively, the MVCD may operate simulations of different scenarios for a set of state changes that may not be synchronized with UE 10, e.g. to assess the effect of certain actions on the UE 10 behavior and / or communication parameters.

[0272] In other words, a method and system is provided wherein an MVCD operates as a digital twin of a UE, the method and system comprising a UE and a virtual representation of the UE (i.e. MVCD), wherein the UE and MVCD establish a secure communication channel between each other (or between the UE and a management entity thereof), and wherein the UE and MVCD synchronize application layer related state information, operating system related state information, user interface related information, A / V streaming / rendering related information, and / or hardware / memory / (e)SIM related state information between the UE and the MVCD through the secure communication. And wherein the MVCD may act on behalf of the UE, may perform the same operations as the UE and / or may run simulations of the UE.

[0273] Avatar communication.

[0274] The following embodiments are directed to avatar communication.

[0275] In 3GPP specification TR 23700-77, a goal is to study whether and how to enhance an IMS architecture (e.g., as defined in TS 23.228) whose security may be specified e.g. in TS 33.203 and TS 33.210 and TS 33.328 (media plane security), by providing procedures and / or interfaces for supporting an avatar call (including multi-party communication) and communication with accessibility (e.g., as specified in clause 5.2.2 of TS 22.156).

[0276] For multi-party communication, a secure real-time protocol (e.g., as defined in RFC 3711) may be used. Multi-party communication may require negotiating as to which type of security is required, using a group key or multiple point to point keys. This may also be a configuration distributed by the network or the IMS network or pushed to the communicating parties. The IMS network may also gather preferences of the users or communicating parties and distribute them to the rest of the users. Key management (e.g., as described in Clause 6.2.3 of TS 33.328) may be based on ticket-based modes of key distribution in multimedia Internet keying (MIKEY-TICKET) as described in IETF RFC 6309. In some cases, a communication may start between a sender and a single receiver of a communicating party, and then increase to two, three, or more receivers of communicating parties. For a communication between sender and a single receiver of a communicating party, a single key may be sufficient to secure the communication between sender and receiver. When the communication takes place between a sender and two receivers of communicating parties, the sender may keep two keys, a first key to protect the communication between the sender and the first receiver and a second key to protect the communication between the sender and second receiver.

[0277] In avatar communication, a user may choose a given avatar and it needs to be made sure that avatar objects (such as an avatar representation) can be stored and accessed by the authenticated and authorized UE and / or IMS network nodes while avoiding fraud and ensuring privacy. Similarly, it needs to be made sure that the use of an avatar representation can be authorised in an IMS avatar communication. As per Annex AC.9 in TS 23.228, step 3 is about AR-media rendering negotiation between UE and IMS network. In an example (EA1), this step can be enhanced to only configure and store authorized avatar models in a multimedia function (MF) and / or a multimedia resource function (MRF). Additionally or alternatively, a new step may be introduced to achieve said configuration. Additionally or alternatively, the step may also enable the authorization process. For instance, the user and / or UE (e.g., the receiving UE / user) may indicate a given desired avatar model, identified by a given identifier or Avatar-id, but this avatar model may only be authorized by an AR application server if supported and / or authorized for / by the user (e.g., the sending UE / user). Note that this can also require identifying / authenticating a user (e.g., the sending and / or receiving UE) as in other embodiments. The MF / MRF may only allow it if it complies with a policy of the network and / or of the communicating parties involved in the call. For instance, a user may have a personalized avatar model that allows to improving his presence, eye contact, etc in video calls. However, the user may want that this avatar model is not misused, and it may only allow its usage if he and other users have been identified / authenticated as the user in the call / using the UE / AR / VR glasses.

[0278] In a further example (EA2), the user may have a preference policy that may be stored locally (e.g., in the user's UE) or in a database in the core network (e.g., UDM or in an Avatar Repository) or part of the user's subscription, the preference policy that may determine whether the avatar model, completely or partially, may be shared also with remote users, e.g., may be locally loaded in the UEs of remote users, e.g., when a split rendering technique is required, or whether it may only be used in a remote edge server serving the remote user. This avatar model may be a predictive model -- as indicated in TS 22.156 - that enables presentation of avatar media to users based upon timing and other information, so that information can be extrapolated or inferred even if it is not yet available from the network.

[0279] In another example (EA3), a user may own several avatar models / representa- tions which may be used when communicating with different users or groups of users wherein a user may designate a default avatar model that is used as a fallback option in case of e.g., failure to access a particular avatar model / representation during an IMS avatar communication session. The default avatar may be set as part of the user's preference policy and may be owned by the user itself and / or be a generic avatar model that is assigned by the network. The access / use of such generic avatar model may be subject to looser authentication / author- ization requirements as it is a fallback option i.e., placeholder avatar. For instance, the user may be required to only be authenticated and / or authorized to perform an IMS avatar communication session to be able to make use of the default avatar model. Moreover, the fallback to use the default avatar model may be on-demand (e.g., through an indication in the SIP invite) and / or automatically upon failure to authenticate / authorize a user to access / use a particular avatar model, in which case the network checks the user's preference policy and / or subscription to determine whether a user specific default avatar model or a network generic default avatar model is to be used instead.

[0280] In a further example (EA4), the user may enter his preferences (e.g., preference policy) when communicating with another party, e.g., by means of the UE user interface.

[0281] In a further example (EA5), the preference policy may be sent or exchanged or retrieved during an authorization process, e.g., as in previous embodiments, used to determine which avatars are authorized to be used or stored. For instance, the preference policy of a user may be shared with the MF or MRF so that it only uses / stores authorized avatar models. For instance, the MF or MRF may check with the AUSF / UDM whether the avatar model for the current communication may be used / stored. For instance, the user may enter his preferences and determine whether to share his model or not.

[0282] In a further example (EA6), the avatar model may be supported (used) if the model includes a signature or certificate or proof of ownership that can be verified successfully by the verifier, e.g., AS or MF / MRF. The signature used to sign the certificate may have been issued by the end party requesting the usage of the avatar model, e.g., the UE / user that is transmitting (transmitting user). The avatar model may be deployed in the AS or MF / MRF or in an edge server or in remote UE used by the receiving user. Similarly, the preference policy may also need to be successfully verified if it is to be accepted.

[0283] In a related example (EA7), the receiving user also requires the identifica- tion / authentication of the transmitting user, e.g., by checking the biometrics of the transmitting user or by other means as illustrated in other embodiments. Once the receiving user was able to verify the identity of the remote transmitting user, e.g., by means of the techniques described in other embodiments, the receiving user may be securely provisioned with the keying materials that are required to verify the model of the remote transmitting user, e.g., a public key issued to or owned by the remote transmitting user. The provisioning step may be done by the 5G network or the IMS network. In a further example (EA8), the avatar model may be verified against a distributed ledger such as a blockchain that allows verifying the integrity and / or ownership and / or authenticity of the model. A party willing to communicate may publish in the distributed ledger his / her model, and / or a fingerprint of the model, and / or a link between the model and the party, and / or a signature of them so that any other party retrieving the data can verify this information. A party willing to communicate may also publish any other software and / or libraries required to correctly process the avatar model, e.g., software and / or libraries that are required to properly run a predictive avatar model. The producers of such libraries may also publish the libraries and / or their fingerprints and / or their signature in the distributed ledger. The published avatar model may be encrypted so that it cannot be used without authorization, whereby the authorization may involve the distribution of keys that allow decrypting it, in its entirety or partially.

[0284] Next several scenario variations related to clause AC.9.3.1 of TS 23.228 are described in which two UEs may establish and / or use and / or rely on an Avatar based communication where above embodiments and examples may be applied and further elaborated. In these scenarios, a first UE (e.g., UE_A) and a second UE (e.g., UE_B) are involved where both UEs (wish to) interact by means of an Avatar based communication. Next to the Media Function / Media Rendering Function (MF / MRF), other functions involved may include the DC Signaling Function (DCSF), an AR / XR Application Server (AS), a Digital Asset / Avatar repository. In some cases, steps of different scenarios may be skipped or combined with each other.

[0285] In a scenario, step 3 in Figure AC.9.3.1-1 in clause AC.9.3.1 of TS 23.228 may include the exchange of an avatar-id from a first UE UE-A and the MF / MRF and / or XR application server. Next, the application data channel may be established between UE-A and the IMS network, as well as between UE-B and IMS network, wherein this may also require indicating the Avatar-Id. Next the AR application server may request an Avatar database to retrieve the avatar metadata. This may require providing the UE-identity and Avatar-ID. Once the XR application server has the data, it may start controlling rendering, e.g., that may be done by the MF / MRF, UE-A or UE-B. If done by MF-MRF, UE-A may send data, e.g., face expression of the user, that may be rendered by the MF / MRF, and the rendering may be sent to both UEs UE-A and UE-B. If done by UE-A, UE-A may receive from the AR application server the Avatar metadata, Avatar Id, and UE identity so that it can perform the rendering locally and send the rendering to UE-B (over RTP). If done by UE-B, UE-B may receive from the XR application server the avatar metadata, Avatar ID, and UE identity. UE-B receives from UE-A information about UE-A, so that the rendering is performed at UE-B. In another scenario, it is required to download the avatar representations from an avatar repository, and this may be done by means of a bootstrap data channel. The avatar repository may store the avatar representation. The avatar representation is identified by avatar ID. The avatar repository may be connected to the Data Channel Signaling Function (DCSF). After the bootstrap data channel establishment, the avatar ID which UE can use is provided together via the bootstrap data channel. UE may select appropriate data channel application and avatar representation to download from the DCSF through MF / MRF. The action may trigger the download to a network entity (e.g., MF / MRF) and / or UEs (a sending UE and / or a receiving UE).

[0286] In yet another scenario, it is required to transition from audio / video communication to avatar communication. A first UE UE_A may have audio / video communication with a second UE UE_B and may exchange audio / video media through MRF over RTP. UE_A may decide to switch to Avatar communication so that UE_A may need to interact with the DCSF and UE_B to negotiate the Avatar media and establish a Data Channel. The DCSF may get the Avatar metadata from an Avatar repository and send it to the Media Function (MF / MRF), that may send it to UE_B. UE_A may then sense the user (e.g., facial data, body motion, etc) and send it to the MF / MRF. The MF / MRF may then perform rendering given the Avatar metadata and the sensed user information, sending the rendered data to UE_B and / or may send the Avatar metadata to UE_B that will perform the rendering based on the received sensed user information.

[0287] In yet another scenario, the two UEs UE_A and UE_B have established an audio / video connection, the XR_AS and MF / MRF may interact (e.g., XR_AS may send a request through DCSF) so that the MR / MRF performs transcoding and rendering functions. Parameters to consider may include the avatar type (e.g., 2D or 3D), location of the Avatar (e.g., URL). The MF / MRF may download the Avatar metadata / model so that it can perform transcoding / rendering of the audio / video stream into an avatar-based representation by applying the Avatar model that may be an Al-model such as Text-to- Speech, Self-Supervised Learning, Self-Regulated Learning, Automatic Speech Recognition, etc.

[0288] In yet another scenario, a first UE UE_A may generate or update an Avatar representation (of the user) and upload it to a NF, e.g., a Digital Asset Repository (or Avatar repository). UE_A and a second UE, UE_B, may establish an IMS session for audio / video and bootstrap a data channel that is used to distribute the initial scene. An AR Application Server may generate the scene for this AR session and send it over the data channel to the MF / MRF. This scene may include the Avatar representation (or model) of UE_A and / or UE_B. The MF / MRF may share the scene with UE_A and UE_B that may determine applying the Avatar communication, e.g., UE_B may send a request to obtain Avatar model of UE_A from the Digital Asset repository. The Digital Asset repository may authorize UE_B to access UE_A's avatar model. This step may involve the checking of the IMS session details and the authentication of UE-B. It may also include the checking of which assets and which level of details are to be shared. If authorized, the Avatar model of UE_A is shared with UE_B. In a subsequent phase, media streams may be transformed into animation streams that may be used as input in the Avatar model for the animation of the Avatar.

[0289] Fig. 8 describes a potential procedure according to some of the embodiments and examples above. Entities 1000, 1001, 1002, 1003, 1004, 1005, 1006, 1007, and 1008 correspond to a first UE UE_A and / or user, an avatar / digital asset repository or database, the MF / MRF, an XR or AR AS, the DCSF, an IMS AS, a core network function in charge of identity management (e.g., HSS or UDM / UDR), a third party issuing identities / signatures, and a second UE UE_B and / or user. Step 1009 may represent an established Audio / Video communication session between UE_A and UE_B or an initial configuration step of UEs (e.g., with authorization tokens, or policies) or authorization policies in some functions (e.g., Avatar repository 1001). Step 1010 may refer to an initial XR media rendering negotiation step (e.g., similar to Annex AC.9 in TS 23.228, step 3) wherein an Avatar model is negotiated, e.g., for UE_A. Step 1011 may refer to media -renegotiation between UE_B and IMS network for a given Avatar model. Step 1012 may refer to an internal configuration / authentication / authorization of the Avatar communication based on the user / UE identities, Avatar model to use, and policies, this may involve configuring the Avatar model at the MF / MRF 1002 or at one of the UEs, e.g., UE_A or UE_B. Step 1013 may indicate the start of the communication wherein UE_A transmits stream data (au- dio / video / sensed gestures / ...) to 1002. In Step 1014, 1002 performs the transcoding / rendering based on the Avatar model. In Step 1015 the rendered data is sent to UE_B. This procedure is exemplary and may be combined with other aspects described before, e.g., the transcoding / rendering may be performed at UE_A 1000 or UE_B 1008 requiring the storage of the Avatar model at UE_A or UE_B.

[0290] In an embodiment (EB1) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, when a network function / server, e.g., XR AS 1003, requests (e.g., in Step 1012) the Avatar metadata or model from an Avatar database 1001, the Avatar database may only return the model if UE-A and / or UE-B and / or MF / MRF are authorized to receive said metadata or model. This may require indicating and / or verifying information such as the UE identities, the User Identity, communication purpose, and communication context.

[0291] In an embodiment (EB2) illustrated by means of Fig. 8, when a network function / server, e.g., XR application server 1003, shares Avatar metadata (e.g., in Step 1012), which metadata is allowed to be transmitted may depend on the target entity, e.g., MF / MRF may be authorized to obtain all metadata, but a UE may not. This means that depending on the rendering mode (network based or split rendering, the Avatar metadata or model may be shared or not, and thus, Avatar-based communication may be allowed or disallowed. In an embodiment (EB3) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the UEs and / or the users behind the UEs 1000 and / or 1005 may have an identity used for their (mutual) identification, authentication, and / or authorization wherein the identity may be provided by:

[0292] A cellular network, e.g., be related to a unique user identity such as the SUPI (e.g., 1006);

[0293] An external party such as an application service (e.g., 1003 or 1007) that may be using the cellular network to enable Avatar-based communication;

[0294] A third-party identity / signing server in charge of issuing identities for a given organization (e.g., 1007), e.g., following an enhanced STIR / SHAKEN architecture (e.g., as illustrated in Fig. 6.11.1.1-1 in TR 23.700-77 V0.4.0).

[0295] A UE itself.

[0296] In an embodiment (EB4) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the verification of an identity of a UE / user mas well as authentica- tion / authorization for the usage of an Avatar model may be performed by means of an enhanced STIR / SHAKE architecture (TS 24.229) wherein the sending / receiving UE may use a signing server in the domain of the sending / receiving UE operator to sign its identity and / or request to use an Avatar model and / or Avatar model to offer to a remote UE / user, the signed data may be shared with a receiv- ing / sending UE (in the domain of the receiving / sending UE operator) and a verification server may verify the signed data. Once verified, an authorization step may be taken / performed, in other words, the verification of the signed data by the verification server serves as an authorization step..

[0297] In an embodiment (EB5) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the identity UID required for the identification of the (sending) user and / or UE establishing the avatar-based communication that is required for its later authentica- tion / authorization may be exchanged in an initial communication establishment or negotiation phase (e.g., Step 1009 or 1010), e.g., as part of the SIP INVITE message. Next to this identity UID, the identity of the required Avatar ID may be exchanged so that it is possible to:

[0298] Identify the user / UE

[0299] Authenticate the user / UE

[0300] Verify whether the user / UE is authorized to use said Avatar model linked to the Avatar ID.

[0301] In a related embodiment (EB7) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the identity UID (or a pseudonym of it) required for the identification of the (sending) user and / or UE establishing the avatar-based is included in an authorization information (e.g., an authorization token) that allows the receiving party (e.g., Avatar repository 1001) to verify the identity and authorization. Additionally, or alternatively, it includes some authentication information, (e.g., digital signature) allowing the receiving party to verify the identity and authenticate the sending UE / user. Note that the receiving party may need to interact, e.g., with 1006 or 1007, e.g., through 1005, to verify the authorization token

[0302] In a related embodiment (EB8) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the identity UID (or a pseudonym of it) required for the identification of the (receiving) user and / or UE may also be exchanged in an initial communication establishment or negotiation phase (e.g., Step 1011), additionally or alternatively, authentication and / or authorization information may be exchanged as per the last embodiment that may be verified in a similar way.

[0303] In a related embodiment (EB9) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, a user / UE (e.g., in Step 1009 or 1010) or an XR AS (e.g., in Step 1009 or 1012) or a third party (e.g., in Step 1012) may indicate: the conditions under which an Avatar model may be used and / or stored, e.g., the type or properties of the connection (data rate, quality of service, latency, jitter, etc) to which it may be applicable, and / or specific UEs / users that may use or store an Avatar model (e.g., Avatar model may be stored at the MF / MRF 1002, but not at UE_B, e.g., Avatar model may not be stored at UE_B if it is not within the same operator network) and / or

[0304] UE / user types that may use an Avatar model, e.g., a user identified as a kid may not use a given Avatar model.

[0305] This information may be part of a policy / configuration / metadata linked to the Avatar model that may be identified by a given Avatar ID.

[0306] In a related embodiment (EBIO) by means of Fig. 8 that may be used with other embodiments or used independently, a receiving UE UE_B may request the storage of the Avatar model used by UE_A so that it can perform local transcoding and rendering by sending its UE / user ID / authentication data / authorization data, the IMS / core network (e.g., Avatar repository 1001) may determine that UE_B is not authorized to locally store the model but to use it remotely in a split rendering mode wherein the MF / MRF 1002 may perform the transcoding / rendering, at least, partially. The IMS / core network may then inform UE_B about it and may either trigger this configuration of the MF / MRF with the Avatar model and / or wait for the request from UE_B to perform this configuration.

[0307] In a related embodiment (EB11) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the entity performing the transcoding and / or rendering by means of the Avatar model (e.g., MF / MRF 1002 in Step 1014 in Fig. 8) may monitor whether the user changes (e.g., a different face is identified in the incoming data stream, e.g., audio / video stream and / or the sensed data (e.g., way user moves his head, etc follows a different pattern) during the Avatar session since this may indicate the involvement of a different user that may not be authorized. The entity performing the transcoding and / or rendering may have a policy / configuration determining the action to take when this even is detected, e.g., send an indication to the receiving UE / user and / or switch back to normal Audio / Video communication and / or stop the communication session.

[0308] In a related embodiment (EB12) illustrated by means of Fig. 8 that may be used with other embodiments or used independently, the authentication / authorization procedure is performed in two steps: an initial authentication / authorization step performed before the communication starts and based on the identity of the user and an authorization policy; and a second (continuous) authentication / authorization step performed while UE_A and UE_B are performing the Avatar-based communication (e.g., as in previous embodiment).

[0309] In a scenario related to Tdoc S3-241212, Steps 1- 6: UE-A and UE-B negotiate the usage of an Avatar-ID, and it is checked whether usage of Avatar-ID by UE-A and UE-b is authorized. This is done by sending, by UE-A, an indication of the Avatar-ID and a token in the XR media rendering negotiation step. The IMS AS then checks with the HSS / UDM whether the UE is authorized to use the Avan- tar ID, and if it is, IMS AS signs the Avatar ID. The signed Avatar-id is exchanged with UE-B to indicate about the avatar session during the signalling. The terminating IMS network checks if the UE-A is allowed to use the Avatar-id by verifying the signed Avatar-id with the verification server. If successful, it forwards the Avatar-id to UE-B. UE-B has the option to reject the avatar alone or terminate the session based on Avatar-id. If this authorization step succeeds, the XR AS retrieves a token through NEF / CAPIF / NRF. The successful retrieval of the token gives access to the avatar model from the avatar repository. The XR application server retrieves model from avatar repository, and delivers it to the MR / MRF so that the network rendering can be performed.

[0310] This scenario shows some similar steps compared with above embodiments, e.g.: EB1, EB2, EB4, and EB7. Still, this scenario has a number of challenges such as how the procedure to get a token from NEF / CADPIF works, (2) what is included in the UE token, (3) why the signed avatar ID is sent to UE-B, or (4) which information is to be provided via NEF to obtain the token, or (5) whether interaction over NEF is required at all. Furthermore, the UE centric rendering is for further specification.

[0311] In an embodiment (EBT) that may be combined with other embodiments or used independently, an application function (AF) may allow a UE / user to use / select an Avatar ID, e.g., after UE / user purchases said Avatar. This action may give the UE / user authorization to use the Avatar, and this authorization may be provided to the user / UE as an authorization token / policy. The UE may share said authorization token in Step 1009, as in Fig. 10. The IMS system may then be able to verify that UE_A is entitled to use Avatar ID. The token may state also whether said Avatar may be used in net- work-centric rendering and / or UE-centric rendering, as well, as whether UE-B may store said Avatar metadata model.

[0312] In another embodiment (EB2’) that may be combined with other embodiments or used independently, a UE / user that may be authorized not only to use the Avatar but also to manage it e.g., if UE / User owns the avatar. For instance, a UE / user may authorize other UEs / users to use and / or store the avatar, e.g., by requesting authorization tokens from XR AS and providing them to said UEs / Users where the token may determine one of a multitude of usage conditions, which include, but are not limited to: type of access (e.g., retrieve and use, retrieve, use, and store) type of rendering (e.g., network-centric, UE-centric, or both) type of use (e.g., use to represent owner during avatar communication, use as own avatar during avatar communication) access duration (validity time of the authorization token e.g., one time use or multiple times use)

[0313] In an embodiment (EB3’) that may be combined with other embodiments or used independently, the Avatar based communication may focus on network-centric rendering. At some point of time, UE-B may request UE-centric rendering, and may send a request for this purpose. This request may include its UE (and / or user) ID, UE (and / or user) profile, and authorization information, e.g., authorization token. This request may be sent to the IMS AS. The IMS AS may check with the XR AS whether UE B is authorized to obtain the Avatar model. If allowed, it may retrieve the Avatar model / metadata from the Avatar repository, and it may be provided to UE-B. Additionally or alternatively, the request to check whether UE_B is authorized to obtain the Avatar model may be forwarded to UE_A, such that the user / owner of the Avatar model determines whether UE_B could be permitted to retrieve it, how it may use it, and for how long / many times. Additionally, or alternatively, it may request the MF / MRF to distribute (part of) the Avatar model to UE-B, and signal the change between network-centric rendering and UE-centric rendering.

[0314] In an embodiment (EB4’) that may be combined with other embodiments or used independently, an Avatar model / metadata is distributed together with a usage policy or policy that determines the conditions and UE / user / MF / MRF that can use it. The Avatar model / metadata is distributed in a protected manner, e.g., encrypted under key K, next to the usage policy. The device running the model, e.g., MRF / MF / UE-B may evaluate whether the conditions for its usage are met, and only if the conditions are met, the Avatar model / metadata may be unlocked (e.g., after removing protection, i.e., decrypting) and used. In an embodiment (EB5’) that may be combined with other embodiments or used independently, the MF / MRF / UE-B may already contain / store an Avatar model / metadata associated to an Avatar ID, e.g., from another (previous) communication session. If this happens, the MF / MRF / UE- B does not need to retrieve the Avatar model / metadata, but only check whether the UE(s) in a new communication session are allowed to use it and / or renew the authorization / usage policy, e.g., by sending a request to the authorization entity, e.g., XR AS, or AF (e.g., through NEF).

[0315] In an embodiment (EB6’) that may be combined with other embodiments or used independently, UE-A / UE-B / MF / MRF is assigned an authorization token that may include one or more of:

[0316] UE ID,

[0317] Avatar ID,

[0318] Conditions for usage,

[0319] Key identifier to decrypt the Avatar model / metadata.

[0320] Key to decrypt / undo protections of the Avatar model / metadata.

[0321] In some cases, the key (identifier) to decrypt / undo protections of the Avatar model / metadata may be provided separately; this may allow, e.g., UE-B to provide the token with UE ID, Avatar ID, conditions for usage to another entity.

[0322] In an embodiment (EB7’) that may be combined with other embodiments or used independently, the Avatar model / metadata is provided in protected manner to UE-B / MF / MRF including a key identifier that identifies the key used to protect (or undo the protection).

[0323] In general, the above embodiments describe a method above is adapted to: verifying the authorization of a first device / user to use a digital asset representation and its identifier by a Network Function in charge of identity management; and upon successful authorization check, signing (and adding a digital signature of) the digital asset identifier to be exchanged by the originating IMS network; and verifying the signed digital asset identifier with a verification server by the terminating IMS network; and upon successful signature check, forwarding the digital asset identifier to a second device / user; and depending on the negotiated rendering type: retrieve the digital asset representation from the digital asset repository by XR application server and providing it to MF / MRF to perform network-centric rendering; or in case of UE-centric rendering, the second device / user's authorization to obtain the digital asset representation from a digital asset repository is checked by XR AS, and if successful, allow the second device / user to obtain the digital asset representation and perform UE-centric rendering.

[0324] To summarize, methods and systems have been presented for providing users, that are virtually present in a metaverse, with communications capabilities on their own real- life network and account by using an expanded metaverse authentication identity. This may include a communications credentialing process which can be performed from within the metaverse for communicating directly or indirectly with a user's mobile phone and a biometric process operating in a portal device (e.g., virtual reality headset) that can be invoked from within the metaverse, and a specific unique metaverse identity.

[0325] Although the embodiments were described in the context of virtual environments in a general sense, it is worth noting that the embodiments are applicable to metaverse services and applications enabled within the 3GPP system through the Service Enabler Architecture Layer (SEAL) providing 3GPP services to vertical applications, enabled through the Vertical Application Layer (VAL). Functionally, SEAL and VAL comprise both client-side (on the UE side) and server-side (on the network and / or 3rdparty metaverse service providers side) entities (i.e., SEAL / VAL Client, SEAL / VAL server(s)) which provide the client / server sides functionalities supporting metaverse services. As such, client and server-side functionalities described in the embodiments herein may be mapped to the functionalities provided by SEAL / VAL entities as described in the 3GPP system.

[0326] Although the embodiments were described in the context of a 5G network, their applications are not limited to such a type of network. They may be applied to any type of wireless or cellular network which provides suitable authentication and authorization signalling options.

[0327] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claims, from a study of the drawings, the disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. The foregoing description details certain embodiments. It will be appreciated, however, that no matter how detailed the foregoing appears in the text, these embodiments may be practiced in many ways, and is therefore not limited to the embodiments disclosed. It should be noted that the use of particular terminology when describing certain features or aspects should not be taken to imply that the terminology is being re-defined herein to be restricted to include any specific characteristics of the features or aspects with which that terminology is associated. Additionally, the expression "at least one of A, B, and C" is to be understood as disjunctive, i.e., as "A and / or B and / or C".

[0328] A single unit or device may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0329] The described operations like those indicated in the above embodiments may be implemented as program code means of a computer program and / or as dedicated hardware of the related network device or function, respectively. The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid- state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

Claims1. A method for managing privacy preferences for use of digital assets, comprising the apparatus storing privacy preferences for a user that owns / operates a set of digital assets, wherein the privacy preferences include one or more parameters indicative of whether or not the user allows: sharing information about digital / virtual assets to metaverse applications and / or to other users in the metaverse and / or rendering of digital / virtual assets in metaverse applications, and / or by the network, and / or at other users' UEs; or sharing contact information, communication preferences, communication history and / or usage data stored in a User Equipment, UE, or a metaverse virtual communications device, MVCD, with metaverse applications and / or with other users in the metaverse; or sharing audio / video input / output of an application running on, or a communication session / call from, a UE or MVCD with metaverse applications and / or with other users in the metaverse; or sharing information related to biometric methods and / or results thereof, or other biometric data of the user, or 5GS authentication credentials / in- formation, user / UE / MVCD related identities, and / or username / passwords, and / or any credentials associated with the UE, user, and / or MVCD with metaverse applications and / or with other users in the metaverse; the apparatus using one or more digital asset identifiers to identify the digital assets.

2. The method of claim 1, comprising the apparatus storing information about whether a confirmation by the user is to be requested for one or more of the stored privacy preferences or for one or more privacy parameters for which no privacy preference is stored.

3. The method of claim 1 or 2, comprising the apparatus using a subscription identifier or UE identifier or user identifier to identify the user.

4. The method of claim 3, comprising the apparatus transmitting a request to a UE related to the stored subscription identifier or to the stored UE identifier of the user.

5. The method of claim 1, comprising the apparatus storing privacy preferences in relation to at least one metaverse application or in relation to a particular UE / MVCD or in relation to a virtual area / location in the virtual environment or in relation to a Public Land Mobile Network, PLMN, or non-public network (NPN) and / or network entities within a PLMN or NPN, or in relation to a usage scenario or in relation to a set of users.

6. The method of any of the previous claims, comprising retrieving and / or checking the privacy preferences.

7. The method of claim 6, comprising the apparatus causing a UE or a MVCD to render a user interface dialog, said UE or MVCD being related to the stored subscription identifier or the stored UE or MVCD identifier of the user, wherein the user interface dialog enables to check the privacy preference for one or more of the stored privacy preferences for which confirmation by the user is requested or for one or more privacy parameters for which no privacy preference is stored.

8. The method of claim 6 or 7, wherein the step of retrieving and / or checking the privacy preferences includes receiving a request from a first device to retrieve a privacy preference for use of one or more digital assets by the first or second device, and to provide the result of the retrieval or check to the first device.

9. The method of claim 8, comprising retrieving the preferences for sharing information pertaining to a set of digital assets, based on a request from a first device, and verifying by the apparatus or by the first device whether or not sharing of the requested information (or subset thereof) to a second device is allowed or not.

10. The method of claim 9, comprising, upon determination that sharing of the requested information to the second device is allowed, sharing the requested sharing information to the second device and upon determination that sharing of the requested information to the second device is not allowed, providing an error message to the second device.

11. The method of claim 8 or 9 or 10, comprising the apparatus authenticating the first and / or second device.

12. The method of claim 6 to 11, comprising storing digital assets, and if the privacy preferences allow sharing of the digital assets to the first or second device, allowing retrieval of stored digital assets by the first or second device and / or transmitting the stored digital asset to the first or second device and if the privacy preferences do not allow sharing of the digital assets to the first or second device, providing an error message.

13. The method of claim 12, wherein the apparatus is a digital asset repository and / or a UE.

14. The method of claim 13, wherein the step of retrieving and / or checking the privacy preferences is performed after receiving a request from a first device or second device to retrieve one or more digital assets, and to provide the result of the retrieval or check to the first device or second device.

15. The method of any of the preceding claims, comprising the apparatus obtaining authentication information from a subscriber identity module operated by a real-world communication device (10) associated with the user, or a part thereof, or a copy of the subscribed identity module operated by a virtual communication device in a metaverse implementation (30) or from a biometric method performed at a paired portal device (20).

16. An apparatus, comprising a communication unit including a receiver and a transmitter; a controller, a data storage including instructions which when executed cause the apparatus to: store privacy preferences for a user that owns / operates a set of digital assets, wherein the privacy preferences include one or more parameters indicative of whether or not the user allows: sharing information about digital / virtual assets to metaverse applications and / or to other users in the metaverse and / or rendering of digital / virtual assets in metaverse applications, and / or by the network, and / or at other users' UEs; or sharing contact information, communication preferences, communication history and / or usage data stored in a User Equipment, UE, or a metaverse virtual communications device, MVCD, with metaverse applications and / or with other users in the metaverse; or sharing audio / video input / output of an application running on, or a communication session / call from, a UE or MVCD with metaverse applications and / or with other users in the metaverse; or sharing information related to biometric methods and / or results thereof, or other biometric data of the user, or 5GS authentication credentials / in- formation, user / UE / MVCD related identities, and / or username / passwords, and / or any credentials associated with the UE, user, and / or MVCD with metaverse applications and / or with other users in the metaverse; using one or more digital asset identifiers to identify the digital assets.

17. An apparatus for operating a virtual communication device (MVCD) in a metaverse implementation (30), wherein the apparatus is configured to: perform an IP Multimedia Subsystem, IMS, communication session with other communication devices on behalf of a real-world communication device (10); render A / V input received from other communication devices or from the real- world communication device;generate A / V output from input received from one or more users or digital assets related to a user, and application layer rendering information.

18. A method for operating a virtual communication device (MVCD) in a metaverse implementation (30), wherein the method comprises: perform an IMS communication session with other communication devices on behalf of a real-world communication device (10); render A / V input received from other communication devices or from the real-world communication device; and generate A / V output from input received from one or more users or digital assets related to a user, and application layer rendering information.

19. A method for operating a virtual communication device (MVCD) in a metaverse implementation (30), comprising: establishing a secure communication channel with a real-world communication device (10); synchronizing state information between the real-world communication device and the virtual communication device through the secure communication channel; performing one or more of the following operations:■ perform an action on behalf of the real-world communication device, or■ perform the same operations as the real-world communication device, or■ perform a simulation of the real-world communication device.

20. An apparatus for operating a virtual communication device (MVCD) in a metaverse implementation (30), wherein the apparatus is configured to:Establish a secure communication channel with a real-world communication device (10);Synchronize state information between the real-world communication device and the virtual communication device through the secure communication channelPerform one or more of the following operations:■ Perform an action on behalf of the real-world communication device,■ Perform the same operations as the real-world communication device,■ Perform a simulation of the real-world communication device.

21. An apparatus for registering a virtual communication device in a metaverse implementation (30), wherein the apparatus is configured to: obtain authentication and credential information of a user; package the authentication and credential information; generate an extended authentication code based on the packaged authentication and credential information; and access the metaverse implementation (30); and register the virtual communication device in the metaverse implementation (30) by using the extended authentication code.

22. The apparatus of claim 21, wherein the apparatus is configured to derive the credential information from a subscriber identity module of the real-world communication device (10) associated with the user, or a part thereof, or a copy of the subscriber identity module, in particular a clone of an embedded subscriber identity module running in a virtual embedded universal integrated circuit card.

23. The apparatus of claim 22, wherein the credential information is metaverse implementation or application specific, and / or wherein the credential information is derived based on one or moreof the following parameters: long-term security credentials stored in the Subscriber Identity Module, a communication device (10) identifier, a virtual communication device identifier, a metaverse implementation / application identifier,a synchronization parameter, and a freshness parameter.

24. The apparatus of claims 21, 22 or - 23, wherein the apparatus is configured to obtain the authentication information from a biometric method performed at a paired portal device (20), in particular a virtual reality headset, wherein the biometric method can be invoked from within a virtual environment, in particular the metaverse implementation (30).

25. The apparatus of any one of claims 21-24, wherein the credential information comprises a unique metaverse identity of the user, in particular a unique username and password of the user.

26. A communication device (10) comprising the apparatus of any one of claims 21 to 25.

27. An apparatus (304) for registering a virtual communication device in a metaverse implementation (30), wherein the apparatus is configured to: receive an extended authentication code of a user from a real-world communication device (10); register a virtual communication device for the user in the metaverse implementation (30) by using the extended authentication code; extract authentication and credential information of the user from the extended authentication code; attach the extracted authentication and credential information to the registered virtual communication device; and registerthe virtual communication device for the user in a real-world communication network (40) by using the extracted credential information.

28. The apparatus according to claim 27, wherein the apparatus (304) is configured to communicate with a subscriber identity module of the real-world communication device (10).

29. A metaverse implementation (30) comprising the apparatus of claims 17, 20,27 or 28.

30. A communication system comprising one or more communication devices of claim 6 and a metaverse implementation of claim 29.

31. The system of claim 30, wherein the system is configured to provide communication capabilities of the real-world communication network (40) within the metaverse implementation (30), wherein the virtual communication device can be used to initiate a communication session with other entities and / or users inside or outside the metaverse implementation (30).

32. The system of claim 30 or 31, wherein the system is configured to provide authorization and / or privacy control over data that is exposed to metaverse applications or providers or other users within the metaverse implementation (30), wherein the authorization and / or privacy control is based on access tokens for ensuring that virtual communications services are part of the user's subscription plan and / or for requesting security materials from the real-world communication network (40), and / or privacy profiles for determining which data the user allows to share in which context and with which entities.

33. The system of any one of claims 30 to 32, wherein the system is configured to allow porting predetermined tasks and / or data to the virtual communications device, wherein the predetermined tasks and / or data comprise one or more of: receiving and sending calls by the virtual communication device over the real-world communication network (40) assigned to the user's standard network account and / or subscription; transferring a biometric method and / or result conducted on the user for authentication purposes to the virtual communications device for use by the virtual communications device to establish authentication of a user's identity using real-world biometrics; or using the credential and authentication information to establish an identity authentication for the user when logging into the metaverse implementation (30) and allowing the virtual communication device to be used as primary and / main communication device.

34. A method of registering a virtual communication device in a metaverse implementation (30), wherein the method comprises: obtaining authentication and credential information of a user; packaging the authentication and credential information; generating an extended authentication code based on the packaged authentication and credential information; and accessing the metaverse implementation (30) and registering the virtual communication in the metaverse implementation (30) by using the extended authentication code.

35. A method of registering a virtual communication device in a metaverse implementation (30), wherein the method comprises: receiving an extended authentication code of a user from a real-world communication device (10); registering a virtual communication device for the user in the metaverse implementation (30) by using the extended authentication code; extracting authentication and credential information of the user from the extended authentication code; attaching the extracted authentication and credential information to the registered virtual communication device; and registering the virtual communication device for the user in a real-world communication network (40) by using the extracted credential information.

36. A computer program product comprising code means for producing the steps of claim 34 or 35 when run on a computer device.

37. A method, comprising establishing an end-to-end communication channel between a real-world communication device (UE) and a virtual communication device (MVCD) based on a shared symmetric key and secret or decapsulation keys, wherein said shared symmetric key is derived through a key exchange or a key encapsulation mechanism using public or encapsulation keys,wherein thesecret or decapsulation keys are associated with the real-world communication device (UE) and a virtual communication device (MVCD), wherein the public key pair generated by the MVCD is ephemeral.

38. The method of claim 37, wherein the end-to-end communication channel is established between a core network and a virtual communication device (MVCD) through a third party metaverse services provider.

39. The method of claim 37, wherein the virtual communication device is a digital twin of the real-world communication device (UE).

40. An apparatus, comprising a transmitter, a receiver, a controller and a data storage including instructions which cause the apparatus to establish an end-to-end communication channel between a real-world communication device (UE) and a virtual communication device (MVCD) based on a shared symmetric key and secret or decapsulation keys, wherein said shared symmetric key is derived through a key exchange or a key encapsulation mechanism using public or encapsulation keys, wherein thesecret or decapsulation keys are associated with the real-world communication device (UE) and a virtual communication device (MVCD), wherein the public key pair generated by the MVCD is ephemeral.

41. A method comprising, deriving a fresh root security key by a real-world communication device (UE) wherein the derivation of said root security key comprises one or more, or a combination of at least two of the following parameters:Master Key, which may be stored in a USIMUE identifier, digital asset identifier, vertical application layer server and / or client identifier(s),synchronization parameter, freshness parameter, which may be a random nonce, or a time value, wherein, said root security key is provided to the virtual communication device to serve as the root of security for the communication link to be established between the virtual communication device and the network.

42. An apparatus comprising, a transmitter, a receiver, a controller and a data storage including instructions which cause the apparatus to derive a fresh root security key by a real-world communication device (UE) wherein the derivation of said root security key comprises one or more, or a combination of at least two of the following parameters:Master Key, which may be stored in a USIMUE identifier, digital asset identifier, vertical application layer server and / or client identifier(s), synchronization parameter, freshness parameter, which may be a random nonce, or a time value, wherein, said root security key is provided to the virtual communication device to serve as the root of security for the communication link to be established between the virtual communication device and the network.

43. A method comprising, splitting control plane and / or user plane traffic data between a real-world communication device (UE) and a virtual communication device, wherein the subset of control plane and / or user plane traffic to be routed to the virtual communication device is determined based on a network policy or configuration, said network policy or configuration authorizing services for consumption within a metaverse im- plementation / application.

44. The method of claim 43, comprisingsuspending or terminating the control / user plane traffic data split, based on the fulfillment of at least one of the following conditions: service authorization revocation by the network, metaverse service provider, or the user, - service authorization expiry, activity detected, by the network, on the real-world communication device, inactivity for a pre-configured duration, detected by the metaverse service provider and indicated to the network.

45. An apparatus, comprising a transmitter, a receiver, a controller and a data storage including instructions which cause the apparatus to split control plane and / or user plane traffic data between a real-world commu- nication device (UE) and a virtual communication device, wherein the subset of control plane and / or user plane traffic to be routed to the virtual communication device is determined based on a network policy or configuration which authorizes services for consumption within a metaverse implementation / application.

Images