Method and device for performing avatar calling in wireless communication system

Abstract

The present disclosure presents a method and device for negotiating a shared scene-based avatar calling in implementing a method for performing an avatar calling in a wireless communication system or a mobile communication system. A method performed by a user equipment (UE) related to a user equipment scene manager (USM) according to an embodiment may comprise the steps of: establishing a session for a shared scene-based avatar calling with a network entity related to a scene manager (SM); receiving an avatar list related to the UE from an avatar storage entity via the network entity; selecting an avatar from the avatar list for the avatar calling; transmitting an identifier of the selected avatar to the network entity; and receiving, from the network entity, information about a shared scene updated on the basis of the selected avatar.

Description

Method and device for performing avatar calls in a wireless communication system

[0001] The present disclosure relates to a wireless communication system or a mobile communication system. Specifically, it relates to a method and apparatus for performing an avatar call in a wireless communication system.

[0002] 5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in frequency bands below 6 GHz ('Sub 6 GHz'), such as 3.5 gigahertz (3.5 GHz), but also in ultra-high frequency bands called millimeter waves (mmWave), such as 28 GHz and 39 GHz ('Above 6 GHz'). In addition, for 6G mobile communication technology, which is referred to as a system beyond 5G, implementation in the terahertz (THX) band (e.g., the 3 terahertz band at 95 GHz) is being considered to achieve transmission speeds 50 times faster and ultra-low latency reduced to one-tenth compared to 5G mobile communication technology.

[0003] In the early stages of 5G mobile communication technology, aiming to satisfy service support and performance requirements for enhanced Mobile BroadBand (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), technologies such as beamforming and Massive MIMO to mitigate path loss and increase transmission distance in ultra-high frequency bands, support for various numerologies (such as the operation of multiple subcarrier spacings) and dynamic operation of slot formats for the efficient utilization of ultra-high frequency resources, initial access techniques to support multi-beam transmission and broadband, definition and operation of Band-Width Parts (BWP), Low Density Parity Check (LDPC) codes for high-volume data transmission, new channel coding methods such as Polar Codes for the reliable transmission of control information, and L2 pre-processing (L2 Standardization has been carried out for pre-processing, network slicing which provides a dedicated network specialized for specific services, and other methods.

[0004] Currently, discussions are underway to improve and enhance the performance of the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support. Additionally, standardization of the physical layer is in progress for technologies such as V2X (Vehicle-to-Everything), which helps autonomous vehicles make driving decisions and enhance user convenience based on their own location and status information transmitted by the vehicle; NR-U (New Radio Unlicensed), which aims for system operation in unlicensed bands to comply with various regulatory requirements; NR terminal low power consumption technology (UE Power Saving); Non-Terrestrial Network (NTN), which is direct terminal-satellite communication for securing coverage in areas where communication with the terrestrial network is impossible; and positioning.

[0005] In addition, standardization is underway in the field of wireless interface architecture / protocols for technologies such as the Industrial Internet of Things (IIoT) for supporting new services through linkage and convergence with other industries, Integrated Access and Backhaul (IAB) which provides nodes for expanding network service areas by integrating wireless backhaul links and access links, Mobility Enhancement including Conditional Handover and Dual Active Protocol Stack (DAPS) Handover, and 2-step Random Access (2-step RACH for NR) which simplifies random access procedures. Standardization is also underway in the field of system architecture / services for 5G baseline architectures (e.g., Service based Architecture, Service based Interface) for incorporating Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC), which provides services based on the location of the terminal.

[0006] When such 5G mobile communication systems are commercialized, connected devices, which are increasing explosively, will be connected to communication networks. Accordingly, it is expected that there will be a need to enhance the functionality and performance of 5G mobile communication systems and to integrate the operation of connected devices. To this end, new research is planned to be conducted on 5G performance improvement and complexity reduction, support for AI services, support for metaverse services, and drone communication using eXtended Reality (XR), Artificial Intelligence (AI), and Machine Learning (ML) to efficiently support Augmented Reality (AR), Virtual Reality (VR), and Mixed Reality (MR).

[0007] Furthermore, the advancement of these 5G mobile communication systems encompasses multi-antenna transmission technologies such as new waveforms to guarantee coverage in the terahertz band of 6G mobile communication technology, Full Dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas; metamaterial-based lenses and antennas to improve terahertz band signal coverage; high-dimensional spatial multiplexing technology using OAM (Orbital Angular Momentum); and Reconfigurable Intelligent Surface (RIS) technology; as well as Full Duplex technology for enhancing frequency efficiency and system networks in 6G mobile communication technology; AI-based communication technologies that realize system optimization by utilizing satellites and AI from the design stage and internalizing end-to-end AI support functions; and the realization of services of complexity exceeding the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could serve as a foundation for the development of next-generation distributed computing technologies.

[0008] The present disclosure presents a method and apparatus for negotiating a shared scene-based avatar call in implementing a method for performing an avatar call in a wireless communication system or a mobile communication system. The technical problems to be solved by the present disclosure are not limited to those mentioned above, and other unmentioned technical problems will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

[0009] A method performed by a user equipment (UE) associated with a user equipment scene manager (USM) according to one embodiment for solving the above-described problem may include: establishing a session for a shared scene-based avatar call with a network entity associated with a scene manager (SM); receiving an avatar list associated with the UE from an avatar storage entity via the network entity; selecting an avatar from the avatar list for the avatar call; transmitting an identifier of the selected avatar to the network entity; and receiving information about a shared scene updated based on the selected avatar from the network entity.

[0010] A method performed by a network entity associated with a scene manager (SM) according to one embodiment for solving the above-described problem may include: establishing a session for a shared scene-based avatar call with a user equipment (UE) associated with a user equipment scene manager (USM); transmitting to the UE an avatar list associated with the UE received from an avatar storage entity; receiving from the UE an identifier of an avatar selected from the avatar list for the avatar call; updating the shared scene based on the selected avatar; and transmitting information about the updated shared scene to the UE.

[0011] A user equipment (UE) associated with a user equipment scene manager (USM) in a wireless communication system according to one embodiment for solving the above-described problem comprises: at least one transceiver; at least one processor communicatively coupled to the at least one transceiver; and at least one memory communicatively coupled to the at least one processor for storing instructions, wherein the instructions are executed individually or in any combination by the at least one processor, so that the UE: establishes a session for a shared scene-based avatar call with a network entity associated with the scene manager (SM); receives an avatar list associated with the UE from an avatar storage entity via the network entity; selects an avatar from the avatar list for the avatar call; transmits an identifier of the selected avatar to the network entity; and receives information about a shared scene updated based on the selected avatar from the network entity.

[0012] A network entity associated with a scene manager (SM) in a wireless communication system according to one embodiment for solving the above-described problem comprises: at least one processor; and at least one memory that is communicationally coupled to the at least one processor and stores instructions, wherein the instructions are executed individually or in any combination by the at least one processor, so that the network entity: establishes a session for a shared scene-based avatar call with a user equipment (UE) associated with a user equipment scene manager (USM); transmits to the UE an avatar list associated with the UE received from an avatar storage entity; receives from the UE an identifier of an avatar selected from the avatar list for the avatar call; updates the shared scene based on the selected avatar; and transmits information about the updated shared scene to the UE.

[0013] FIG. 1 is a diagram showing the structure of a wireless communication system that provides voice and video calls in a mobile communication network according to various embodiments of the present disclosure.

[0014] FIG. 2 is a drawing showing an avatar call system according to various embodiments of the present disclosure.

[0015] FIG. 3 is a diagram showing operations performed between a USM and a scene manager in an avatar call system according to various embodiments of the present disclosure.

[0016] FIG. 4 is a diagram illustrating operations performed between a USM, a scene manager, and an avatar storage in an avatar call system according to various embodiments of the present disclosure.

[0017] FIG. 5 is a diagram showing operations performed between a USM and a scene manager that update a scene in an avatar call system according to various embodiments of the present disclosure.

[0018] FIG. 6 is a diagram illustrating operations performed between a USM and a scene manager that update a scene in an avatar call system according to various embodiments of the present disclosure.

[0019] FIG. 7 is a diagram illustrating operations performed between a USM and a scene manager that update a scene in an avatar call system according to various embodiments of the present disclosure.

[0020] FIG. 8 illustrates an example in which a terminal USM manages update details in an avatar call system according to various embodiments of the present disclosure.

[0021] FIG. 9 illustrates an example in which a terminal USM manages update details in an avatar call system according to various embodiments of the present disclosure.

[0022] FIG. 10 is a diagram showing a plurality of nodes in an avatar call system according to various embodiments of the present disclosure.

[0023] FIG. 11 illustrates the structure of a terminal according to various embodiments of the present disclosure.

[0024] FIG. 12 illustrates the structure of a server according to various embodiments of the present disclosure.

[0025] FIG. 13 illustrates the structure of a network entity according to various embodiments of the present disclosure.

[0026] Various aspects of the claimed subject matter are described with reference to the drawings, in which similar reference numerals are used to denote similar elements. In the following description, for the purpose of explanation, a number of specific details are described to provide a sufficient understanding of one or more embodiments. However, it may be apparent that the embodiments can be practiced without these specific details.

[0027] The terms used in this disclosure are used merely to describe specific embodiments and are not intended to limit the scope of other embodiments. A singular expression may include a plural expression unless the context clearly indicates otherwise. Terms used herein, including technical or scientific terms, may have the same meaning as generally understood by those skilled in the art described in this disclosure. Terms used in this disclosure that are defined in a general dictionary may be interpreted as having the same or similar meaning as they have in the context of the relevant technology, and are not to be interpreted in an ideal or overly formal sense unless explicitly defined in this disclosure. In some cases, even terms defined in this disclosure are not to be interpreted to exclude the embodiments of this disclosure.

[0028] Terms referring to signals used in the following description (e.g., message, signal, signaling, sequence, stream), terms referring to resources (e.g., symbol, slot, subframe, radio frame, subcarrier, RE (resource element), RB (resource block), BWP (bandwidth part), occurrence), terms for operations (e.g., step, method, process, procedure), terms referring to data (e.g., information, parameter, variable, value, bit, symbol, codeword), terms referring to channels, terms referring to control information (e.g., DCI (downlink control information), MAC CE (medium access control codeword element), RRC (radio resource control) signaling), terms referring to network entities, terms referring to device components, etc., are used for the convenience of explanation This is an example. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meanings may be used.

[0029] Various embodiments of the present disclosure are described herein in relation to wireless terminals. A wireless terminal may refer to a device that provides voice and / or data access to a user. A wireless terminal may be connected to a computing device, such as a laptop computer or a desktop computer, or may be a self-contained device, such as a personal portable information terminal (PDA). A wireless terminal may also be referred to as a system, subscriber unit, subscriber station, mobile station, mobile, mobile device, remote station, remote terminal, access terminal, user terminal, terminal, wireless communication device, user agent, user device, or user equipment. A wireless terminal may be a subscriber station, wireless device, cellular phone, PCS phone, wireless phone, Session Initiation Protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), portable device with wireless access capability, or other processing device connected to a wireless modem. A base station (e.g., an access point) may refer to a device within an access network that communicates with wireless terminals at a wireless interface through one or more sectors.

[0030] IMS Architecture Overview

[0031] FIG. 1 is a diagram showing the structure of a wireless communication system that provides voice and video calls in a mobile communication network according to various embodiments of the present disclosure. Specifically, FIG. 1 is a diagram showing the structure of a wireless communication system that provides voice and video calls in a mobile communication network.

[0032] FIG. 1 illustrates an IMS (Internet Protocol Multimedia Subsystem; IP Multimedia Subsystem) architecture that a first terminal (user equipment 1; UE1) can use for real-time multimedia transmission and reception with a second terminal (UE2), and the description of the functions of the components is as follows.

[0033] The P-CSCF (Proxy-Call Session Control Function) serves as the first point of contact in the IMS network and is responsible for communication between the user terminal and the IMS network. This functional element handles SIP (Session Initiation Protocol) requests and responses and can forward user requests to the S-CSCF (Serving-Call Session Control Function). The P-CSCF also performs authentication and security processing and can route requests from the user terminal to the appropriate location within the IMS network. Additionally, the P-CSCF can support network roaming functions.

[0034] The Serving-Call Session Control Function (S-CSCF) is a core element of the IMS network capable of managing and controlling user sessions. This functional element routes SIP messages and handles user registration and authentication. The S-CSCF communicates with the Home Subscriber Server (HSS) to query user profiles and establish sessions. Additionally, the S-CSCF provides interfaces with various application services to control and coordinate them.

[0035] The Home Subscriber Server (HSS) is a database that stores and manages user information within an IMS network. The HSS can manage user profiles, including user authentication, authorization, and location management. The HSS communicates with the S-CSCF to provide user information and can provide all essential information about the user.

[0036] Unified Data Management (UDM) can provide the ability to manage data related to user profiles in 5G networks. UDM is a network function designed according to 3GPP (3rd Generation Partnership Project) standards and can perform roles related to user profile management, session management, authentication and authorization, policy and rule enforcement, and data synchronization and distribution in 5G core networks.

[0037] An IMS AS (Application Server) is a server that provides various applications and services within an IMS network. The IMS AS supports a wide range of SIP-based application services, enabling it to provide various services to users, such as voice, video, and messaging. It communicates with the S-CSCF to process service requests and performs various functions necessary for service provision.

[0038] The Data Channel Signaling Function (DCSF) performs the function of managing signals related to data channels in an IMS network. The DCSF is used to initialize and control the data channel through which application data is transmitted. This function is an essential element for efficiently supporting real-time data transmission as well as multimedia services, particularly within an IMS network. One of the primary roles of the DCSF is to establish the data channel. This involves defining and setting data channel parameters using protocols such as the Session Initiation Protocol (SIP) or Session Description Protocol (SDP). For example, these parameters may include the channel type, bandwidth, and transmission format. After establishing the data channel, the DCSF continuously manages it. This may include functions such as monitoring the channel status, maintaining sessions, resetting, and terminating sessions. Furthermore, the DCSF handles changes that may occur while a session is maintained, thereby ensuring stable data transmission.

[0039] DCAR (Data Channel Application Repository; DC Application Repository) is a component in the IMS architecture that stores and processes user data. DCAR can create a data channel (data transmission) for a user to use data communication services, and user data or carrier applications stored within DCAR can be transmitted to the user terminal via DCSF and MF (Media Function).

[0040] A Media Function (MF) is a functional element responsible for media streaming and processing within an IMS network. The MF processes media such as voice, video, and data, and can manage media streams in cooperation with a Media Gateway. This supports seamless media transmission and processing. The Media Function can process media streams generated from various services, such as calls, video streaming, and video conferencing. This ensures that multimedia data between users is delivered in high quality and supports users in utilizing services in the intended manner.

[0041] The IMS-AGW (IMS Access Gateway) is a gateway that provides an interface between the IMS network and an external network. The IMS-AGW supports interoperability between the external network and the IMS network and can convert and transmit SIP signals and media streams. This gateway can ensure seamless communication with the external network.

[0042] The Data Channel Application Server (DCAS) is a server that acts as part of the IMS architecture to deliver various application data over data channels. It is designed to efficiently handle data transmission as well as SIP-based multimedia sessions within an IMS network. The DCAS can manage the transmission of data other than media streams. This data can include various formats such as text, files, application-related data, and status updates. For example, it provides functions such as sharing files during video conferences or synchronizing location information in real-time games. The DCAS uses SIP to establish, maintain, and terminate sessions. It coordinates data channel settings via SIP messaging, thereby enabling bidirectional data transmission. The DCAS can support various data formats, meaning it can be used in multiple applications and services. Examples include real-time data synchronization for business applications, communication with IoT (Internet of Things) devices, or real-time chat applications. As part of the IMS architecture, the DCAS can operate in conjunction with other IMS components. For instance, it can perform session control in conjunction with the CSCF and handle user authentication and authorization management in conjunction with the HSS.

[0043] Based on the aforementioned components, the UE can request a connection to the counterpart terminal as follows.

[0044] First, the UE sends a request to the P-CSCF via a Session Initiation Protocol (SIP) Invitation Message to establish a data channel with the counterpart terminal. This SIP message includes media-related parameters and multiplexing requirements within the Session Description Protocol (SDP). Additionally, to utilize IMS data channel services, the UE may include an SDP offer containing bootstrap information within the SIP Invitation Message, along with an SDP offer for an existing video or audio session connection.

[0045] The P-CSCF can forward received SIP messages to the S-CSCF. The S-CSCF is a key functional element responsible for session control within the IMS network; it manages UE sessions and interacts with the associated application server (IMS AS). The S-CSCF can process messages, verify user authentication and authorization if necessary, and then forward the messages to the IMS AS. Upon receiving a SIP INVITE message containing the aforementioned SDP information, the S-CSCF can forward the contents of the bootstrap-related SDP offer to the IMS AS if the SIP INVITE message includes a bootstrap data channel SDP offer for a data channel service connection request. At this time, the S-CSCF can check whether the terminal or network supports IMS-DC based on the contents of the received bootstrap-related SDP offer. If both parties support the data channel, the S-CSCF may decide to forward information for the bootstrap data channel connection to the IMS AS.

[0046] Upon receiving a bootstrap-related SDP offer message from the S-CSCF, the IMS AS can first check with the HSS (home subscriber server) whether the relevant UE or subscriber can use the data channel service. If the user cannot use the data channel based on the user's user profile, the IMS AS can perform a multimedia telephony (MMTel) session setup operation without a data channel connection through the standard IMS process. Additionally, if the user cannot use the data channel-based service, the IMS AS can update the SIP INVITE message received from the S-CSCF by deleting the data channel (DC) related media information from the message, and then forward the updated SIP INVITE message to the S-CSCF.

[0047] The S-CSCF can forward a UE's data channel request to the IMS AS. The IMS AS is a node that performs various service logic and can initiate interactions with the DCSF and MF based on the data channel setup request. The IMS AS can analyze the request and initiate a signaling procedure to establish the data channel.

[0048] If the service user can utilize a service based on the IMS data channel, the IMS AS can communicate with the DCSF to perform data channel bootstrapping via a data channel call request as part of the signaling process for data channel setup. The IMS AS can select a DCSF by performing discovery and selection of a DCSF instance via the NRF (network repository function) based on the network operator's local configuration or information transmitted from the UE. Through the above process, the IMS AS can deliver a Session Event Control Notification (SessionEventControl_Notify) message containing information such as SessionEstablishmentRequestEvent, Session ID, CallingID, CalledID, SessionCase, Event initiator, MediaInfoList, and DC Stream ID to the DCSF selected. The DCSF is responsible for the setup, management, and control of the data channel and can generate and deliver necessary SIP / SDP (Session Description Protocol) signaling messages. The DCSF can set data channel parameters in accordance with the request from the IMS AS and manage the process to ensure that the data channel is correctly configured on the counterparty terminal side as well. In addition, DCSF can determine MDC1 media information so that the UE can download applications through MF or MRF (Media Resource Function).

[0049] Based on the above decision information, the DCSF can send a MediaControl_MediaInstruction message containing information such as SessionID and MediaInstructionSet to the IMS AS. The DCSF can send the MDC1 media endpoint address, DC stream ID, and alternative information for the URL (uniform resource locator) of the application list delivered from the MDC1 interface to the IMS AS by including these in the MediaInstructionSet. Based on this, the DCSF can provide the IMS AS with a policy regarding how the originating and terminating sides can create bootstrap data channels using MF.

[0050] IMS AS can select an MF by using NRF to search for and select an MF instance or enhanced MRF that supports local settings or DC media functions.

[0051] The IMS AS may transmit a list of Media Termination Descriptors to the MF selected in the above process via the Nmf_MRM_Create message. The IMS AS may request the creation of two different Media Terminations. One Media Termination information may be information related to local bootstrap media, and the other may represent information related to remote bootstrap media to be provided to a remote UE. Each Media Termination may include information requesting resource allocation for the Mb and MDC1 interfaces. The MF may transmit the result of the negotiation of the corresponding data channel media resource information to the IMS AS.

[0052] After completing signal processing of the data channel based on MF information received from the IMS AS, the DCSF communicates with the Media Function (MF) to process the media stream. The MF is responsible for processing the actual media data (e.g., audio, video, etc.) to be transmitted through the data channel. The MF prepares necessary tasks such as transcoding, mixing, and conversion of the media stream, and establishes the data transmission path. During this process, the MF performs QoS (quality of service) management and security functions to ensure stable data transmission.

[0053] When the DCSF and MF successfully establish a data channel, the IMS AS can send a SIP INVITE message to the S-CSCF containing an updated SDP offer with media information added from the MF or enhanced MRF. The S-CSCF can forward the received SIP INVITE message containing the updated SDP offer to the remote network and UE#2. Once the data channel is established, data transmission between the UE and the counterpart terminal begins. This data channel is connected between the UE, the MF, and the counterpart terminal, and the MF can transmit data in real time while processing media data and performing necessary conversion operations.

[0054] The avatar call service described below is provided by DCAS and can be provided as a Scene manager in DCAS, DCSF, or MF, etc., and the USM of the terminal can be executed in UEs such as UE1, UE2, etc. Message communication and data exchange between the Scene manager and the USM can be performed directly with MF or through a data channel interface such as Mb, MDC1, or MDC2 via MF.

[0055] Scene Management

[0056] FIG. 2 is a drawing showing an avatar call system according to various embodiments of the present disclosure.

[0057] An avatar call system may have a concept of space where avatar call participants can position other participants and objects from their respective locations. In this disclosure, the description of the space is recorded in and exchanged in data called a Scene graph (hereinafter referred to as "scene"), and the technical grammar describing the Scene is called a Scene description. The Scene has a tree structure, that is, connected by a parent node and one or more child nodes, and each child node has a data model that can become another parent node, and the address from the top-level parent node to each node is called a node path. The node indicated by the node path is unique and singular.

[0058] In order to describe the participants' space based on a Scene, modify it according to the participants' interactions, and share it among the participants, the Avatar Calling System and the participants' terminals may each have a Scene Manager as a component. For distinction, in this disclosure, the Scene Manager of the Avatar Calling System is referred to as the Scene Manager (or SM), and the Scene Manager of the terminal (UE) is referred to as the UE Scene Manager (hereinafter USM).

[0059] The types of scenes managed by the Scene manager of the avatar call system and the USM of the terminal may include shared scenes provided to all participants in common, and individual changes provided to each participant. Additionally, within the scenes managed by the terminal's USM, spatial descriptions specific to the terminal may exist as local changes and may not be provided to other participants.

[0060] The Scene manager can transmit the shared scene and individual changes to the USMs of the participants' terminals, or create and transmit a personalized shared scene for UE that combines the shared scene and individual changes for each participant.

[0061] The shared scene and individual changes received by the terminal can be combined by USM, and the combined result is called a personalized shared scene. The result of applying the aforementioned local changes to the personalized shared scene can also be called a personalized shared scene.

[0062] A shared scene can be delivered to all participants. Content applicable to all participants in common can be recorded within the shared scene. When the USM of all participants' terminals receives both the shared scene and individual changes, it can apply the individual changes to the shared scene to configure a personalized shared scene.

[0063] USM can internally store shared scenes and individual changes separately and update them individually, or it can create personalized shared scenes and store, manage, or update only those personalized shared scenes. When sending update requests to the Scene Manager to receive updates, USM can distinguish between requesting and receiving shared scenes, individual changes, or personalized shared scenes.

[0064] The Scene Manager can record details in Individual changes for each participant that differ from the shared scene by participant, i.e., by device. Individual changes can be described as changes to the shared scene or can be a standalone scene.

[0065] For example, in a scene with two participants, the shared scene consists of Participant 1's avatar, Participant 2's avatar, and a conference table. Participant 1's individual changes may include adding a camera facing Participant 2 to modify their position and orientation, while Participant 2's individual changes may include adding a camera facing Participant 1 to modify their position and orientation. The USM on Participant 1's terminal can receive the shared scene and apply individual changes to create a personalized shared scene composed of Participant 1, Participant 2, the conference table, and a camera facing Participant 2. Similarly, the USM on Participant 2's terminal can read the shared scene and apply individual changes to create a personalized shared scene composed of Participant 1, Participant 2, the conference table, and a camera facing Participant 1. The content of each participant's individual changes may include specifying nodes in the shared scene and adding nodes below them.

[0066] The USM of the terminal may receive instructions from the participant (user) regarding whether the scope of application of changes resulting from the participant's interaction applies to all participants, some participants, or is limited only to the terminal itself. Depending on the instructed scope of application of changes resulting from the interaction, the USM may apply the corresponding changes to a shared scene, individual changes, or local changes.

[0067] The terminal's USM lists local changes for changes specific to the terminal itself that are not shared with other users or the Scene manager.

[0068] The USM of the terminal may be applied only to local changes if it is specified that the change is valid only for the terminal as an option for the participant's interaction, or if it is determined to be a change equivalent thereto.

[0069] For example, information regarding the start time of Participant 1's avatar usage and the release (decryption) of the encryption session can be recorded as attribute information in a node dependent on the avatar in the scene as details generated during avatar usage; however, since this information is recorded for the USM to manage only within the terminal, it may not need to be transmitted to other users or the scene manager. In this case, the USM records the relevant information within local changes and combines it with shared scenes and individual changes for use; even if a new version of the shared scene or individual changes is received, the local changes can be combined and used without being recreated.

[0070] As another example, Participant 1 can open a notepad visible only to Participant 1 during a call with Participant 2 and write down thoughts that come to mind during the call. Participant 1 does not want the written content to be transmitted to the other party or even to the service server, so they can select "Do not share with call participants" as an option when adding the notepad.

[0071] The personalized shared scene is the final result displayed on the terminal, and may be the result of combining individual changes and local changes with the shared scene received by the terminal's USM.

[0072] The content of the participant's scene being tracked by the Scene manager of the avatar call system and the personalized shared scene displayed by the participant terminal's USM are characterized by being identical, except for the content of local changes managed by the terminal USM.

[0073] [Update]

[0074] Common and individual management

[0075] When an avatar call according to the present disclosure is initiated, a message transmission channel session for scene exchange between the Scene manager and the USM of each participant's terminal may be established. The Scene manager generates spatial information (i.e., a scene) that allows participants to share a spatial interaction experience and transmits it to the USMs, and receives and redistributes changes made by participants from the USMs to maintain synchronization of spatial information between the participant terminals.

[0076] Information regarding whether each node within Personalized shared scenes, Shared scenes, or individual changes transmitted by the Scene Manager to the USM can be modified by that USM may be provided. Whether a specific terminal is allowed to modify a node may be indicated in a sub-location of that node or in a separate location within the scene. For example, if a node is marked as read / write accessible to all participants, all USMs can read, modify, or delete that node and its child nodes. As another example, if a node is marked as read-only accessible to a specific participant, that participant's USM may only be able to read that node and its child nodes, and may not be able to modify or delete them. In other words, changes within the USM can only be made by authorized nodes, and if a node in a scene published by the Scene Manager is read-only within the corresponding USM, modifications to that node and its child nodes may be impossible.

[0077] According to the present disclosure, details of changes made at a terminal can be transmitted to a Scene manager as an update. The Scene manager can manage the received update by distinguishing between changes common to all participants and changes individual to each participant.

[0078] USM can apply changes to a participant's personalized shared scene based on the participant's interaction with authorized work nodes, and transmit the applied changes to the Scene Manager.

[0079] USM must not allow user interaction on unauthorized work nodes (e.g., if there is no permission to modify the desk position, the desk will not move), and even if a change request for an unauthorized node is passed to the Scene manager due to an incorrect implementation or behavior of USM, the Scene manager may reject the request and return an error code.

[0080] USM may also receive instructions from a participant on whether the scope of application of changes resulting from the participant's interaction applies to all other participants, some participants, or is limited only to the terminal itself.

[0081] Changes made on one terminal may be displayed on the terminals of all participants in the conversation, or they may be displayed only on the terminals of some specific participants depending on the scope of disclosure of the changes.

[0082] For example, an example of a case where you want it to be displayed to all participants could be Participant 1 changing their avatar. Other participants, such as Participant 2 and 3, might see Participant 1's avatar change from A to B. Change history transmitted from Participant 1's USM can target a shared scene.

[0083] An example of a case where you want something to be displayed only to specific participants is that Participant 1 specifies that their avatar should be changed to be visible only to Participant 3. Other participants, such as Participant 2 and future additional participants, may see Participant 1's avatar as A, but it may be changed to B only to Participant 3. Change history transmitted from Participant 1's USM may target Participant 3's individual changes.

[0084] If the USM does not apply the intended scope of a change resulting from an interaction to all participants, it may specify the identifiers of the target participants to whom the change applies within the scene update history sent to the Scene manager.

[0085] The Scene manager can determine the intended scope of participant coverage for changes received from USMs and distinguish between changes common to all participants and changes individual to each participant.

[0086] The Scene manager can reflect the change details received from the terminal USM within the shared scene if the change details are acceptable and apply to all participants.

[0087] If the change details received from the terminal USM are acceptable and target some participants, the Scene manager can reflect the said change details in individual changes for each participant.

[0088] In other words, the Scene Manager reflects common changes within the shared scene and can reflect changes that may vary by participant within the individual changes for each target participant. If a node provided within the shared scene for all participants needs to be applied differently to specific participants—that is, if it needs to be listed in the individual changes of some participants—the Scene Manager can modify the node or its attribute value from the shared scene within the relevant individual changes.

[0089] For example, if avatar A (e.g., anonymous face) is indicated as Participant 1's avatar in a shared scene, and Participant 1 wants to use avatar B (e.g., their own face) only for Participant 3, Participant 1's avatar is indicated as A in the shared scene, and a command to replace Participant 1's avatar identifier from A to B may be included in the individual changes for Participant 3. Participants 1, 2, and 3 receive the shared scene and their respective individual changes, and can configure their respective personalized shared scenes by applying the individual changes to the shared scene. In the personalized shared scenes of Participants 1 and 2, Participant 1's avatar is listed as avatar A, and in the personalized shared scene of Participant 3, Participant 1's avatar is listed and displayed as avatar B.

[0090] Depending on the changes or the target, the type of scene that needs to be changed can be a shared scene or individual changes; therefore, the timing of when the Scene Manager updates a shared scene and when it updates individual changes may be unrelated. In other words, updating a shared scene may not require updating individual changes, and vice versa.

[0091] When version identifiers managed by the Scene manager are assigned to shared scenes and individual changes respectively, a new version identifier can be issued to the shared scene whenever the shared scene is updated, and to individual changes whenever individual changes are updated. In particular, since individual changes are generated for each participant, participants may have different individual changes version identifiers depending on their devices.

[0092] If a version identifier managed by the Scene manager is assigned to a personalized shared scene, a new version identifier may be issued whenever either the shared scene or individual changes are updated.

[0093] The terminal's USM can display the results in the USM after the update transmitted to the Scene manager is accepted. The Scene manager can issue a new version identifier for the accepted update. The USM can distinguish the version of the personalized shared scene held by the terminal's USM using the received version identifier.

[0094] For example, in the USM of Terminal 1 that has received a Personalized shared scene of Version 10, the value of the desk location attribute within the scene is adjusted for all participants as a result of the participant's interaction, and an update changing the attribute value is sent to the Scene manager. Afterward, the USM can receive 11 as a version identifier from the Scene manager along with the acceptance of the change request. The USM of Terminal 1 can reflect the proposed update in the Personalized Shared Scene of Version 10 that had it and manage it as Version 11. Meanwhile, other USMs can communicate with the Scene manager to receive the scene of Version 11 as Version 11 becomes available.

[0095] Update Procedure

[0096] FIG. 3 is a diagram illustrating operations performed between a USM and a scene manager in an avatar call system according to various embodiments of the present disclosure. Specifically, FIG. 3 illustrates a process in which a change in a terminal USM is transmitted to a scene manager, and the accepted change is transmitted to the USMs of other participants.

[0097] As a prerequisite prior to the execution of the following steps, the Scene manager and USMs establish an avatar call session using a shared scene, and the terminal's USM receives the final version of the shared scene, individual changes, or personalized shared scene from the Scene manager, and may attempt to apply changes resulting from user interaction to nodes to which the USM has been granted modification authority. The result of the user interaction may be the creation or deletion of nodes, or a change in the attribute values ​​of nodes. The result of the user interaction may be described by the USM as changes to the previously received final version of the scene.

[0098] In Step 1, the Scene manager and USMs can establish an avatar call session using a shared scene. USM1 can request a list of avatars from the Scene manager. In response to USM1's request, the Scene manager can transmit a Scene containing a list of avatars or a list of avatars. In Step 2, USM1 can select an avatar from the list of avatars to use and notify the Scene manager of this. The Scene manager can respond to USM1's selection and list USM1's selection as the avatar selected for USM1 within the Scene.

[0099] In step 3, USM1 can transmit its current version identifier and difference, etc., to the Scene manager.

[0100] The version identifier identifies the version of the Scene that serves as the basis for difference generation, and is one of those previously received from the Scene manager.

[0101] If necessary, USM1 can deliver the entire new version to the Scene manager, rather than just the difference from the previous version. For example, if the content of the difference is extensive, the size of the difference may be larger than the size of the entire new version. In the following description, the entire new version, as well as the difference from the previous version, will be referred to as a 'difference'.

[0102] Changes applied by USM1 to the nodes in the differential must be within the authority granted to the USM. Additionally, a list of all or specific participants may be listed as the scope of the differential.

[0103] In Step 4, the Scene manager checks whether the received difference is a change within the authority granted to the corresponding USM1, and in Step 4a, if it is an attempt to change outside the authority, it may reject all or part of the difference. The rejection may be simply an Error, a detailed explanation of the reason for rejection, or information about some of the allowed differences.

[0104] In Step 5, the Scene manager checks the coverage for the received difference and, if there is no distinction between participants or if the change applies to all participants, the difference can be applied under the shared scene. If there is a distinction between participants, the difference can be applied to the individual changes managed by the scene manager for those participants. In Step 5a, if other errors occur, such as a participant not participating in the conversation being in coverage, the Scene manager may reject all or part of the requested difference. The rejection may be simply an Error or a detailed explanation of the reason for rejection.

[0105] Step 6. The Scene manager may apply the accepted difference to the shared scene and / or individual changes and issue a new version identifier. In Step 6a, the Scene manager may return the new version identifier to USM1 as a response, along with whether the acceptance was successful.

[0106] In step 7, when USM1 receives a version identifier for a new scene along with a successful result in response to a request for differential reflection from the Scene manager, USM1 may consider the content of its scene to be the same as the Scene manager's scene and replace the scene version with the newly received version identifier.

[0107] In step 8, the Scene manager may issue a new version identifier even if only a portion of the difference is accepted. In step 8a, the Scene manager may return to USM1 the contents of the reflected difference and the new version identifier, along with a code indicating that the difference has been accepted.

[0108] In step 9, if USM1 receives a response that only a portion is accepted, it may reflect the accepted difference received from the Scene manager instead of the difference it previously requested to reflect, and assign the version identifier received from the Scene manager to the result of the reflection.

[0109] In step 10, the Scene manager may notify other USMs of the new version and instruct the USMs to perform updates. The USMs may communicate with the Scene manager to perform updates. In one example, the Scene manager may update the Scene at the request of terminal USMs and transmit all or part of the changes to the USMs to synchronize the scene content among the participants.

[0110] If the Scene Manager manages shared scenes and individual changes separately and assigns separate version identifiers, the update timing and frequency of shared scenes may differ from those of individual changes. The Scene Manager can update shared scenes or individual changes and publish them as new versions, notifying participants' terminals of each separately. The USM of a terminal checks the version information notified by the Scene Manager and can receive only the updated version separately among cases where the version identifiers of shared scenes and individual changes are transmitted separately.

[0111] The Scene manager can update a shared scene, individual changes, or a personalized shared scene that combines them, and notify the participants' terminals by issuing a new version identifier based on the personalized shared scene.

[0112] In step 11, the Scene manager can transmit the result to be reflected from the USM1 of the terminal to the USM2 of the terminal.

[0113] FIG. 4 is a diagram illustrating operations performed between a USM, a scene manager, and an avatar storage in an avatar call system according to various embodiments of the present disclosure.

[0114] According to one embodiment of the present disclosure, in some cases, the terminal of Participant 1 may pre-create a base avatar, which is a model file of an avatar, and register it on a network so that it can be used in an avatar call. In FIG. 4, an example is illustrated in which the USM creates and uploads a base avatar, and then includes it in a Scene after concluding an avatar call.

[0115] In the first step, a Base avatar can be created.

[0116] In step 1a, the terminal or USM can generate a base avatar from various information obtained from the user.

[0117] In step 1b, the terminal or USM may register the created base avatar in Avatar Storage for future use prior to avatar call.

[0118] In the second step, Avatar Call Participant 1 (User #1) and Participant 2 (User #2) can establish a shared space for Avatar Call.

[0119] In Step 3, Participant 1's USM1 communicates with the Scene manager to provide an avatar to be used in the session. The detailed method may be as follows.

[0120] In Step 3a, in a method mediated by Scene exchange, the Scene manager may deliver a scene for a participant in an avatar call. To create a scene for a participant, the Scene manager may query Avatar storage for a list of avatars that Participant 1 can select, and create a scene listed as one or more avatars that can be selected from the received list of avatars. The Scene manager may list one avatar from the list of avatars as the default selected avatar under selectedDefault in the created scene. The default selected avatar may be the one most recently used, the one most recently used with the counterpart User #2, the one most frequently used, or the one most recently registered, and this may depend on the choice of the avatar call provider or the user.

[0121] The Scene manager can pass the created scene to USM 1, and the pass may be a response to request_scene(), which is a request from USM, or push_updated_scene(), which is a push from the Scene manager.

[0122] In step 3b, Participant 1 can select one of the avatars listed as available for selection within the scene.

[0123] In step 3c, USM 1 can request an update by writing the identifier of the avatar selected by the participant at the avatar identifier location within the scene and transmitting the changed difference to the Scene manager.

[0124] In step 3d, in a method mediated by message exchange, Participant 1's USM 1 can request a list of available avatars as a get_avatar_list() message.

[0125] In step 3e, the Scene manager may query Avatar storage for a list of avatars that Participant 1 can select, and respond to USM 1 with a list from the avatar list that is listed as being selectable by one or more avatars.

[0126] In step 3f, USM 1 may request avatar metadata as additional information for avatar selection using get_base_avatar_metadata(). Avatar metadata may be any information that allows the user to refer to and make a decision when selecting an avatar. For example, it may be thumbnails, thumbnail videos, videos of promised default actions, last usage time, usage time over the last few days, total usage time, identifiers of the target participants who last used it, the size of the avatar model, attribute values ​​by quality metric, etc.

[0127] In the 3g stage, the Scene manager can obtain and pass metadata from within the avatar model or from Avatar storage. If obtained from Avatar storage, the metadata can be obtained along with the base avatar list in the 3d stage.

[0128] In step 3h, Participant 1 can select one of the avatars listed as available for selection.

[0129] In step 3i, USM 1 can indicate the identifier of the selected avatar to the Scene manager as set_selected_base_avatar().

[0130] In step 4, the Scene manager can update the scene based on avatar selections received from USM 1. According to one embodiment of the present disclosure, the Scene manager updates the Scene in response to requests from terminal USMs and can transmit all or part of the changes to the USMs to synchronize the scene content among the participants.

[0131] If the Scene Manager manages shared scenes and individual changes separately and assigns separate version identifiers, the update timing and frequency of shared scenes may differ from those of individual changes. The Scene Manager can update shared scenes or individual changes and publish them as new versions, notifying participants' terminals of each separately. The USM of a terminal checks the version information notified by the Scene Manager and can receive only the updated version separately among cases where the version identifiers of shared scenes and individual changes are transmitted separately.

[0132] The Scene Manager can update a shared scene, individual changes, or a personalized shared scene that combines them, and notify the participants' terminals by issuing a new version identifier based on the personalized shared scene. The USM of the terminal can check the version information notified by the Scene Manager and update the personalized shared scene.

[0133] The Scene manager can notify all participants of changes or differentiate by participant to notify only those participants who have changes.

[0134] In Step 5, the Scene manager can distribute the updated scene to the participants.

[0135] In step 6, USM 2 can receive from Avatar storage the base avatar of Participant 1, which is listed as having been selected by Participant 1 in the received scene.

[0136] In step 7, an anumation stream generated according to the movements and facial expressions of participants 1 and 2 is exchanged between USM 1 and USM 2.

[0137] In step 8, USM 2 can move and display the avatar along with the scene according to Participant 1's animation.

[0138] FIG. 5 is a diagram illustrating operations performed between a USM and a scene manager for updating a scene in an avatar call system according to various embodiments of the present disclosure. Specifically, FIG. 5 illustrates a procedure for updating a scene. The update procedure may include the following methods.

[0139] For the first method, the steps may be as follows.

[0140] In the first step, the Scene manager can notify the USM of the participants' terminals that there is a change by sending a message containing components such as those in [Table 1] below.

[0141]

[0142] In the second step, the USM of the terminal determines whether the version notified by the Scene manager is the same as the version identifier previously received and managed, and if a difference occurs, it may request an update.

[0143] In the third step, the terminal's USM can request an update by sending a message containing components such as those in [Table 2] to the Scene manager, and may specify the final version of each scene type that the terminal had in the request.

[0144]

[0145] In steps 4 and 5, the Scene manager may deliver an updated scene to the USM using a message containing components such as those in [Table 3] below as a response to an update request received from the USM. If the USM requests an independent scene (content_type=type_scene) or if the version held by the USM is not specified, the Scene manager may transmit the latest version of the independent scene. If the USM requests a version difference (type_patch), the Scene manager may transmit a patch, which is a change history that can generate the latest version held by the Scene manager from the version specified as held by the terminal. If the size of the patch is larger than the full version, the Scene manager may transmit the full version.

[0146]

[0147] FIG. 6 is a diagram illustrating operations performed between a USM and a scene manager that update a scene in an avatar call system according to various embodiments of the present disclosure.

[0148] Specifically, FIG. 6 describes a second method for updating a scene in addition to the procedure for updating a scene described in FIG. 5. For the second method, the steps may be as follows.

[0149] In Step 1, the Scene manager may manage versions of the scene sent to each USM by each participant. As the scene is updated, the Scene manager identifies the difference between the version held by each USM and the final version managed by the Scene manager, and decides to publish the update if necessary. The scene and version identifiers of the final version generated by the Scene manager may differ for each USM.

[0150] In the second step, the Scene manager can deliver the necessary update information to each USM. The update information can be delivered using a message containing components such as those in [Table 1b] below.

[0151]

[0152] In the third step, when an update is generated and transmitted by the Scene manager, USMs receive the update without requesting it, and can configure a personalized shared scene by applying the received update to the previous version.

[0153] FIG. 7 is a diagram illustrating operations performed between a USM and a scene manager for updating a scene in an avatar call system according to various embodiments of the present disclosure. Specifically, FIG. 7 describes a third method for updating a scene in addition to the procedure for updating a scene described in FIG. 5. In the case of the third method, the steps may be as follows.

[0154] In the first step, the USM of the terminal can periodically send a message containing components such as those in [Table 2] described above to report the version of the Scene it has to the Scene manager.

[0155] In the second step, the Scene manager can determine whether the version of the Scene held by the USM of the terminal is the final version or if an update is needed, based on the report received from the terminal. For example, if the versions are different, it can be determined that an update is needed.

[0156] In step 3, the Scene manager can return an identical_version response if the version requested by the terminal is the same as the latest version on the server.

[0157] In step 4, if the response from the Scene manager is identical_version, the USM can repeat from step 1 after a certain period of time or after the expiration time.

[0158] In step 5, the Scene manager can deliver patch information as an update to generate the latest version from the version reported by the terminal when there is a difference between the version requested by the terminal and the latest version of the server.

[0159] In step 6, if the response from the Scene manager is update_exists, the USM can update the USM's scene using the update sent with the message.

[0160] Version Identifier Management in Scene Manager

[0161] FIG. 8 illustrates an example in which a terminal USM manages update details in an avatar call system according to various embodiments of the present disclosure.

[0162] According to one embodiment of the present disclosure, a Scene manager can separately manage a shared scene for all participants and individual changes for individual participants, and can also manage version information for the shared scene and individual changes respectively.

[0163] Alternatively, the Scene manager may configure a personalized shared scene for each participant as a result of applying individual changes for each participant to a shared scene common to all participants. When either the shared scene or the individual changes configuring the personalized shared scene for each participant is updated, the Scene manager may publish a new version of the personalized shared scene for each participant. The version of the personalized shared scene may be information that can track version increments, or it may be a version identifier that combines the version of the shared scene and the version of the individual changes for each participant.

[0164] In one example, there may be a version system using numbers. In this case, the shared scene can be expressed as an increase in the first few decimal places, and individual changes as an increase in the second few decimal places. In the example, v2.1 could indicate that there are changes to the individual changes compared to the previous version, v2.0, and v3.0 could indicate changes to the shared scene compared to v2.0.

[0165] In one example, there may be a participant identification system using the alphabet. In this case, changes specific to each participant may be managed only by the Scene manager and not disclosed to other participants. Alternatively, as in v3.2a, participants may be distinguished and provided using letters such as a, b, c, etc. As mentioned above, the alphabet is just one example, and as another example, identifiers for conversation participants may be used.

[0166] In one example, there may be a versioning system that uses updated times. In this case, the shared scene and individual changes can each be represented as a combination of two pieces of time information.

[0167] The terminal's USM can transmit changes to shared scenes or individual changes made by the user to the Scene Manager, i.e., request an update. If the Scene Manager accepts the request from the USM, it can apply the changes to the managed shared scenes or individual changes per UE and increment the version.

[0168] If a change transmitted from the terminal USM is determined to be an unacceptable change, the Scene manager may respond to the USM by specifying the address and reason for the rejected node, or only the nodes for which the update is permitted. The USM may not reflect the rejected update from the Scene manager even within the terminal, or may reflect it only in local changes. The USM may reflect only the updates permitted by the Scene manager in the personalized shared scene. This ensures that the content and version of the shared scene, individual changes, or personalized shared scene managed by the Scene manager remain identical to the content and version of the scene managed by the terminal USM.

[0169] Update management in terminal USM

[0170] FIG. 9 illustrates an example in which a terminal USM manages update details in an avatar call system according to various embodiments of the present disclosure.

[0171] When the USM of the terminal receives shared scenes and individual changes separately from the Scene manager, it can synchronize the version of the Scene manager with the version of the USM by managing the shared scenes and individual changes separately within the USM and requesting and receiving each new version separately from the Scene manager.

[0172] The Scene manager and the terminal's USM can distinguish whether the target of an update is a shared scene, individual changes, or a personalized shared scene by specifying the subtype in update notifications, requests, and responses.

[0173] The shared scene, individual changes, or personalized shared scene received by the terminal's USM may be complete information (type_scene) that can be used without a previous version, or an update command (type_patch) that can be applied to a previous version to obtain a new version, depending on the content_type. When the USM receives an update that is a type_patch, it can apply it as an update command to the previous version to generate a new version as a result. For example, when the previously held version is v1 and the content_type of the update is type_scene, the information received from the Scene manager may be a complete v2. As another example, when the previously held version is v1 and the content_type of the update is type_patch, the information received from the Scene manager may be a set of commands to create v2 using v1. The USM can generate v2 by applying update information (e.g., [Table 4-1] or [Table 4-2]) to the v1 information (e.g., [Table 4]).

[0174]

[0175] Shared scenes, individual changes, and personalized shared scenes transmitted from the Scene manager may all be type_scene or type_patch. The Scene manager and USM may use type_scene or type_patch as needed when requesting and transmitting updates. If the size of type_patch is larger than the size of type_scene, the Scene manager may transmit it as type_scene even if the terminal's USM requested it as type_patch.

[0176] If the scene received by the terminal's USM from the Scene manager consists of a shared scene and individual changes, the USM can apply the individual changes to the shared scene to generate a personalized shared scene as a result. The USM can use the generated or received personalized shared scene as is as a personalized shared scene, or, if there are local changes, use the result of applying them as a personalized shared scene.

[0177] Update Information

[0178] The Scene manager can provide the time the scene was published (publish_timestamp) and the time it expired (expiration_timestamp).

[0179] A Scene manager can specify a publish_timestamp for updates to be published. The publish_timestamp can be the time at which the update was generated or a future time. If the publish_timestamp of a received update is a future time, the USM of a terminal must wait until the publish_timestamp is reached before applying the update. Accordingly, the Scene manager can pre-distribute updates to the USMs of multiple terminals and publish them with the intention that they be applied simultaneously the moment the publish_timestamp is reached.

[0180] If a higher version update is received and has a different publish_timestamp, even though there is an unapplied update whose publish_timestamp has not yet arrived, the update with the previous publish_timestamp can be considered overwritten, i.e., canceled, and the new version assigned.

[0181] The Scene manager can specify an expiration_timestamp for published updates. The terminal's USM may not be able to immediately apply updates received from the Scene manager due to reasons such as performance degradation or processing delays; however, it must apply them before the expiration_timestamp at any time. If the application is delayed and the current time becomes after the expiration_timestamp, the USM must not apply the update. However, the update may be applied if the Scene manager confirms that the version of the update is the final version.

[0182] [Scene Attributes]

[0183] Selectable values ​​and selected default

[0184] Through the exchange of Scenes, the Scene manager provides one or more options that the terminal's USM can select and can receive a selected value from the participant. An option is a list of one or more interchangeable nodes for a node (and child nodes that have the said node as a parent) that constitutes the Scene.

[0185] Within the Scene provided by the Scene manager, a list of selectable items may be provided, and selectable values ​​may be provided for each item. Additionally, default selected values ​​for each item may be listed so that the Scene can operate without issues even before the initial selection by the terminal's USM, and if the value is changed by the USM, the Scene can operate using the changed value.

[0186] In one embodiment, the Scene received from the Scene manager may have an extras node as sub-information of one node, and a list of multiple selectable sub-attributes may be presented under the selectableValues ​​node below it, and selectedDefault may also be presented as a selected default value. In Table 4, the scene transmitted from the Scene manager is described as having selectable identifiers, background colors, and textures for the Base avatar, and an index of the selection to be used in the terminal USM for the initial scene display may be described.

[0187] Users can change the selected value, and can also specify different attribute values ​​for the same attribute for specific users.

[0188] [Table 4-1] below illustrates an example in which the difference generated by USM includes a change in which its baseAvatarIdentifierIndex is designated as 1st, i.e., "identifier2", and a change in which "userOverrides" is used to make "baseAvatarIdentifierIndex" 2 for "user B" and "user D".

[0189] The difference transmitted from USM to the Scene manager may be in a format that follows the syntax of the scene as shown in [Table 4-1], or it may be a JSON patch command that directs the scene and changes to the scene as shown in [Table 4-2] below.

[0190]

[0191]

[0192] The Scene manager can reflect the values ​​listed in the userOverrides item within each USM's individual changes and delete userOverrides to avoid disclosing that one USM or participant is applying different values ​​to another participant.

[0193] For example, in the individual changes of user B and user D, user A's avatar is listed as having a value of (userA node) / extras / selectedDefault / baseAvatarIdentifierIndex of 2, and the value of (userA node) / extras / selectedDefault / baseAvatarIdentifierIndex in the shared scene may be 1.

[0194] The Scene manager can add content to shared scenes or individual changes for each user and issue a new version identifier.

[0195] Permission

[0196] In the scenes provided by the Scene Manager, access and modification permissions can be listed as accessControls by node or attribute. As sub-information of the accessControl, a user identifier is listed, and user-specific read-write, read-only, etc., may be specified. This information serves as guide information for the terminal USM, and it may not be information that can be changed even if the terminal USM arbitrarily attempts to change read-only to read-write, etc. In other words, even if the USM arbitrarily changes the value of userA or userB, the Scene Manager may ignore such changes.

[0197] FIG. 10 is a diagram showing a plurality of nodes in an avatar call system according to various embodiments of the present disclosure.

[0198] Since Node 1 is marked as read-write for userA, Node 1 and its child nodes 2, 3, 4, 5, and 6 inherit the same permission. However, since Node 7 is marked as read-only, Node 7 and its child nodes 8 and 9 inherit the read-only permission.

[0199] Internally, the Scene manager can have a value of no-access as one of the accessControl options, in addition to read-write and read-only; however, if no-access is selected, the corresponding node may not be provided to the user. In other words, since the Scene manager does not transmit it, the content cannot be known. For example, in the tables below, if "userC": "no-access", the first node of nodes is not delivered to userC.

[0200]

[0201]

[0202] As another embodiment, access and modification permissions may be defined by following the policy representation method defined by the organization. As an example, as shown in [Table 7] below, "3gpp_accessControl" under extensions may be defined to group and indicate nodes that can be accessed by users granted the same permissions within the scene. In this example, / nodes / 0 and / nodes / 1 are nodes where user A and user B have the same permissions, and instead of specifying user permissions for each node, nodes can be enumerated by user permissions. Nodes 0 and 1 indicate that user A can read and write while user B is allowed to read only, and Node 2 indicates that user A can read and write while user C is allowed to read only.

[0203]

[0204] [Subprotocol]

[0205] According to one embodiment of the present disclosure, an avatar call system and a terminal may exchange and set up the following messages for the exchange and setup of an avatar call, a Scene, and a process for the avatar call.

[0206] Avatar-related messages

[0207] According to one embodiment of the present disclosure, a USM or terminal may set configurations related to an avatar by sending the following messages to a Scene manager or an avatar call service component. The USM may send a get_base_avatar_list message to obtain a list of avatars available for use in an avatar call. In response to this, a list of avatars available for use by the USM may be provided in the form of a list of identifiers. The USM may send a get_base_avatar_metadata message to obtain additional information regarding the list of identifiers, such as thumbnails, total usage time, and last access time. When sufficient information is received to select an avatar, one avatar is selected based on the user's judgment, and the user's selection may be transmitted to the Scene manager via a set_selected_base_avatar message. Additionally, to represent other participants in an avatar call, the USM may receive avatar identifiers selected by other participants using a get_participants_base_avatar_ids message and receive them using a get_Base_avatar_metadata message.

[0208]

[0209] Messages related to shared scene

[0210] According to one embodiment of the present disclosure, a USM or terminal and a Scene manager or avatar call service component may exchange messages as follows to perform processing related to updating and distributing a Scene.

[0211] The USM can create changes to the scene received from the Scene manager and send the created changes to the Scene manager using the update_scene message. In response, the Scene manager can reply with a newly issued version identifier along with the reason for success or rejection.

[0212] The USM can use the request_scene message to report the version identifier currently held by the USM to the Scene manager and request and receive independent scenes or version differences.

[0213] The USM can use the report_version message to report the version identifier currently held by the USM to the Scene manager.

[0214]

[0215]

[0216] The Scene Manager can send a notifyUpdateRequired message to all or specific USMs when a version higher than the version of the USMs it manages is created, or when the version information received from the USMs is lower than the final version. After being notified of the existence of a new version, the USMs must request and receive an update from the Scene Manager.

[0217]

[0218] FIG. 11 illustrates the structure of a terminal (1100) according to various embodiments of the present disclosure.

[0219] The configuration exemplified in FIG. 11 can be understood as a configuration of a terminal (1100). Terms such as '...part', '...unit' used below refer to a unit that processes at least one function or operation, and this can be implemented as hardware or software, or a combination of hardware and software.

[0220] Referring to FIG. 11, the terminal (1100) includes a communication unit (1110), a storage unit (1120), and a control unit (1130).

[0221] The communication unit (1110) performs functions for transmitting and receiving signals through a wireless channel. For example, the communication unit (1110) performs a conversion function between a baseband signal and a bit sequence according to the physical layer specifications of the system. For example, when transmitting data, the communication unit (1110) generates complex symbols by encoding and modulating the transmitted bit sequence. Also, when receiving data, the communication unit (1110) restores the received bit sequence by demodulating and decoding the baseband signal. Additionally, the communication unit (1110) upconverts the baseband signal into an RF band signal and transmits it through an antenna, and downconverts the RF band signal received through the antenna into a baseband signal. For example, the communication unit (1110) may include a transmission filter, a reception filter, an amplifier, a mixer, an oscillator, a DAC, an ADC, etc.

[0222] Additionally, the communication unit (1110) may include a plurality of transmission and reception paths. Furthermore, the communication unit (1110) may include an antenna unit. The communication unit (1110) may include at least one antenna array composed of a plurality of antenna elements. In terms of hardware, the communication unit (1110) may be composed of a digital circuit and an analog circuit (e.g., a radio frequency integrated circuit (RFIC)). Here, the digital circuit and the analog circuit may be implemented as a single package. Additionally, the communication unit (1110) may include a plurality of RF chains. The communication unit (1110) may perform beamforming. The communication unit (1110) may apply beamforming weights to a signal to impart directionality according to the settings of the control unit (1130) to the signal to be transmitted or received. According to one embodiment, the communication unit (1110) may include a radio frequency (RF) block (or RF unit). The RF block may include a first RF circuitry associated with an antenna and a second RF circuitry associated with baseband processing. The first RF circuitry may be referred to as RF-A (antenna). The second RF circuitry may be referred to as RF-B (baseband).

[0223] Additionally, the communication unit (1110) can transmit and receive signals. To this end, the communication unit (1110) may include at least one transceiver. The communication unit (1110) can receive downlink signals. The downlink signal may include a synchronization signal (SS), a reference signal (RS) (e.g., DM (demodulation)-RS, PTRS (phase tracking reference signal)), system information (e.g., MIB, SIB, RMSI (remaining system information), OSI (other system information)), a configuration message, control information, or downlink data. Additionally, the communication unit (1110) may transmit an uplink signal. The uplink signal may include a random access related signal (e.g., a random access preamble (RAP) (or Msg1 (message 1)), Msg3 (message 3)), a reference signal (e.g., SRS (sounding reference signal), DMRS, PTRS), or a power headroom report (PHR).

[0224] Additionally, the communication unit (1110) may include different communication modules to process signals of different frequency bands. Furthermore, the communication unit (1110) may include multiple communication modules to support multiple different wireless access technologies. For example, different wireless access technologies may include Bluetooth Low Energy (BLE), Wi-Fi (Wireless Fidelity), WiGig (WiFi Gigabyte), cellular networks (e.g., LTE (Long Term Evolution), NR (new radio), etc. Additionally, different frequency bands may include super high frequency (SHF) bands (e.g., 2.5 GHz, 5 GHz) and millimeter wave bands (e.g., 38 GHz, 60 GHz, etc.). Additionally, the communication unit (1110) may use the same type of wireless access technology on different frequency bands (e.g., unlicensed band for LAA (licensed Assisted Access), CBRS (citizens broadband radio service) (e.g., 3.5 GHz)).

[0225] The communication unit (1110) transmits and receives signals as described above. Accordingly, all or part of the communication unit (1110) may be referred to as a 'transmitter', a 'receiver', or a 'transmitter / receiver'. Furthermore, in the following description, transmission and reception performed via a wireless channel are used to mean that processing as described above is performed by the communication unit (1110).

[0226] The storage unit (1120) stores data such as basic programs, application programs, and setting information for the operation of the terminal (1100). The storage unit (1120) may be composed of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. Additionally, the storage unit (1120) provides the stored data upon the request of the control unit (1130).

[0227] The control unit (1130) controls the overall operations of the terminal (1100). For example, the control unit (1130) transmits and receives signals through the communication unit (1110). Additionally, the control unit (1130) writes and reads data to and from the storage unit (1120). Furthermore, the control unit (1130) can perform the functions of the protocol stack required by the communication standard. To this end, the control unit (1130) may include at least one processor. The control unit (1130) may include at least one processor or microprocessor, or may be part of a processor. Additionally, part of the communication unit (1110) and the control unit (1130) may be referred to as CP. The control unit (1130) may include various modules for performing communication. According to various embodiments, the control unit (1130) may control the terminal to perform operations according to various embodiments.

[0228] FIG. 12 illustrates the structure of a server according to one embodiment of the present disclosure.

[0229] Referring to FIG. 12, the server may include a communication unit (1210), a storage unit (1220), and a control unit (1230). In the present disclosure, the control unit (1230) may be defined as a circuit or an application-specific integrated circuit or at least one processor.

[0230] At this time, the server may correspond to at least one of a computing server, an application server, or a data network configuration server.

[0231] The communication unit (1210) can transmit and receive signals with other network entities. The communication unit (1210) can transmit and receive information with, for example, another server through a specific interface.

[0232] The storage unit (1220) can store at least one of the information transmitted and received through the communication unit (1210) and the information generated through the control unit (1230).

[0233] The control unit (1230) can control the overall operation of the server according to an embodiment of the present disclosure. For example, the control unit (1230) can control the signal flow between each block to perform operations according to the flowchart described above.

[0234] FIG. 13 illustrates the structure of a network entity according to an embodiment of the present disclosure.

[0235] A network entity according to one embodiment of the present disclosure may include a processor (1320) that controls the overall operation of the network entity, a transceiver (1300) including a transmitter and a receiver, and a memory (1310). Of course, it is not limited to the above examples, and the network entity may include more or fewer configurations than the configuration shown in FIG. 13.

[0236] According to one embodiment of the present disclosure, the transmitting and receiving unit (1300) may transmit and receive a signal with at least one of other network entities or terminals. The signal transmitted and received with at least one of other network entities or terminals may include control information and data.

[0237] According to one embodiment of the present disclosure, the processor (1320) can control a network entity to perform any one of the above-described embodiments. Meanwhile, the processor (1320), memory (1310), and transceiver (1300) do not necessarily have to be implemented as separate modules, and can be implemented as a single component in the form of a single chip. Also, the processor (1320) and the transceiver (1300) can be electrically connected. Additionally, the processor (1320) may be an Application Processor (AP), a Communication Processor (CP), a circuit, an application-specific circuit, or at least one processor.

[0238] According to one embodiment of the present disclosure, the memory (1310) may store data such as a basic program, an application program, and configuration information for the operation of a network entity. In particular, the memory (1310) provides the stored data upon request by the processor (1320). The memory (1310) may be composed of a storage medium or a combination of storage media such as ROM, RAM, a hard disk, a CD-ROM, and a DVD. Additionally, the memory (1310) may be a plurality of. Furthermore, the processor (1320) may perform the aforementioned embodiments based on a program for performing the aforementioned embodiments of the present disclosure stored in the memory (1310).

[0239] Meanwhile, the embodiments of the present disclosure disclosed in this specification and drawings are merely specific examples provided to facilitate the explanation of the technical content of the present disclosure and to aid in understanding the present disclosure, and are not intended to limit the scope of the present disclosure. That is, it is obvious to those skilled in the art that other variations based on the technical concept of the present disclosure are possible. Furthermore, each of the above embodiments may be combined and operated together as needed.

Claims

1. A method performed by a UE (user equipment) associated with a USM (user equipment scene manager) in a wireless communication system, A step of establishing a session for shared scene-based avatar calls with network entities related to the SM (scene manager); A step of receiving an avatar list related to the UE from an avatar storage entity via the network entity; A step of selecting an avatar from the avatar list for the above avatar call; A step of transmitting the identifier of the selected avatar to the network entity; and A method comprising the step of receiving information about a shared scene updated based on the selected avatar from the network entity.

2. In Paragraph 1, The step of receiving the above avatar list includes the step of receiving metadata related to each avatar included in the avatar list from the network entity, and A method comprising the step of selecting the avatar, the step of selecting the avatar based on the metadata.

3. In Paragraph 1, The above method is, A step of transmitting information about a scene change of the UE to the above network entity; and A method comprising the step of receiving information about the latest version of a shared scene updated based on information about the scene change from the network entity.

4. In Paragraph 3, The step of receiving information about the latest version of the shared scene updated based on the information about the scene change above is: A method comprising the step of receiving patch information for creating the latest updated version of the shared scene.

5. In Paragraph 1, The above method is, Step of creating a base avatar; and A method comprising the additional step of uploading the base avatar to the avatar storage entity before establishing a session for the avatar call.

6. A method performed by a network entity associated with an SM (scene manager) in a wireless communication system, A step of establishing a session for a shared scene-based avatar call with a UE (user equipment) associated with a USM (user equipment scene manager); A step of transmitting to the above UE an avatar list related to the UE, received from an avatar storage entity; A step of receiving from the above UE, an identifier of an avatar selected from the avatar list for the avatar call; A step of updating the shared scene based on the selected avatar; and A method comprising the step of transmitting information about the updated shared scene to the above UE.

7. In Paragraph 6, A method comprising the step of transmitting the above avatar list, wherein the step of transmitting metadata related to each avatar included in the above avatar list to the UE.

8. In Paragraph 6, The above method is, A step of receiving information about a scene change of the UE from the above UE; A step of updating the shared scene based on information regarding the scene change; and A method comprising the step of transmitting to the above UE information about the latest version of the shared scene updated based on information about the scene change.

9. In Paragraph 8, The step of transmitting information about the latest updated version of the shared scene based on information about the scene change above is: A method comprising the step of transmitting patch information for creating the latest updated version of the shared scene.

10. Regarding UE (user equipment) related to USM (user equipment scene manager) in wireless communication systems: At least one transceiver; At least one processor communicatively coupled to the above at least one transceiver; and It includes at least one memory that is communicationally coupled to the above at least one processor and stores instructions, and The above instructions are executed individually or in any combination by the above at least one processor, so that the UE: Establish a session for shared scene-based avatar calls with network entities related to the SM (scene manager), and Receive an avatar list related to the UE from the avatar storage entity via the network entity, and To make the above avatar call, select an avatar from the above avatar list, and Transmit the identifier of the selected avatar above to the network entity, and A UE that receives information about a shared scene updated based on the selected avatar from the above network entity.

11. In Paragraph 10, the above commands are: the UE From the above network entity, metadata related to each avatar included in the avatar list is received, and A UE that allows selecting the avatar based on the above metadata.

12. In Paragraph 10, the above commands are: the UE To the above network entity, transmit information regarding the scene change of the UE, and A UE that receives information about the latest version of the shared scene, updated based on information about the scene change, from the above network entity.

13. In Paragraph 12, the above commands are: the UE A UE that receives patch information for creating the latest updated version of the shared scene.

14. Regarding network entities related to SM (scene manager) in wireless communication systems: At least one processor; and It includes at least one memory that is communicationally coupled to the above at least one processor and stores instructions, and The above instructions are executed individually or in any combination by the above at least one processor, so that the network entity: Establish a session for shared scene-based avatar calls with UEs (user equipment) related to USM (user equipment scene manager), and Transmit to the above UE an avatar list related to the UE received from an avatar storage entity, and From the above UE, receive the identifier of the avatar selected from the avatar list for the avatar call, and Update the shared scene based on the selected avatar, and A network entity that transmits information about the updated shared scene to the above UE.

15. In paragraph 14, the above commands are that the network entity: A network entity that transmits metadata related to each avatar included in the avatar list to the above UE.

Images