Synchronized avatar identifier

Abstract

The present disclosure relates to synchronized avatar IDs. A method is disclosed that includes requesting an avatar identifier in a request for a base avatar repository; receiving the avatar identifier in response to the request; and uploading a representation of the avatar and an indication that the representation of the avatar is to be associated with the avatar identifier to the base avatar repository.

Description

Technical Field

[0001] This disclosure pertains to avatar IDs.

[0002] abbreviation 3GPP Third Generation Partnership Project 4G / 5G / 6G (Fourth Generation / Fifth Generation / Sixth Generation) 5GA 5G Premium Edition ADC application data channel AF Application Functions API (Application Programming Interface) AR Augmented Reality ARF incarnation representation formation BAR Basic Incarnation Repository CM Configuration Management CRUD operations: create, read, update, delete DA Digital Assets DC Data Channel DCAS Data Channel Application Server DCSF Data Channel Signaling Function GPSI General Public Subscription Identifier HTTP (Hypertext Transfer Protocol) HTTPS Secure HTTP ID identifier IMEI (International Mobile Equipment Identity) IMS IP Multimedia Subsystem IMSI (International Mobile Station Identifier) JSON JavaScript object representation Media on MDC data channel MF Media Functions MSISDN (Mobile Integrated Services Digital Network Number) NEF Network Open Functions NF Network Functions RESTful representation of state transition SBI Service-Based Interface SDN (Software-Defined Networking) SEAL Vertical Industry Business Enablement Architecture Layer SIM subscriber identity module TR Technical Report TS Technical Specifications UE User Equipment VAL Vertical Application Layer WebRTC (Web Real-Time Communication) Background Technology Section 8 of 3GPP TR 26.813 provides for integrating avatars into 3GPP services. The functional mapping of avatar functionality to the IMSDC architecture is also provided. This architecture is as follows... Figure 1 As shown.

[0003] In Clause 8.8 of 3GPP TR 23.700-77, the following consensus was reached regarding support for IMS avatar communications: - The Basic Avatar Repository (BAR) stores avatar representations and associated avatar IDs.

[0004] - The avatar ID list is downloaded to the UE via the DCSF through the boot data channel. The DCSF can verify whether the UE is allowed to use the avatar representation.

[0005] -MF interacts with BAR directly or via DC AS (i.e., using MDC2) to retrieve the avatar representation using the avatar ID.

[0006] According to Clause AC.11.3.2.2 of 3GPP TS 23.228, in order to establish communication with UE2 using UE1's avatar, UE1 performs avatar animation negotiation with DC AS and UE2. This negotiation includes using UE1's avatar ID and the animation data types supported by UE1 (e.g., text and / or facial expressions).

[0007] Section 7.5.2 of 3GPP TS 23.700-21 describes the architectural impact of incarnation integration as follows: This clause provides architectural enhancements to the SEAL CM architecture defined in 3GPP TS 23.434. The SEAL CM client is enhanced to provide client-side functionality for managing (i.e., creating, reading, updating, and deleting) application-specific avatar profiles for metaverse applications. Application-specific avatar profiles contain avatar-related attributes and configurations.

[0008] The SEAL CM server has been enhanced to provide server-side functionality for managing application-specific avatar profiles for metaverse applications. It allows service consumers to create, update, retrieve, and delete application-specific avatar profiles. Application-specific avatar profiles can be stored in the VAL user database.

[0009] The VAL client uses the SEAL CM client to manage application-specific avatar profiles for metaverse applications via the CM-C reference point. Similarly, the VAL server uses the SEAL CM server to manage application-specific avatar profiles for metaverse applications via the CM-S reference point. The CM-UU interface is enhanced to provide management of application-specific avatar profiles between the SEAL CM client and the SEAL CM server.

[0010] Users can have one or more application-specific avatar profiles. Application-specific avatar profiles can be shared by one or more users (for example, an avatar profile is created for a sales representative and is used by all salespeople). Summary of the Invention

[0011] The aim is to improve existing technology.

[0012] According to a first aspect, a user equipment is provided, comprising: one or more processors, and at least one memory, the at least one memory storing instructions that, when executed by the one or more processors, cause the user equipment to perform operations, the operations including: Request the avatar identifier in the request to the base avatar repository; In response to the request, receive the avatar identifier; and The representation of the avatar, along with the indication associated with the avatar identifier, is uploaded to the base avatar repository.

[0013] The request may include an inquiry to query one or more capabilities of the avatar used by the second terminal.

[0014] The operation may also include: Together with the avatar identifier, it receives responses to queries used to retrieve one or more capabilities.

[0015] The first terminal can be configured to communicate with the underlying avatar repository using application protocols.

[0016] The application protocol can be Hypertext Transfer Protocol, Secure Hypertext Transfer Protocol, or Web Real-Time Communication.

[0017] The first terminal can be configured to communicate with the underlying avatar repository via a data channel application server.

[0018] The first terminal is configured to communicate with the underlying avatar repository via a media function entity.

[0019] According to a second aspect, an apparatus is provided, comprising one or more processors and a memory, the memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: Receive a request from the terminal to provide an avatar identifier; Generate avatar identifier; In response to a received request, provide an avatar identifier; Receive from the terminal a representation of the avatar and an indication that the avatar's representation will be associated with the avatar identifier; and The representation of the avatar associated with the avatar identifier is stored in the base avatar repository, where The avatar identifier is unique to the device.

[0020] The device can be configured to communicate with the terminal using an application protocol.

[0021] The application protocol can be Hypertext Transfer Protocol, Secure Hypertext Transfer Protocol, or Web Real-Time Communication.

[0022] The device can be configured to communicate with the terminal via a data channel application server.

[0023] The device can be configured to communicate with the terminal via a media function entity.

[0024] According to a third aspect, a method is provided, comprising operations performed by the means according to the first aspect.

[0025] According to the fourth aspect, a method is provided, comprising operations performed by the means according to the second aspect.

[0026] Each of the methods in the third and fourth aspects can be a method of avatar registration.

[0027] According to a fifth aspect, a computer program product is provided, comprising a set of instructions that, when executed on a device, are configured to cause the device to perform the method according to either the third or fourth aspect. The computer program product may be embodied in a computer-readable medium or directly loadable into a computer.

[0028] According to some example embodiments, at least one of the following advantages can be achieved: UE and BAR are synchronized in terms of avatar ID; Suitable for both user-centric and network-centric avatar ID generation. Attached Figure Description

[0029] Further details, features, objects, and advantages will become apparent from the following detailed description of preferred exemplary embodiments, taken in conjunction with the accompanying drawings, wherein: Figure 1 The IMS DC architecture for avatar functionality is shown (as per 3GPP TR 26.813); Figure 2 Different options for avatar generation are shown (caused by 3GPP TR 26.813); Figure 3 It shows the corresponding Figure 1 A simplified architecture; Figure 4 A message sequence diagram according to some example embodiments is shown; Figure 5 Flowcharts according to some example embodiments are shown; Figure 6A message sequence diagram according to some example embodiments is shown; Figure 7 Flowcharts according to some example embodiments are shown; Figure 8 Flowcharts according to some example embodiments are shown; Figure 9 An apparatus according to an example embodiment is shown; Figure 10 A method according to an example embodiment is shown; Figure 11 An apparatus according to an example embodiment is shown; Figure 12 A method according to an example embodiment is shown; Figure 13 An apparatus according to an example embodiment is shown; Figure 14 A method according to an example embodiment is shown; Figure 15 An apparatus according to an example embodiment is shown; Figure 16 A method according to an example embodiment is shown; and Figure 17 An apparatus according to an example embodiment is shown. Detailed Implementation

[0030] In the following detailed description with reference to the accompanying drawings, certain exemplary embodiments are described in detail, wherein features of the exemplary embodiments may be freely combined with each other unless otherwise described. However, it should be clearly understood that the description of certain exemplary embodiments is given by way of example only and is not intended to be construed as limiting this disclosure to the details disclosed.

[0031] Furthermore, it should be understood that the apparatus is configured to perform the corresponding method, even though in some cases only the apparatus or only the method is described.

[0032] Clause 7.5.3 of 3GPP TS 23.700-21 describes the following process: 7.5.3.1 Creating an application-specific avatar profile The configuration management server exposes an API to consumers for creating avatar profiles. Application-specific avatar profiles can be created via the configuration management client based on user requests or requests from the VAL server.

[0033] Application-specific avatar profiles can be associated with a single user or multiple users. For application-specific avatar profiles that can be used by multiple users, multiple users can use the avatar simultaneously, or, depending on application requirements, only one user can use the avatar at a time. The configuration management server stores avatars and their associated attributes and configurations.

[0034] Editor's Note: The term "user identity" in this document must be clearly defined as "user profile" or "user identifier." The term "avatar ID" in this document must be distinguished from "avatar profile ID."

[0035] A digital avatar is a type of digital asset. According to 3GPP TS 23.438, a digital asset identifier is used to uniquely identify a digital asset across different mobile metaverse services. The digital asset identifier (digital asset ID) is assigned by the SEAL DA server. This identity is globally unique. Avatar storage is part of the SEAL DA server in the application layer.

[0036] The DA server authenticates and authorizes requests to create digital asset profiles. If authorized, the DA server creates the digital asset profile, assigns a globally unique digital asset identifier, and stores information about the digital asset profile in a local repository.

[0037] Table 1 shows the parameters of a digital asset profile:

[0038] Table 1: Parameters for digital asset profiles (from 3GPP TS23.438, Table 8.2.3.1-2) According to 3GPP TR 26.813 Section 8, an incarnation is represented by being stored in three different entities, such as Figure 1 As shown: in BAR, MF, and UE.

[0039] In addition, such as Figure 2 As shown (Figure 21 from 3GPP TR 26.813), there are three ways (options) to generate an avatar and store it in the BAR. First, in response to a UE's request, the avatar representation can be generated by the MF or by a trusted avatar generator, sent to the BAR, and stored in the BAR. Second, as a third option, the UE can generate an avatar representation and send it to the BAR. However, in the BAR, the avatar representation should be associated with an avatar ID. Figure 21 of 3GPP TR 26.813 does not mention the avatar ID.

[0040] Some example implementations synchronize the storage of avatars and their avatar IDs between the UE and the BAR. These can provide a unified architecture that maps avatar functionality to the IMS DC architecture, meeting the requirements of 3GPP SA2 and SA4. These requirements are as follows: SA4 agreed to initiate Rel-19 work item regarding relevant specification work, with objectives including: Based on the IMS architecture extension developed by SA2, the TS 26.264 specification is extended to add support for avatars as part of IMS-based augmented reality (AR) calls. 1. Choose appropriate interoperable formats for the base avatar and animation stream. 2. Collaborate with SA2 and SA3 on security aspects related to basic avatar management and access to define an informational interface for managing user avatars on the Basic Avatar Repository (BAR). 3. Specify the animation and rendering of the avatar within the network.

[0041] The API requirements for SA4 are described in 3GPP TR 26.813: To improve interoperability, BAR can provide an optional RESTful API in the IMS system for avatar management.

[0042] BAR supports the Avatar Representation Format (ARF) container format and implements secure access control through token-based authorization.

[0043] SA2 requirements are as follows (3GPP TR 23.700-77): Whether a reference point is needed between the UE and the BAR, and how that reference point should be used, will further align with the conclusions of SA WG4.

[0044] Specifically, some example embodiments may provide a method for a UE to store its avatar and directly access the BAR, while some example embodiments may provide a process for a UE to access and store its avatar using a 5G network.

[0045] Specifically, one or more of the following problems can be solved through some example embodiments: -Avatar ID List Generation and Processing - The UE registers its avatar with the BAR via the IMS system (How can the UE access the avatar ID before registration?) -MF's role in the avatar processing from UE to BAR, including avatar generation / update / synchronization with the server within the network. Some example embodiments are based on, for example Figure 3 The architecture shown. Figure 3 The architecture is basically based on Figure 1 The architecture is simplified, omitting some network functions. The interface (reference point) names are based on current standards, not restrictive ones. MDCx is a provisional name and may be replaced in subsequent standardization work.

[0046] Specifically, the BAR connects to the DCAS via the MDCx interface and to the MF via the MDC2 interface. The MDC2 interface can implement media-related functions based on the interaction between the MF and the BAR. The DCAS and MF communicate via the MDC2 interface. The DCSF controls the DCAS and MF via the MDC3 and MDC1 interfaces respectively. The UE connects to the MF via the Mb interface. Furthermore, Figure 3 The optional direct interface Mbar between the UE and BAR is shown. Figure 3 (The dashed line in the text). The Mbar interface enables application-layer interaction. Optionally ( Figure 3 (The dotted line in the diagram) AF (such as digital asset servers) can connect to BAR via NEF and DCAS (N33 interface).

[0047] According to some example embodiments, the network function can operate basically as follows: BAR actions may include one or more of the following: - The "Avatar ID List" is stored and managed by the BAR and downloaded to the UE via MF.

[0048] - The "avatar representation" is stored in the BAR and can be accessed by the UE (as well as DCAS and MF) based on controls from the DCSF.

[0049] -BAR can be separate from DCAS or co-located with DCAS (within DCAS). In the latter case, MDCx is MDC2. The existing IMS DC architecture will apply.

[0050] -BAR can be accessed by third-party application providers.

[0051] BAR can be accessed by third-party secure avatars via NEF.

[0052] - Optionally, the BAR can be located in a digital asset server and can be accessed by the SEAL DA client and the VAL server.

[0053] DCSF behavior may include one or more of the following: - The DCSF interacts with the BAR via the interface MDCx (control plane) to establish a media plane path between the BAR and the MF, and provides information to the BAR to allow the UE / MF to send an avatar representation to the UE / MF when the established DC request is made.

[0054] MF behavior may include one or more of the following: - Avatar-related media features based on interaction with BAR, UE, and DCAS, including avatar generation, avatar animation, and scene management.

[0055] - It can be specified that there is no direct interaction between MF and BAR without DCSF control for remote IMS and UE access.

[0056] UE behavior may include one or more of the following: - Request a list of avatar IDs from the BAR or SEAL digital asset server - Based on control from DCSF, by providing the avatar ID listed in the received avatar ID list, request the selected avatar representation stored by BAR.

[0057] - Generate a new avatar ID and register it with BAR - Generate a new avatar representation associated with the avatar ID and register it with BAR. - Generate a new avatar representation associated with the avatar ID with the support of MF and DCAS, and register it with BAR. - Compare the avatar representation downloaded from BAR with the local avatar representation and identify fraud.

[0058] NEF behaviors may include one or more of the following: - Based on the list of avatar IDs, NEF services / APIs for BAR access are made available to authorized users. GPSIs such as MSISDN can be used as external identifiers.

[0059] - In the presence of an untrusted DC application server, the trusted BAR open service parameters can be added as CRUD operations via NEF.

[0060] -NEF consumers can be digital asset servers or any untrusted AF.

[0061] Avatar IDs can be created and stored by the BAR for processing. Typically, avatar IDs are globally unique. Once avatar resources (avatar representations) are generated, the generated avatar IDs are shared by the BAR with the UE (and the core network).

[0062] As an alternative, according to some example embodiments, avatar ID creation can be initiated by the UE. Where the avatar ID should be globally unique, the UE can generate the avatar ID using a globally unique identifier it knows (such as the SIM card number, a number stored on the SIM card (e.g., IMSI, MSISDN), or the UE's device serial number (e.g., IMEI)). The UE sends the generated avatar ID to the BAR, which is the central register for avatar IDs. Upon receiving the avatar ID generated by the UE, the BAR can check the received avatar ID, register it in its local repository (avatar repository), and send an acknowledgment back to the UE (for the confirmed avatar ID). That is, the BAR can check whether the received avatar ID is a duplicate of another avatar ID already stored (registered) in the BAR, and / or can check whether the received avatar ID meets the format requirements for avatar IDs (if any). If the BAR updates the avatar ID or its related details, the BAR will notify the UE of the update to keep the UE synchronized with the BAR on the avatar ID.

[0063] Figure 4 A message sequence diagram is shown according to some example embodiments. Figure 4 The message sequence diagram illustrates the establishment of a session between UE1 and UE2, which uses an avatar of UE1. UE1 generates an avatar ID and provides the avatar representation to the BAR (User-Centric Process). Figure 4 The actions in the middle are as follows: 1. Establishment of IMS sessions (e.g., audio and video) between UE1 and UE2; 2. Guidance and ADC establishment between UE1 and DCAS; 3. Guidance and ADC establishment between UE2 and DCAS; 4a. Avatar ID generation performed by UE1 (e.g., the avatar ID can be generated using a unique identity available to UE1, such as an identity associated with a SIM card or a device serial number). The mechanism by which UE1 generates the avatar ID can be pre-configured and depends on the specific implementation.

[0064] 5a. UE1 sends an avatar ID registration request (including the generated avatar ID) to the network (i.e., via MF to DCAS). For example, the avatar ID registration request may be included in a capability negotiation request, which includes UE1's capabilities regarding avatar communication. Alternatively, the avatar ID registration request may be transmitted to DCAS via a dedicated message.

[0065] 6a. If the avatar ID registration request is included in the capability negotiation request, the DC AS splits the capability negotiation request and sends the avatar capability request to the MF, and the MF sends back an avatar capability response including its avatar capability information; 7a. The DC AS sends an avatar ID registration request to the BAR. The BAR checks the received avatar ID and sends the confirmation result back to the DC AS. The BAR may perform one or more of the following checks: -Whether the avatar ID sent by UE1 has already been registered at BAR (i.e., it must not be duplicated), BAR generates a new ID and sends it back to DC AS; -If there is a formatting or mismatch issue, BAR generates a new ID and sends it back to DC AS.

[0066] If all performed checks are positive (no duplicates, no formatting issues), the BAR can send an acknowledgment of the avatar ID generated by UE1. If at least one of the performed checks is negative, the BAR can issue an error message. In some example embodiments, the BAR can additionally generate another avatar ID that satisfies the above checks. The BAR sends the error message and the other avatar ID generated by the BAR (if any) back to DCAS. In some example embodiments, the other avatar ID generated by the BAR can be considered the error message, thus eliminating the need for a dedicated error message.

[0067] 8a. DCAS makes the final decision on the negotiation result based on the received response (DCAS will combine the responses from BAR (related to avatar ID) and MF (related to capability) (if any) and forward the response to UE1 to complete the capability negotiation request / response process). 9a. DCAS sends a negotiation response back to UE1, which includes either an avatar ID confirmation or an error message (if any) including UE1's new avatar ID. 10a. If the avatar ID generated by UE1 is confirmed, or a new avatar ID is generated by BAR, DCAS also sends a negotiation response to UE2, including confirmation of the avatar ID or the new avatar ID of UE1.

[0068] 10. UE1 can upload an avatar representation to BAR and instruct that the avatar representation will be registered as associated with an avatar ID generated by UE1 or a new avatar ID generated by BAR, as appropriate. UE1 will also store this association in its local avatar register.

[0069] After an avatar representation is registered in association with an avatar ID (either an avatar ID generated by the UE or a new avatar ID generated by the BAR, depending on the case), the avatar representation can be modified, deleted, and invoked based on that avatar ID, just like any other avatar representation.

[0070] exist Figure 4 In some example embodiments, UE1 communicates with BAR for avatar ID registration via MF and DCAS. In some example embodiments, UE1 may communicate with BAR for avatar ID registration solely via MF, without involving DCAS. That is, MF takes on the role of DCAS. In some example embodiments, UE1 may communicate directly with BAR for avatar ID registration without the involvement of any other network functions.

[0071] Figure 5 It shows the relationship with Figure 4 The message sequence diagram corresponds to the flowchart of UE1 behavior (no ability to negotiate requests and related actions). These actions use... Figure 4 The same numerical code in the code, and can be referenced. Figure 4 The description is as follows. Furthermore, in some example embodiments, after establishing the ADC (Action 1 and Action 2), UE1 can check whether it can use an avatar ID already registered at the BAR for that avatar representation, based on the avatar ID list downloaded to the UE via the bootstrap data channel. In this case, Actions 4a, 5a, and 9a can be omitted.

[0072] Figure 6 A message sequence diagram is shown according to some example embodiments. Figure 6 The message sequence diagram illustrates the establishment of a session between UE1 and UE2, using an avatar of UE1. An avatar ID is generated at the BAR, and UE1 provides the avatar representation associated with the avatar ID to the BAR (a network-centric process). Figure 6 The actions in the middle are as follows: 1. Establishment of IMS sessions (e.g., audio and video) between UE1 and UE2; 2. Guidance and ADC establishment between UE1 and DCAS; 3. Guidance and ADC establishment between UE2 and DCAS; 4b. UE1 sends a request for the new avatar ID to the network (i.e., to DCAS via MF). For example, the request for the new avatar ID may be included in a capability negotiation request, which includes UE1's capabilities regarding avatar communication. Alternatively, the request for the new avatar ID may be sent to DCAS via a dedicated message.

[0073] 5b: If the avatar ID registration request is included in the capability negotiation request, then DCAS splits the capability negotiation request, and DCAS sends the avatar capability request to MF, and MF sends back the avatar capability response including its avatar capability information; 6b. DCAS sends a request to BAR for the new avatar ID; 7b. BAR generates a new avatar ID and sends a response (including the generated avatar ID) back to DCAS; 8b. DCAS makes the final decision on the negotiation result based on the received response (DCAS will combine the responses from BAR (related to avatar ID) and MF (related to capability) (if any) to forward the response to UE1, thereby completing the capability negotiation request / response process). 9b.DCAS will send a negotiation response, including the generated avatar ID, back to UE1. UE1 can then use the received avatar ID for subsequent procedures.

[0074] 10. UE1 can upload an avatar representation to BAR and instruct that the avatar representation will be registered in association with the avatar ID generated by BAR. UE1 also stores this association in its local avatar register.

[0075] Once an avatar is registered in association with an avatar ID generated by BAR, it can be modified, deleted, and invoked based on that avatar ID, just like any other avatar.

[0076] exist Figure 6 In some example embodiments, UE1 communicates with BAR regarding avatar ID registration via MF and DCAS. In some example embodiments, UE1 may transmit a request for a new avatar ID to BAR solely via MF, without involving DCAS. That is, MF assumes the role of DCAS. In some example embodiments, UE1 may directly transmit a request for a new avatar ID to BAR without the involvement of any other network functions.

[0077] Figure 7 It shows the relationship with Figure 6 The message sequence diagram corresponds to the flowchart of UE1 behavior (no ability to negotiate requests and related actions). These actions use... Figure 6 The same numerical code is used, and can be referenced. Figure 6 The description is as follows. Furthermore, in some example embodiments, after establishing the ADC (Action 1 and Action 2), UE1 can check whether it can use an avatar ID already registered at the BAR for that avatar representation, based on the avatar ID list downloaded to the UE via the bootstrap data channel. In this case, Actions 4b and 9b can be omitted.

[0078] As described above, the UE communicates with the BAR via the IMS data channel through the MF. CRUD operations and subscription / notification operations can be defined by one or more application protocols on the IMS data channel. This data channel can use either a JSON-based or delimiter-based mechanism to transmit avatar content associated with the avatar ID. Figure 8 A flowchart corresponding to this situation in a user-centric approach is shown.

[0079] Instead of the IMS data channel, the UE and BAR can communicate directly regarding avatar ID registration / creation without involving DCAS or MF, and HTTP or HTTPS can be used on this data channel. The BAR provides CRUD operations to manage avatar IDs, including creation, updating, retrieval, subscription, notification, and deletion. The UE interacts using these service operations for avatar ID registration / creation and subsequent avatar operations. Table 2 shows examples of CRUD operations in this scenario.

[0080]

[0081] Table 2: CRUD Operations for Avatar ID Management Figure 9 A terminal (such as a UE) according to an example embodiment is shown. Figure 10 A method according to an example embodiment is shown. Figure 9 The terminal shown can execute Figure 10 The method, but not limited to this method. Figure 10 The method can be derived from Figure 9 The terminal shown is used for execution, but is not limited to execution by that terminal.

[0082] The terminal includes a component 110 for generating, a component 120 for providing, a component 130 for receiving, and a component 140 for uploading. The components 110 for generating, 120 for providing, 130 for receiving, and 140 for uploading can be respectively a generating component, a providing component, a receiving component, and an uploading component. The components 110 for generating, 120 for providing, 130 for receiving, and 140 for uploading can be respectively a generator, a provider, a receiver, and an uploader. The components 110 for generating, 120 for providing, 130 for receiving, and 140 for uploading can be respectively a generating processor, a providing processor, a receiving processor, and an uploading processor.

[0083] The component 110 used for generation generates an avatar ID for the avatar (S110). The avatar ID is unique to the terminal. The avatar ID is based on the terminal's identifier or the user's identifier.

[0084] The component 120 provided will provide the avatar ID to the base avatar repository (S120).

[0085] The receiving component 130 receives a response to the provision of an avatar ID (S130). The response to the provision of an avatar ID indicates whether the representation of the avatar will be associated with the avatar ID.

[0086] The component 140 for uploading uploads the representation of the avatar and the information indicating the representation of the avatar associated with the avatar ID to the base avatar repository (S140).

[0087] Figure 11 An apparatus according to an example embodiment is shown. The apparatus may be an avatar repository (such as BAR) or a component thereof. Figure 12 A method according to an example embodiment is shown. Figure 11 The device shown can perform Figure 12 The method, but not limited to this method. Figure 12 The method can be derived from Figure 11 The device shown performs the action, but is not limited to the action performed by that device.

[0088] The device includes a first receiving component 210, a first storage component 220, a second receiving component 230, and a second storage component 240. The first receiving component 210, the first storage component 220, the second receiving component 230, and the second storage component 240 can be respectively a first component for receiving, a first component for storing, a second component for receiving, and a second component for storing. The first receiving component 210, the first storage component 220, the second receiving component 230, and the second storage component 240 can also be respectively a first receiver, a first memory, a second receiver, and a second memory. The first receiving component 210, the first storage component 220, the second receiving component 230, and the second storage component 240 can also be respectively a first receiving processor, a first storage processor, a second receiving processor, and a second storage processor.

[0089] The first receiving unit 210 receives a request from the terminal for registering an avatar ID (S210). The first storage unit 220 stores the avatar ID in the basic avatar repository (S220).

[0090] The second receiving unit 230 receives the representation of the avatar (S230). The second receiving unit 230 also receives an indication that the representation of the avatar will be associated with the avatar ID (S230). The representation of the avatar and the indication that the representation will be associated with the avatar ID can be received in one message or in multiple messages. The second storage unit 240 stores the representation of the avatar associated with the avatar ID stored in the basic avatar repository in S220.

[0091] S210 and S230 can be executed in parallel or in part, or sequentially. If S220 is not followed by S240, then S220 and S240 can also be executed in parallel or in part, or sequentially.

[0092] Figure 13 A terminal (such as a UE) according to an example embodiment is shown. Figure 14 A method according to an example embodiment is shown. Figure 13 The terminal can execute Figure 14 The method, but not limited to this method. Figure 14 The method can be derived from Figure 13 The terminal executes the command, but is not limited to the terminal that executes the command.

[0093] The terminal includes a requesting component 310, a receiving component 320, and an uploading component 330. The requesting component 310, the receiving component 320, and the uploading component 330 can be a requesting component, a receiving component, and an uploading component, respectively. The requesting component 310, the receiving component 320, and the uploading component 330 can be a requester, a receiver, and an uploader, respectively. The requesting component 310, the receiving component 320, and the uploading component 330 can be a request processor, a receiving processor, and an uploading processor, respectively.

[0094] The requesting component 310 requests the avatar ID in the request to the base avatar repository (S310). In response to the request in S310, the receiving component 320 receives the avatar ID (S320). The uploading component 330 uploads the representation of the avatar and the indication associated with the avatar ID to the base avatar repository (S330).

[0095] Figure 15 An apparatus according to an example embodiment is shown. The apparatus may be an avatar repository (such as BAR) or an element thereof. Figure 16 A method according to an example embodiment is shown. Figure 15 The device can perform Figure 16 The method, but not limited to this method. Figure 16 The method can be derived from Figure 15 The device performs the action, but is not limited to the device performing the action.

[0096] The device includes a first receiving component 410, a generating component 420, a providing component 430, a second receiving component 440, and a storage component 450. The first receiving component 410, generating component 420, providing component 430, second receiving component 440, and storage component 450 can be respectively a first component for receiving, a generating component, a providing component, a second component for receiving, and a storage component. The first receiving component 410, generating component 420, providing component 430, second receiving component 440, and storage component 450 can also be respectively a first receiver, a generator, a provider, a second receiver, and a memory. The first receiving component 410, generating component 420, providing component 430, second receiving component 440, and storage component 450 can also be respectively a first receiving processor, a generating processor, a providing processor, a second receiving processor, and a storage processor.

[0097] The first receiving unit 410 receives a request from the terminal to provide an avatar ID (S410). The generating unit 420 generates the avatar ID (S420). The avatar ID is unique to the device. S410 and S420 can be executed in any order. They can be executed in parallel, either wholly or partially. That is, in some example embodiments, the generating unit 420 can generate the avatar ID before the request in S410 to reduce response time. In some example embodiments, the generating unit 420 can also generate the avatar ID based on the request in S410 to avoid unnecessary generation of the avatar ID. The providing unit 430 provides the avatar ID in response to receiving the request in S410 (S430).

[0098] The second receiving unit 440 receives the representation of the avatar from the terminal (S440). Additionally, the second receiving unit 440 receives an indication from the terminal that the avatar representation is associated with the avatar ID (S440). The avatar representation and the indication that it is associated with the avatar ID can be received in one message or in multiple messages. The storage unit 450 stores the avatar representation associated with the avatar ID in the basic avatar repository (S450).

[0099] Figure 17 An apparatus according to an example embodiment is shown. The apparatus includes at least one processor 810 and at least one memory 820 storing instructions, which, when executed by the at least one processor 810, cause the apparatus to perform at least the following: Figure 10 or Figure 12 or Figure 14 or Figure 16 At least one of the methods described herein and at least one of the methods described herein.

[0100] The example implementation can be applied to fixed or mobile communication networks, such as any generation of 3GPP networks (e.g., 4G, 5G, 6G, 7G). The terminal can be a UE, IoT device, MTC device, etc., suitable for communicating with the communication network.

[0101] A message can be transmitted from one entity to another in one or more messages. Each of these messages may include additional (different) information.

[0102] The naming of network elements, network functions, protocols, and methods is based on current standards or current proposals. These namings are not restrictive. For example, in other versions or other technologies, the corresponding entities may be named differently or the same as those in this specification.

[0103] Unless otherwise stated or clear from the context, different statements about two entities mean that they perform different functions. This does not necessarily mean that they are based on different hardware. That is, each entity described in this specification may be based on different hardware, or some or all of the entities may be based on the same hardware. This does not necessarily mean that they are based on different software. That is, each entity described in this specification may be based on different software, or some or all of the entities may be based on the same software. Each entity described in this specification may be deployed in the cloud.

[0104] Based on the above description, it should be apparent that the example embodiments provide, for example, a terminal (such as a UE, MTC device, etc.) or its elements, means embodying the terminal, a method for controlling and / or operating the terminal, and a computer program for controlling and / or operating the terminal, and a medium carrying the computer program and constituting a computer program product. Based on the above description, it should also be apparent that the example embodiments also provide, for example, an avatar library (such as a BAR) or its elements, means embodying it, a method for controlling and / or operating it, and a computer program for controlling and / or operating it, and a medium carrying the computer program and constituting a computer program product.

[0105] By way of non-limiting example, implementations of any of the foregoing blocks, devices, systems, techniques, or methods include implementations as hardware, software, firmware, special-purpose circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof. Each entity described in this specification may be embodied in the cloud.

[0106] It should be understood that the above content is what is currently considered to be a preferred example embodiment. However, it should be noted that the description of the preferred example embodiment is given by way of example only, and various modifications can be made without departing from the scope of this disclosure as defined by the appended claims.

[0107] Unless otherwise stated, the terms "first X" and "second X" include options where "first X" is the same as "second X" and options where "first X" is different from "second X". As used herein, "at least one of the following: " and "at least one of " and similar wording (where the list of two or more elements is connected by "and" or "or") means at least any one of the elements, or at least any two or more of the elements, or at least all of the elements. Unless otherwise stated (e.g., using "otherwise" or "or in alternatives"), the term "or" means a non-exclusive "or".

[0108] The following provides some examples of embodiments according to this disclosure, which can be combined in any suitable manner.

[0109] Example 1. A first terminal includes one or more processors and at least one memory, the at least one memory storing instructions that, when executed by the one or more processors, cause the first terminal to perform an operation, the operation including: Request the avatar identifier in the request to the base avatar repository; In response to the request, the avatar identifier is received; and The representation of the avatar and the indication associated with the avatar identifier are uploaded to the base avatar repository.

[0110] Example 2. The first terminal according to Example 1, wherein the request includes an inquiry for querying the second terminal's use of one or more capabilities of the avatar.

[0111] Example 3. The first terminal according to Example 1 or 2, wherein the operation further includes: Together with the avatar identifier, it receives a response to the query used to inquire about the one or more capabilities.

[0112] Example 4. A first terminal according to any one of Examples 1 to 3, wherein the first terminal is configured to communicate with the underlying avatar repository using an application protocol.

[0113] Example 5. The first terminal according to Example 4, wherein the application protocol is Hypertext Transfer Protocol or Secure Hypertext Transfer Protocol or Web Real-Time Communication.

[0114] Example 6. A first terminal according to any one of Examples 1 to 3, wherein the first terminal is configured to communicate with the underlying avatar repository via a data channel application server.

[0115] Example 7. A first terminal according to any one of Examples 1 to 3, wherein the first terminal is configured to communicate with the underlying avatar repository via a media function entity.

[0116] Example 8. An apparatus comprising one or more processors and a memory, the memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: Receive a request from the terminal to provide an avatar identifier; Generate the avatar identifier; In response to receiving the request, the avatar identifier is provided; Receive from the terminal a representation of the avatar and an indication that the representation of the avatar will be associated with the avatar identifier; and The representation of the avatar associated with the avatar identifier is stored in the base avatar repository, wherein The avatar identifier is unique to the device.

[0117] Example 9. The apparatus according to Example 8, wherein the apparatus is configured to communicate with the terminal using an application protocol.

[0118] Example 10. The apparatus according to Example 9, wherein the application protocol is Hypertext Transfer Protocol or Secure Hypertext Transfer Protocol or Web Real-Time Communication.

[0119] Example 11. The apparatus according to Example 8, wherein the apparatus is configured to communicate with the terminal via a data channel application server.

[0120] Example 12. The apparatus according to Example 8, wherein the apparatus is configured to communicate with the terminal via a media function entity.

[0121] Example 13. A method executed by a terminal, the method comprising: Request the avatar identifier in the request to the base avatar repository; In response to the request, the avatar identifier is received; and The representation of the avatar and the indication associated with the avatar identifier are uploaded to the base avatar repository.

[0122] Example 14. A method comprising: Receive a request from the terminal to provide an avatar identifier; Generate the avatar identifier; In response to receiving the request, the avatar identifier is provided; Receive from the terminal a representation of the avatar and an indication that the representation of the avatar will be associated with the avatar identifier; and The representation of the avatar associated with the avatar identifier is stored in the base avatar repository, wherein The avatar identifier is unique to the device.

[0123] Example 15. A computer program product comprising a set of instructions, which, when executed by a device, cause the device to perform the method described according to Example 13 or 14.

Claims

1. A first terminal, comprising one or more processors and at least one memory, the at least one memory storing instructions that, when executed by the one or more processors, cause the first terminal to perform an operation, the operation comprising: Request the avatar identifier in the request to the base avatar repository; In response to the request, the avatar identifier is received; as well as The representation of the avatar and the indication associated with the avatar identifier are uploaded to the base avatar repository.

2. The first terminal according to claim 1, wherein the request includes an inquiry for querying the second terminal's use of one or more capabilities of the avatar.

3. The first terminal according to claim 1 or 2, wherein the operation further includes: Together with the avatar identifier, it receives a response to the query used to inquire about the one or more capabilities.

4. The first terminal according to claim 1 or 2, wherein the first terminal is configured to communicate with the base avatar repository using an application protocol.

5. The first terminal according to claim 4, wherein the application protocol is Hypertext Transfer Protocol, Secure Hypertext Transfer Protocol, or Web Real-Time Communication.

6. The first terminal according to claim 1 or 2, wherein the first terminal is configured to communicate with the underlying avatar repository via a data channel application server.

7. The first terminal according to claim 1 or 2, wherein the first terminal is configured to communicate with the underlying avatar repository via a media function entity.

8. An apparatus for communication, comprising one or more processors and a memory, the memory storing instructions that, when executed by the one or more processors, cause the apparatus to perform: Receive a request from the terminal to provide an avatar identifier; Generate the avatar identifier; In response to receiving the request, the avatar identifier is provided; Receive from the terminal a representation of the avatar and an indication that the representation of the avatar will be associated with the avatar identifier; and The representation of the avatar associated with the avatar identifier is stored in the base avatar repository, wherein The avatar identifier is unique to the device.

9. The apparatus of claim 8, wherein the apparatus is configured to communicate with the terminal using an application protocol.

10. The apparatus of claim 9, wherein the application protocol is Hypertext Transfer Protocol, Secure Hypertext Transfer Protocol, or Web Real-Time Communication.

Images