User agent management
Patent Information
- Application Number
- CN202610454915.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-04-08
- Filing Date
- 2026-04-08
- Publication Date
- 2026-10-16
AI Technical Summary
从用户正在使用的虚拟化身中标识用户可能是困难的或者不可能的,因为虚拟化身的外表可能不会与他们正代表的人紧密匹配或者可能完全不同
Smart Images

Figure CN122934246A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to a system and method for generating, registering, and using user agents or avatars, particularly for use in calls within a mobile network. Background Technology
[0002] In the world of digital communications and virtual environments, virtual avatars are steadily gaining greater significance as an indispensable tool for personal representation and interaction. When users are busy or to enhance privacy, virtual avatars can act as agents for them. For example, virtual avatars can be used in multi-user online games.
[0003] In general use, a virtual avatar is defined as someone who looks and sounds according to user preferences. Identifying a user from the virtual avatar they are using can be difficult or impossible because the avatar's appearance may not closely match or may be completely different from the person they are representing. This can pose security or protection risks when virtual avatars communicate with other users, such as in computer games or virtual worlds, especially for vulnerable users. This is also important in preventing fraud or misrepresentation.
[0004] Therefore, there is a need for improved methods and systems for the security, control, and management of virtual avatars, their creation, and use. Summary of the Invention
[0005] When a user is busy or unable to answer calls, it is useful for an agent to handle calls and other external interactions on the user's mobile device. Such an agent can take the form of a virtual avatar, which can be a visual representation of the user or a digital personification of a person. However, virtual avatars can take any form. Data or metadata can be used to generate virtual avatars, and different users can have different virtual avatars. A single user can have multiple virtual avatars for different occasions or contexts. For example, a user can have a virtual avatar for professional or work interactions and different virtual avatars for social interactions. Users can have different virtual avatars to choose from for other purposes or simply for diversity.
[0006] Users can generate data to define each virtual avatar, allowing them to have different characteristics. Users can use a mobile application to generate virtual avatar definition data.
[0007] Different virtual avatars have different virtual avatar identifiers (preferably unique identifiers). This allows different virtual avatars to be instantiated when needed. Users operating mobile devices or any user equipment (UE) also have their own subscriber identifiers, which are used to access the mobile network. To use virtual avatars on a mobile network (e.g., within a call), virtual avatar definition data and virtual avatar identifiers need to be securely generated and registered to prevent impersonation and restrict the use of virtual avatars to the extent permitted by the mobile network for that particular user. It is possible that some users do not have permission to generate and use virtual avatars (e.g., children), or that virtual avatars can only be used for limited purposes or for limited time. This method and system allow for such security and control.
[0008] A user uses a mobile device or UE to send a request to register a (new) virtual avatar. This request includes the user's subscriber information, such as their Subscription Permanent Identifier (SUPI), General Public Subscription Identifier (GPSI), or other subscription or device identifiers (e.g., International Mobile Subscriber Identity - IMSI, International Device Identifier - IMEI, or Permanent Device Identifier - PEI). This can be sent, for example, by a mobile application on the UE, or as part of another action or component, such as a native application for making and receiving calls. An application server (e.g., within a mobile network) receives and verifies the request. For example, the application server can determine whether the user is authorized to register a virtual avatar, or whether they have reached the limit on the number of virtual avatars they can generate and register.
[0009] The application server verifies the request by sending it to the Data Channel Signalling Function (DCSF). The DCSF needs to obtain subscriber information based on the subscription identifier (e.g., SUIP / GPSI) contained in the request. The DCSF does this by querying components of the user's home network, such as the Home Subscriber System (HSS), Unified Data Management (UDM), and / or Unified Data Repository (UDR). The home network components provide subscriber information based on the supplied subscriber identifier. For example, subscriber information may include access information, UE registration details, and / or communication session information, such as the UE's subscriber's Access and Mobility Management Function (AMF), Session Management Function (SMF), and / or Authentication Server Function (AUSF). This enables the UE to be verified and authenticated for the avatar service. Subscriber information may also include a list of previously registered avatars for a particular subscriber.
[0010] The DCSF sends the subscriber information (retrieved from the UE's home network) to a storage facility or data store used to store the avatar data. This could be referred to as the Basic Avatar Repository (BAR). The BAR generates a new avatar identifier (ID) and stores the avatar ID along with the subscriber identifier. The BAR also sends the avatar ID back to the DCSF, which then forwards the newly generated avatar ID to components of the home network and to the application server.
[0011] The application server sends the virtual avatar ID to the UE and another application server (e.g., a data channel application server). The data channel application provides virtual avatars and other extended reality (XR) or virtual reality (VR) services. Simultaneously (before or after other steps), the UE generates definition data or metadata to define the characteristics of the virtual avatar. This may include, for example, the virtual avatar's appearance, voice, and other characteristics. The UE sends the virtual avatar definition data to a BAR, which stores the virtual avatar definition data along with the virtual avatar ID, so that the virtual avatar definition data can be retrieved if and when the virtual avatar ID is provided (e.g., as part of a separate process).
[0012] Once a virtual avatar is registered, it can be used for various applications. One such application is to act as an agent for a user of the UE during a call. For example, a user can receive calls from a second UE or mobile device at their (first) UE. The call ringing screen can indicate the incoming call and the option for the virtual avatar to answer the call. There may be several available and registered virtual avatars, and the user can select one of them. For example, one virtual avatar may be more suitable for work or formal calls, while another virtual avatar may be more suitable for social or home calls. Optionally, a virtual avatar generation and registration process can be performed (e.g., if the user does not have any current, active, or available virtual avatars).
[0013] After the virtual avatar is selected, the UE sends or transmits the corresponding virtual avatar identifier (e.g., registered during the above method) to the DC application server.
[0014] This creates a request for the corresponding avatar definition data. The DC application server sends the avatar identifier to the avatar storage location or BAR, which retrieves the avatar definition data based on the avatar identifier provided in the request.
[0015] The avatar storage location sends avatar definition data to a DC application server, which then forwards the data to a Media Function (MF) or Media Execution Server. The MF uses the avatar definition data to generate avatar streaming data (e.g., by executing software code using the avatar definition data). The avatar streaming data is then directly transmitted to a second UE (e.g., via a mobile network), allowing the second UE to view the avatar during a call with the first UE. This simplifies the process and reduces network traffic.
[0016] Data can be sent to and from the second UE and MF, enabling responses to be created using voice, video (if it is a video call), and other components of the call. For example, virtualization streaming data can generate the virtualization's voice and video, which can ask questions. Responses to these questions (e.g., voice or text commands from the user of the second UE) can also be sent from the second UE to the MF and interpreted (e.g., using a speech-to-text converter). The MF can process this data in real time, providing real-time responses in the form of a dialogue without human intervention.
[0017] The user of the first UE can be informed of the progress or content of the virtual avatar call. For example, this could take the form of a speech-to-text converter providing real-time written transcription. Alternatively or additionally, a text transcription or summary could be provided at the end of the call. For example, at any time, the user of the first UE can intervene in the call and suspend the virtual avatar.
[0018] According to the first aspect, a method for registering a virtual avatar is provided, the method comprising: The user equipment (UE) sends a request to register a virtual avatar, wherein the request includes the UE's subscriber identifier; The application server receives the request from the UE; The application server sends the request to the Data Channel Signalling Function (DCSF), and in response, the DCSF requests subscriber information from a component of the UE subscriber's home network based on the subscriber identifier. The component of the home network provides the subscriber information to the DCSF; The DCSF sends the subscriber information to the virtual avatar storage location; The virtual avatar storage location generates the virtual avatar identifier; The virtual avatar storage location stores the virtual avatar identifier along with the subscriber identifier; The virtual avatar storage location sends the virtual avatar identifier to the DCSF; The DCSF sends virtual avatar identifiers to components of the home network and to the application server; The application server sends the virtual avatar identifier to the UE and the data channel application server; The UE generates virtual avatar definition data; The UE sends the virtual avatar definition data to the virtual avatar storage location; and This virtual avatar storage location stores the virtual avatar definition data along with the virtual avatar identifier. Therefore, virtual avatars can be registered reliably and securely.
[0019] Preferably, the application server can be an IP Multimedia Subsystem (IMS) application server. Other application servers can be used, but an IMS application server is particularly well-suited for virtualization purposes.
[0020] Optionally, the subscriber identifier may include the UE subscriber's Subscription Permanent Identifier (SUPI) and / or General Public Subscription Identifier (GPSI). For example, other subscription or device identifiers may be used, such as International Mobile Subscriber Identity (IMSI), Permanent Device Identifier (PEI), or International Mobile Equipment Identifier (IMEI).
[0021] Optionally, the method may further include having a component of the home network store a virtual avatar identifier associated with subscriber information. Thus, the home network can know that the virtual avatar was generated by a specific subscriber.
[0022] Optionally, the home network may store the UE's subscriber's avatar identifier together with previously generated avatar identifiers. Therefore, the home network can maintain a list of avatars for a specific subscriber.
[0023] Optionally, the components of the home network can be Unified Data Management (UDM) and / or Unified Data Repository (UDR). For example, other components of the home network, such as HSS or HLR, can be used.
[0024] Preferably, the virtual avatar definition data may include any one or more of the following: voice, images, and video. Other descriptive data, such as color and shape, may also be included.
[0025] Optionally, the method may further include the application server verifying the request by determining that the UE's subscriber has permission to generate a virtual avatar by receiving a virtual avatar identifier from the DCSF. Security, verification, and authentication may also be performed. Thus, by receiving the virtual avatar identifier (after a successful or earlier step), the application server can ensure that the subscriber has permission to generate, register, and use virtual avatars (e.g., within a call).
[0026] Optionally, the method may further include: Receive a call at a UE, where the UE is the first UE and the call originates from a second UE; The first UE receives the selection of a virtual avatar corresponding to the virtual avatar identifier; The first UE sends the virtual avatar identifier to the DC application server; The DC application server sends the virtual avatar identifier as part of a request for virtual avatar definition data to the virtual avatar storage location; The virtual avatar storage location retrieves virtual avatar definition data based on the virtual avatar identifier; The virtual avatar storage location sends the virtual avatar definition data to the DC application server; The DC application server sends virtual avatar definition data to the media function (MF) or media execution server; This MF generates virtual avatar stream data based on virtual avatar definition data; and The MF sends the virtual avatar streaming data to the first UE. For example, the virtual avatar can be used for purposes other than making a call, such as within a game or social media application. The MF then sends the virtual avatar streaming data directly to the second (calling) UE.
[0027] Alternatively, communication between the data channel application server and the virtualization storage location is via a dedicated interface. This can be an interface independent of those used in other signaling and messaging within the method and system.
[0028] According to the second aspect, a user equipment (UE) is provided, which includes: One or more processors; and One or more memories storing computer-executable instructions that, when executed by a processor, cause the UE to: Send a request to register a virtual avatar, wherein the request includes the subscriber's identifier for the UE; Receive the virtual avatar identifier from the application server; Generate virtual avatar definition data; and Send the virtual avatar definition data to the virtual avatar storage location.
[0029] Preferably, the avatar definition data can be generated by a mobile application. For example, the avatar definition data can also be generated outside the UE (e.g., downloaded from an external source).
[0030] Alternatively, the application can be downloaded from the data channel application repository located within the core network. Other application stores may also be used to distribute the application.
[0031] According to the third aspect, a system is provided, comprising: One or more UEs as described above; Application server; Data Channel Signaling Function (DCSF); Components belonging to the network; Virtual avatar storage location; and Data channel application server, where The application server is configured as follows: Receive requests from the UE, and Send the request to DCSF; and in which The DCSF is configured as follows: In response to a request from the application server, subscriber information is requested from a component of the home network based on the subscriber identifier; and whereby... Components of the home network provide subscriber information to the DCSF; and among them The virtual avatar storage location is configured as follows: Generate virtual avatar identifiers. Storage virtual avatar identifier along with subscriber identifier, and Send the virtual avatar identifier to the components of the home network and to the application server; and whereby The application server is further configured as follows: Send the virtual avatar identifier to the UE and to the data channel application server; and where The virtual avatar storage location is further configured as follows: The virtual avatar definition data is stored together with the virtual avatar identifier.
[0032] Preferably, the virtual avatar storage location can be located in the (mobile operator's) core network.
[0033] According to another aspect, a communication method is provided, which includes: A call is received at a first user equipment (UE), wherein the call originates from a second UE; The selection of a virtual avatar is received at the first UE; The first UE sends the virtual avatar identifier of the selected virtual avatar to the data channel DC application server; The DC application server sends the virtual avatar identifier as part of a request for virtual avatar definition data to the virtual avatar storage location; The virtual avatar storage location retrieves virtual avatar definition data based on the virtual avatar identifier; The virtual avatar storage location sends the virtual avatar definition data to the DC application server; The DC application server sends virtual avatar definition data to the media function MF; This MF generates virtual avatar stream data based on virtual avatar definition data; and The MF sends virtual avatar streaming data to the second UE. Therefore, the proxy or virtual avatar can answer calls more conveniently and securely. For example, the call could be a video call using a mobile network.
[0034] Optionally, the method may further include registering the virtual avatar before receiving a call. Registration can be performed by any suitable method, but it is preferred to register according to the registration process described in detail in this specification.
[0035] Optionally, during a call with the second UE, the virtual avatar stream data can be rendered to generate the interaction between the virtual avatar and the second UE. This rendering can occur on the UE or at another location (e.g., within a part or component of a mobile network).
[0036] Optionally, the interaction may include a response to an in-call inquiry from the second UE. This inquiry may be generated at the virtual avatar (e.g., “Who is calling?”, “What is the subject of the call?”, etc.) or from the caller (e.g., “When is the first user available to make the call?”).
[0037] Optionally, the interaction may include a request for the reason for the call.
[0038] Optionally, the interaction may include a proposal to call back a second UE. This proposal or inquiry may originate from the virtual avatar (e.g., "The person you are calling is currently unavailable. Would you like them to call you back?").
[0039] Optionally, the method may further include consulting the user's calendar for the first UE to determine the available time and date for a callback. The calendar may be an application on the first UE, or it may be data stored elsewhere (e.g., data stored on a separate server or on a virtual server or service). For example, the calendar may be accessed via an application programming interface (API).
[0040] Optionally, the rendered virtual avatar may present a proposal of the determined callback availability time and date to the user of the second UE during the call. For example, one or more alternative callback times and dates may be provided.
[0041] Optionally, when the rendered virtual avatar receives an indication from the user of the second UE during a call to reject the proposed callback time and date, the rendering of the virtual avatar proposes an alternative time and date to the user of the second UE during the call. This process or series of interactions may be repeated until a suitable (approved date and time) is presented and accepted.
[0042] Optionally, the method may further include the rendered virtual avatar receiving an instruction from the user of the second UE during the call to accept the proposed callback time and date, and in response, saving the callback appointment at the accepted time and date in the calendar of the user of the first UE. For example, the appointment or reminder may have an advance reminder time (e.g., sending a notification or reminder before the appointment).
[0043] Optionally, the method may further include providing a written description of the interaction and / or a summary of the call results. This could be text displayed on the first UE's display, stored in the UE's memory, sent (e.g., via email) to the user of the first UE, or otherwise provided. For example, the text could be generated at a media function (MF) and transmitted over a network.
[0044] Optionally, a written description may be provided in real time during the interaction and / or at the end of the call. For example, as the call progresses, a live display may show a scrolling or continuous stream of text on the screen.
[0045] Optionally, the method may further include receiving a request to intervene in the call from a user of the first UE, and in response to the request, pausing or stopping the incorporation of virtual avatar streaming data into the call. For example, the user may press a button or optional icon on the display of the first UE. This will pause or stop the rendering of the virtual avatar (and the streaming of the virtual avatar streaming data from the MF) and provide the user with an interface to continue the call (e.g., activating the microphone, camera, displaying a second user on the screen, etc.).
[0046] According to another aspect, a user equipment (UE) is provided, which includes: One or more processors; and One or more memories storing computer-executable instructions that, when executed by a processor, cause the UE to: A call is received at a UE, which is the first UE, where the call originates from a second UE; Receive the choice of a virtual avatar; and The virtual avatar identifier of the selected virtual avatar is sent to the data channel DC application server. Multiple UEs may exist in the mobile network. Each UE can act as either a first UE (receiving calls) or a second UE (initiating and making calls).
[0047] According to another aspect, a system is provided, comprising: One or more UEs as described above; Data channel DC application server; Virtual avatar storage location; and Media Functions (MF) The DC application server is configured to send the virtual avatar identifier as part of a request for virtual avatar definition data to the virtual avatar storage location. The virtual avatar storage location is configured as follows: Retrieving virtual avatar definition data based on virtual avatar identifier; and Send the virtual avatar definition data to the DC application server. The DC application server is further configured to send virtual avatar definition data to MF, and The MF is configured as follows: Generate virtual avatar stream data based on virtual avatar definition data; and The virtual avatar stream data is sent to the second UE. For example, there may be multiple entities or devices, each operating within a communication network. The second UE (caller) is the UE that initiated the call to the first UE (call receiver).
[0048] It should be noted that individual methods can be combined and used in any combination. For example, a method for registering a virtual avatar can be combined with and follow a communication method. However, methods can be implemented independently. Furthermore, the UE and the system can each include all the functions and components for registering and using the virtual avatar (e.g., by implementing the communication method).
[0049] The above method can be implemented as a computer program including program instructions for operating a computer. The computer program can be stored on a computer-readable medium, including non-transitory computer-readable media.
[0050] A computer system may include one or more processors (e.g., local, virtual, or cloud-based), such as a central processing unit (CPU), and / or a single graphics processing unit (GPU) or a collection of GPUs. The processors may execute logic in the form of software programs. The computer system may include memory, comprising volatile and non-volatile storage media. Computer-readable media (CRMs) may be included to store logic or program instructions. For example, embodiments may include a non-transitory computer-readable medium (CRM) storing software including instructions executable by one or more computers, which, upon such execution, cause the one or more computers to perform disclosed methods. A non-transitory CRM may refer to a CRM that stores data temporarily or in the presence of electricity, such as a memory device or random access memory (RAM). For example, a non-transitory computer-readable medium may include storage components such as hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state disks), compact discs (CDs), digital versatile discs (DVDs), floppy disks, magnetic tape cassettes, and / or magnetic tapes. Different parts of the system may be connected using a network (e.g., wireless and wired networks). The computer system may include one or more interfaces. For example, a computer system may contain a suitable operating system, such as UNIX (RTM), Windows (RTM), or Linux (RTM).
[0051] It should be noted that any of the above features can be used with any particular aspect or embodiment of the invention. Attached Figure Description
[0052] This invention can be practiced in many ways, and embodiments will now be described by way of example only and with reference to the accompanying drawings, wherein: Figure 1 A flowchart illustrating the method for registering a virtual avatar is shown; Figure 2 It shows the use of Figure 1 A flowchart of the communication method of the virtual avatar; Figure 3 The following diagram illustrates the implementation. Figure 1 and Figure 2 A schematic diagram of the computer system for the method; Figure 4 The following diagram illustrates the implementation. Figure 1 and Figure 2 A schematic diagram of the communication system using this method; Figure 5 The following diagram illustrates the implementation. Figure 1 and Figure 2 Another schematic diagram of the communication system using this method; Figure 6 The following diagram illustrates the implementation. Figure 1 and Figure 2 A schematic diagram of a part of the communication system of the method; Figure 7 Instructions for registration are shown. Figure 1 Sequence diagram of another aspect of the method of virtual avatar; Figure 8 Explanation is shown Figure 2 Sequence diagrams of other aspects of the communication methods; and Figure 9 A schematic diagram is shown of the process for interpreting speech during a call that includes a virtual avatar.
[0053] It should be noted that the figures are shown for simplicity and are not necessarily drawn to scale. The same features are provided with the same reference numbers. Detailed Implementation
[0054] A virtual avatar is a digital representation, agent, or character that represents a user in a virtual environment such as virtual reality (VR), augmented reality (AR), or extended reality (XR). These virtual avatars can range from 2D representations to highly detailed 3D realistic models that mimic the user's appearance or behavior in real time.
[0055] For some time, 3GPP has been standardizing XR-related concepts. This disclosure presents the functions of virtual avatars, including their integration into existing communication services and technical support for immersive virtual environments, thereby enhancing the user experience.
[0056] Figure 1 A flowchart of method 10 for registering a virtual avatar or agent for a user is shown. At step 15, the mobile device or user equipment (UE) initiates method 10 by requesting registration or a new virtual avatar identifier. This request can be initiated at any time, including but not limited to when the user receives a call. The request includes the UE's identifier. The UE's identifier can be a Subscription Permanent Identifier (SUPI), a General Public Subscription Identifier (GPSI), or other identifiers (e.g., International Mobile Subscriber Identity – IMSI, International Device Identifier – IMEI, or Permanent Device Identifier – PEI). At step 20, an application server, such as an IP Multimedia Subsystem (IMS), receives the request from the UE.
[0057] The application server verifies the request by confirming that the requesting UE has permission to create a virtual avatar. At step 25, the application server does this by sending a request to the Data Channel Signalling Function (DCSF). In response, the DCSF requests subscriber information by sending the UE identifier included in the request to a component of the UE subscriber's home network (step 30). This component could be, for example, the Home Location Register (HLR), Home Subscriber Server (HSS), Unified Data Management (UDM), and / or Unified Data Repository (UDR).
[0058] At step 35, the home network component provides subscriber information to the DCSF, and at step 40, the DCSF sends the subscriber information to the virtualization storage location (e.g., the Basic Virtualization Repository – BAR). Optionally, one or more identifiers of the UE may also be sent along with the subscriber information. This triggers the BAR to generate a new virtualization or proxy identifier (step 45) and store the virtualization identifier along with the subscriber identifier, so that the virtualization identifier can be retrieved when the subscriber identifier is provided (step 50). At step 55, the BAR sends the generated virtualization identifier to the DCSF (in response to the DCSF sending the UE subscriber information to the BAR).
[0059] At step 60, the DCSF now sends the virtual avatar identifier to the home network component (UDM / UDR) and to the application server. At step 65, the application server sends the virtual avatar identifier to the UE and to the data channel (DC) application server (e.g., an extended reality (XR) or virtual reality (VR) application server). The UE can now generate (or has already generated) data defining the virtual avatar (step 70). This data may include metadata and any other information necessary for rendering the virtual avatar. At step 75, this data definition data is sent to the BAR, and at step 80, the BAR stores the virtual avatar definition data along with the virtual avatar identifier. The BAR may have a database 272 for storing this data.
[0060] Once at least one virtual avatar has been created and registered for a UE user, that virtual avatar can be used. Figure 2 A flowchart is shown for a method 100 for incorporating a virtual avatar into a call made by a second UE or a mobile device to a first UE.
[0061] At step 115, the first UE receives a call. The user of the first UE decides not to answer the call, but instead selects a virtual avatar (if they have more than one virtual avatar to choose from) to answer the call on their behalf (step 120). At step 125, the first user sends the virtual avatar identifier of the selected virtual avatar to the DC application server. The DC application server may verify the request to determine if the virtual avatar identifier is valid (e.g., it may optionally expire after a period of time). At step 130 (e.g., after successful verification), the DC application server creates a request for virtual avatar definition data, including the virtual avatar identifier, and sends the request to the virtual avatar storage location or BAR.
[0062] At step 135, the BAR uses the avatar identifier as a reference to retrieve avatar definition data from a database or data store. The avatar definition data may have already been created on the first UE or elsewhere. If no saved avatar definition data is available for the requested avatar identifier, the BAR may return an error or simply fail to respond. When the saved avatar definition data is available and can be retrieved, at step 140, the BAR sends this data to the DC application server.
[0063] The avatar definition data is data or metadata processed by a suitable executable file or function to generate visual, video, and / or audio data representing the avatar. This processing is performed by a media function (MF) or a media generation server. At step 145, the DC application server sends the avatar definition data to the MF, which generates avatar streaming data from the avatar definition data at step 150. At step 155, the MF streams the data to a second UE (e.g., the avatar's video and audio). This can take the form of the first UE accepting a call, but instead of the first UE's microphone (and camera) being used to capture the first user's voice (and image), the avatar representation is incorporated into the call stream, which is sent directly to the second UE. At step 160, the user's response from the second UE is obtained and sent to the MF. This processing may include natural language processing and artificial intelligence (AI) and machine learning (ML) techniques. For example, the processing may include: AI-ML-based speech recognition, intent recognition, entity recognition, data access, natural language generation, and follow-up processing.
[0064] Once a virtual avatar call has been initiated, it can continue without user input. However, the user can be updated on the call's progress either in real-time or after the call has concluded. For example, the ongoing call transcription (both the virtual avatar's voice and text and the caller's voice) can be captured and presented to the user of the first UE. This text can be displayed on the screen or sent or stored as a file after the call has ended. In some example implementations, the user of the first UE (who receives the call and initiates the virtual avatar) can intervene in the call and suspend or stop the virtual avatar from participating in the call. For example, there might be some switching action, such as the virtual avatar notifying the user that a call will soon be initiated.
[0065] The virtual avatar can interact with the caller in different ways. For example, the virtual avatar can request the caller to describe the purpose of the call, and this can be communicated to the call recipient (the user of the first UE). The virtual avatar can additionally or alternatively offer the caller the option for the call recipient to call back the caller. If the caller accepts such an option, systems and methods operating on the first UE can query or consult the call recipient's calendar (either within the UE or by accessing a remote calendar). The purpose of this calendar consultation is to find a suitable and available time for the call recipient to call back the caller. For example, this might be indicated in the calendar as part of a typical workday (if a formal or work virtual avatar is selected), or as a free time in the evening or on a weekend if a social or family virtual avatar is selected. Pre-set rules can exist by the call recipient to determine whether, how, and when a call back can be scheduled.
[0066] Once a suitable callback time and date have been determined, this information can be presented to the caller by the virtual avatar during the call. If the caller accepts the callback time and date (e.g., by saying "yes" or nodding during a video call), the system and methods can add a calendar entry for that time (with or without a reminder). If the caller indicates that they cannot accept that time and date (e.g., by saying "no" or shaking their head during a video call), the calendar can be consulted again to find alternative available times and dates that also meet the caller's criteria. This process can loop or continue until an acceptable callback time and date has been provided and approved by the caller. For example, interaction with the calendar can be done via an application programming interface (API).
[0067] Refer to each Figure 1 and Figure 2 Both methods 10 and 100 described can be executed by computer system 200. For example, computer system 200 may include one or more individual machines or nodes.
[0068] like Figure 3 As shown, computer system 200 includes multiple components, including a communication interface 220, system circuitry 230, input / output (I / O) circuitry 240, display circuitry and interface 250, and data storage 270. System circuitry 220 may include one or more processors or CPUs 280 and memory 290. System circuitry 230 may include any combination of hardware, software, firmware, and / or other circuitry. System circuitry 230 may be implemented using one or more system-on-a-chip (SoC), application-specific integrated circuit (ASIC), microprocessor, and / or analog and digital circuitry.
[0069] The display circuitry can provide one or more graphical user interfaces (GUIs) 260, and the I / O interface circuitry 240 can include touch-sensitive or non-touch displays, sound, voice, or other recognition inputs, buttons, switches, speakers, audio devices, and other user interface elements. The I / O interface circuitry 240 can include microphones, cameras, headphones, and microphone input / output connectors, a universal serial bus (USB) connector, and SD or other memory card slots. The I / O interface circuitry 240 may further include data media interfaces (e.g., CD-ROM or DVD drives) and other bus and display interfaces.
[0070] Memory 290 may include volatile (RAM) or non-volatile memory (e.g., ROM or flash memory). Memory may store the operating system 292, application programs or software 294, dynamic data 296, and / or static data 298 of the computer system 200. For example, data storage or data source 270 may include one or more databases 272, 274, and / or file storage or file systems. Database 272 may form part of a BAR.
[0071] Figure 4 A schematic diagram of a system 300 for implementing methods 10 and 100 is shown. System 300 includes different components of a communication network and multiple interfaces for transmitting data and signaling between these components. Figure 4 The diagram illustrates the use of the IP Multimedia Subsystem (IMS) architecture in System 300. This architecture is integrated with other functions and enabled via a data channel (DC). The diagram connects nodes and network functions, references corresponding interfaces (DC1, DC2, DC3, DC4, DC5, and DC6), and highlights key connections for this example implementation. In this example, System 300 is based on an architecture of approximately 5GC.
[0072] exist Figure 4The diagram illustrates a single UE 310. However, in the implemented system, more than one UE 310 can operate. UE 310 sends its registration virtual avatar request via the IMS proxy and the Serving Call Session Control function, which handles the normal IMS registration. The application server in this example implementation is an IMS Application Server (IMS AS) 320. The interface between IMS AS 320 and DCSF 330 is illustrated in the diagram. The home network component is the UDM / UDR 340. The interface (DC1) between IMS AS 320 and DCSF 330 is also shown.
[0073] exist Figure 4 In the diagram, the virtual avatar storage location or repository is shown as the base virtual avatar repository BAR 350. BAR 350 communicates with the DC application server 360 using interface DC6. The DC application server includes functionality to provide extended reality (XR) and augmented reality (AR) services. The DC application server communicates with the DCSF 330 using interface DC4. A mobile application is used on the UE 310 to generate virtual avatar definition data. The mobile application is provided by the DC application repository 380.
[0074] As previously mentioned, once the virtual avatar is registered, the MF 370 receives the virtual avatar definition data from the DC application server 360 and streams the data to the UE 310 through various components of the system 300.
[0075] Figure 5 Another schematic diagram of system 300 is shown, illustrating... Figure 4 The diagram shows the components, but also illustrates the different communication planes used for various interfaces and data. The diagram shows where virtual avatar data 410 is defined (within application 420 of UE 310) and generated (within MF 370). Media plane 430 provides streaming services for this data. Mobile network communication 440 is illustrated to show cellular messaging. IMS service 450 is illustrated within the mobile network.
[0076] In the context of avatar communication and avatar calls, it is important to identify, authenticate, and authorize avatars within the communication network and map them to registered or subscribed UEs. The mobile application used to generate avatar definition data is the avatar creation application. The avatar creation application can belong to the MNO network, a third party, or an AR / XR-enabled device application, and it supports authentication and registration via a BAR (Basic Avatar Store) / UDM (Unified Data Management) / UDR (Unified Data Repository) repository, depending on the described methods and systems. The avatar creation application can communicate with the core network to store avatars in the BAR (Basic Avatar Store) within the operator network.
[0077] The creation and storage of virtual avatars require the identification and authentication of the virtual avatars. This, in turn, requires the secure assignment of a virtual avatar identifier to the virtual avatar, which is mapped to a subscriber within the network. Mapping the virtual avatar identifier to a specific user and optionally also to a user equipment is a crucial step in this process, as it ensures that the entity (virtual avatar) can be trusted by other users, properly authenticated, authorized, and securely stored, with the user equipment having a device identifier known to the user and (optionally) the network operator (e.g., Subscription Permanent Identifier (SUPI), General Public Subscription Identifier (GPSI), International Mobile Subscriber Identity (IMSI), Permanent Device Identifier (PEI), and / or International Mobile Equipment Identifier (IMEI)).
[0078] Before the avatar creation application can be used on UE 310 to create avatars, the application must be downloaded and installed, followed by subscriber authentication. However, the avatar creation application itself can be verified and authenticated to enhance security. Figure 6 This diagram illustrates the relationship between the virtual avatar creating the application and the Network Open Function (NEF) performing such authentication and verification. This prevents malicious applications from being downloaded and installed. The process can be based on third-party application authentication as defined in 3GPP.
[0079] Once a verified virtual avatar creation application has been installed on the UE 310, the first (and any additional) virtual avatars can be created and registered according to Method 10. Figure 7 The sequence diagram illustrates another aspect of method 10. This results in the virtual avatar being identified and mapped to a specific UE and / or subscriber.
[0080] When a virtual avatar is generated in the virtual avatar creation application, it is submitted to the network to be stored in the BAR350 (and assigned to the UE's configuration file).
[0081] 1. Virtual avatar registration requests are sent from UE 310 and the application repository (within UE 310) to IMS AS320.
[0082] 2. The IMS Application Server (AS) 320 sends a subscriber information request to the DCSF 330. The DCSF 330 queries the subscription information from the UDM / UDR 340. The response from the UDM / UDR 340 includes the UE's SUPI / GPSI, optionally IMEI / PEI, and a list of virtual avatar identifiers (if a previous virtual avatar has been created and registered).
[0083] 3. After receiving information from UDR / UDM 340, DCSF 330 sends a virtual avatar registration request to BAR 350 via XR AS 320. This request contains UE subscription information and a list of virtual avatar IDs. The request prompts BAR 350 to send a new virtual avatar identifier.
[0084] Note 1: The new interface (DC6) for signaling is used for communication between the XR (DC / AR) AS 360 and BAR 350.
[0085] 4. BAR 350 checks the UE's configuration file and avatar ID list, and generates a new avatar identifier. The new avatar identifier is sent back to DCSF 330.
[0086] 5. DCSF 330 provides a virtual avatar identifier as a response to an IMS AS 320 registration request.
[0087] 6. IMS AS 320 updates the list of virtual avatar identifiers in UDR / UDM 340 and XR (DC / AR) AS 360. Communication to XR (DC / AR) AS 360 is performed using the DC1 and DC4 interfaces. These interfaces have been modified to update information about the virtual avatar list for a specific UE 310. DC4 contains GPSI information identifying the UE 310.
[0088] Note 2: The XR AS 320 includes data channel (DC) and / or AR AS capabilities and supports all next-generation real-time communications. The DC AS 360 currently supports IMS network tasks based on the data channel. The AR AS 320 currently supports IMS-based AR communication services.
[0089] 7. IMS AS 320 confirms the virtual avatar identifier using BAR 350 and sends the new virtual avatar identifier to UE 310.
[0090] 8. UE 310 stores the new virtual avatar together with the corresponding virtual avatar identifier in BAR 350.
[0091] Figure 7 A more detailed sequence diagram of method 100 is shown, which is used to initiate a virtual avatar call using a virtual avatar generated and registered when using method 10. When a user needs to use a virtual avatar, a list of virtual avatar identifiers is downloaded to UE 310 via the bootstrap data channel through DCSF 330. DCSF 330 verifies whether UE 310 is allowed to use the virtual avatar representation.
[0092] Note 3: The UE 310 may have a default avatar and several options to select any other saved avatar from the avatar list on the UE screen. These alternative avatars may be situation-specific or selected based on the user's current preferences.
[0093] The method can begin once the following required components have been installed or are available for UE 310: IMS-Aware Virtual Avatar Application: This application can be embedded in the UE 310 or downloaded from, for example, AR / XR / DC AS 360 or DC application repositories 380. The virtual avatar application can be used to create virtual avatars.
[0094] The IMS stack includes DC(AR)MTSI: DC(AR)MTSI support is provided in chipsets with an IMS stack. This enables devices to communicate with data channels that support IMS networks. Separate Rendering Client (SRC) and Separate Rendering Server (SRS) are separate rendering components on the client and device, respectively. These can be used individually or in combination based on specific purposes and device capabilities.
[0095] The following components are available in the mobile IMS network: - MF MRF (Media Functions Media Repository Functions): The MF 370 or Enhanced MRF includes additional media functions to support new services, such as data channels, separate rendering, media functions related to virtual avatars, and media functions related to AI.
[0096] - BAR (Basic Virtual Avatar Repository): BAR 350 is used to store and retrieve virtual avatar models from 5GC.
[0097] Note 4: The virtual avatar identifier stored in BAR 350 is assigned to each virtual avatar and subscriber identifier.
[0098] - DC Application Repository: This is a storage system used to house applications, content, or services related to the data channel.
[0099] - AR / XR / DC AS 360: It manages and delivers immersive experiences by handling data communications, user sessions, and content delivery for AR / XR applications.
[0100] The following describes an example of how a virtual avatar can be used once it has been registered: UE 2 turns on the dialer and calls UE 1.
[0101] UE 1 receives a call (ringing).
[0102] The ringing answer option is downloaded from the DC application server 360 (to UE1).
[0103] UE 1 already stores two (but potentially more) virtual avatars in the BAR 350 within the network. These virtual avatars (their identifiers) are mapped, identified, and associated with their subscriber identifiers (e.g., SUPI / GPSI), and optionally also with their device (IMEI / P).
[0104] UE 1 can create and save virtual avatars to the network either from a third-party provider or by using a virtual avatar application (part of the device or a downloaded application) on the device. In an alternative implementation, the IMS data channel on the dial pad screen may have the option to select whether to create or edit virtual avatars downloaded from DC (XR / AR) AS 360 via the boot data channel through DCSF 330 on the screen (e.g., using JavaScript).
[0105] UE 1 saves the newly created virtual avatar (in this example, the user of UE 1 wants to use the virtual avatar to answer calls), and the newly created virtual avatar, along with other pre-created virtual avatars, is mapped to their identities.
[0106] UE 1 receives a call and presents them on their device screen with the option to choose a virtual avatar from their own available pre-created virtual avatars. The name or an icon for identification is displayed on the telephone dialer screen.
[0107] Note: This utilizes the capabilities of a next-generation RTC using the IMS data channel concept. Options can be downloaded from the DC (AR / XR) AS 360 to the dialer via a JavaScript screen during the setup of the data channel.
[0108] Therefore, users of UE 1 do not answer calls directly, but instead select their virtual avatars to do so.
[0109] When a call is established, a virtual avatar of UE1 appears on the screen of UE2 (the caller or dialer). In the example implementation, the virtual avatar asks the user of UE2 for the reason for the call, whether UE2 wants to leave a message, and / or whether the caller prefers to call back on a certain date and time.
[0110] In one example implementation, artificial intelligence (AI) can be used to enhance the operation and control of the virtual avatar during a call, allowing the caller to leave voice or text messages while speaking to the virtual avatar.
[0111] Note that AI can perform text-to-speech, speech-to-text, text-to-text, and speech-to-speech conversions, generate communications, and display the results on the screens of either or both parties.
[0112] UE 1 can receive a transcription of the communication between the virtual avatar and the caller of UE 2 on their screen.
[0113] UE 1 users can intervene whenever they wish, or leave the call entirely to the virtual avatar.
[0114] When communication between the virtual avatar and the caller (UE 2) is complete, the call ends, and the network delivers the caller's (UE 2) message and / or script to the recipient's (UE 1's) inbox.
[0115] In the example implementation, the virtual avatar (e.g., an AI-controlled avatar) can set or schedule callback times and dates. For example, an application programming interface (API) call to the recipient's calendar can allow the virtual avatar to check, verify, and update the call recipient's availability. Different time periods can be offered to the caller, or the caller can suggest their preferred callback time and date. If the requested time period is available, a callback can be scheduled (using the API). Otherwise, another date and / or time can be offered. This can continue until a suitable time and date are found.
[0116] Figure 8 A sequence diagram illustrating method 100 in more detail is shown. Identical components and features have the same reference numerals. Both the subscriber (call receiver) of UE1 and the subscriber (caller) of UE2 are licensed to use the virtual avatar calling function. These licenses are recorded in the components of the home network (UDR / UDM) according to their respective subscriber identifiers.
[0117] System 300 can generate responses to speech from a caller acting as a virtual avatar. MF370 can generate streaming virtual avatar data, presenting these responses in the form of the generated virtual avatar. This is achieved using natural language processing and artificial intelligence / machine learning (AI / ML) technologies. Figure 9 The diagram illustrates the process of a verbal response from UE2 (the caller), which is decoded and processed using AI / ML to provide the caller with follow-up actions and responses as if delivered by a virtual avatar.
[0118] The method and system can be implemented using hardware, software, or a combination of both. The method and system can be implemented as a server comprising a single computer system, or as a distributed network of servers connected across a network. Any type of computer system or other electronic device can be adapted to perform the described method.
[0119] As used throughout this document (including in the claims), unless the context otherwise requires, the singular form of a term is to be interpreted to include the plural form, and vice versa. For example, unless the context otherwise requires, singular references such as “a” or “an” herein (including in the claims) mean “one or more”. Throughout the specification and claims of this disclosure, the words “comprising,” “including,” “having,” and “containing,” as well as variations of these words (e.g., “including” and “comprising” or similar), mean “including but not limited to” and are not intended to exclude (and do not exclude) other components. Furthermore, the use of “or” is inclusive, such that the phrase “A or B” is true when “A” is true and “B” is true, or when both “A” and “B” are true.
[0120] The use of any and all examples or exemplary language (“e.g.,” “such as,” “for example,” and similar language) provided herein is intended only to better illustrate this disclosure and does not indicate any limitation on the scope of this disclosure unless otherwise stated. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.
[0121] The terms "first" and "second" may be reversed without altering the scope of this disclosure. That is, an element referred to as a "first" element may be referred to as a "second" element instead, and an element referred to as a "second" element may be regarded as a "first" element instead.
[0122] Any steps described in this specification may be performed in any order or simultaneously unless otherwise stated or required by the context. Furthermore, the fact that a step is described as being performed after another step does not preclude the performance of an interim step.
[0123] It should also be understood that, for any given component or embodiment described throughout the text, any possible candidates or alternatives listed for that component may generally be used alone or in combination with each other, unless implicitly or explicitly understood or otherwise stated. It will be appreciated that any list of such candidates or alternatives is merely illustrative and not restrictive, unless implicitly or explicitly understood or otherwise stated.
[0124] Unless otherwise stated, all technical and scientific terms used throughout this document have the meanings commonly understood by one of ordinary skill in the art to which the various embodiments described herein pertain.
[0125] As those skilled in the art will appreciate, the details of the above embodiments may be changed without departing from the scope of the invention as defined by the appended claims.
[0126] For example, although only one or two devices (UEs) are shown and described, any number of devices can exist in a communication system with similar functionality. Furthermore, any network component and server can be replicated to provide load balancing or redundancy. Virtual avatars can take any form and are not limited to a human appearance. For example, different (or identical) virtual avatars can speak different languages.
[0127] Many combinations, modifications, or variations of the features of the above embodiments will be apparent to those skilled in the art and are intended to form part of the invention. Any feature described in particular relation to one embodiment or example may be used in any other embodiment with appropriate changes.
Claims
1. A method for registering a virtual avatar, the method comprising: The user equipment (UE) sends a request to register a virtual avatar, wherein the request includes the subscriber identifier of the UE; The application server receives the request from the UE; The application server sends the request to the Data Channel Signalling Function (DCSF), and in response, the DCSF requests subscriber information from a component of the UE subscriber's home network based on the subscriber identifier. The components of the home network provide the subscriber information to the DCSF; The DCSF sends the subscriber information to the virtual avatar storage location; The virtual avatar storage location generates a virtual avatar identifier; The virtual avatar storage location stores the virtual avatar identifier together with the subscriber identifier; The virtual avatar storage location sends the virtual avatar identifier to the DCSF; The DCSF sends the virtual avatar identifier to the components of the home network and to the application server; The application server sends the virtual avatar identifier to the UE and to the data channel application server; The UE generates virtual avatar definition data; The UE sends the virtual avatar definition data to the virtual avatar storage location; and The virtual avatar storage location stores the virtual avatar definition data together with the virtual avatar identifier.
2. The method according to claim 1, wherein, The application server is the IP Multimedia Subsystem—IMS—Application Server.
3. The method according to claim 1 or claim 2, wherein, The subscriber identifier includes the UE subscriber’s subscription permanent identifier SUPI and / or general public subscription identifier GPSI.
4. The method according to any of the preceding claims, further comprising, wherein a component of the home network stores a virtual avatar identifier associated with the subscriber information.
5. The method according to claim 4, wherein, The home network stores the UE's subscriber's virtual avatar identifier together with the previously generated virtual avatar identifier.
6. The method according to any of the preceding claims, wherein, The components of the home network are Unified Data Management (UDM) and / or Unified Data Repository (UDR).
7. The method according to any of the preceding claims, wherein, The virtual avatar definition data includes any one or more of the following: voice, images, and video.
8. The method according to any of the preceding claims, further comprising, wherein the application server verifies the request by determining that the UE subscriber has permission to generate a virtual avatar by receiving the virtual avatar identifier from the DCSF.
9. The method according to any of the preceding claims, further comprising: A call is received at the UE, wherein the UE is a first UE and the call originates from a second UE; The first UE receives a selection of a virtual avatar corresponding to the virtual avatar identifier; The first UE sends the virtual avatar identifier to the DC application server; The DC application server sends the virtual avatar identifier as part of a request for virtual avatar definition data to the virtual avatar storage location; The virtual avatar storage location retrieves the virtual avatar definition data based on the virtual avatar identifier; The virtual avatar storage location sends the virtual avatar definition data to the DC application server; The DC application server sends the virtual avatar definition data to the media function MF; The MF generates virtual avatar stream data based on the virtual avatar definition data; and The MF sends the virtual avatar stream data to the second UE.
10. The method according to any of the preceding claims, wherein, Communication between the data channel application server and the virtual avatar storage location is via a dedicated interface.
11. A user equipment (UE), comprising: One or more processors; as well as One or more memories storing computer-executable instructions that, when executed by the processor, cause the UE to: Send a request to register a virtual avatar, wherein the request includes the subscriber identifier of the UE; Receive the virtual avatar identifier from the application server; Generate virtual avatar definition data; and The virtual avatar definition data is sent to the virtual avatar storage location.
12. The UE according to claim 11, wherein, The virtual avatar definition data is generated by the mobile application.
13. The UE according to claim 12, wherein, The application was downloaded from the data channel application repository located within the core network.
14. A system comprising: One or more UEs according to any one of claims 11 to 13; Application server; Data Channel Signaling Function (DCSF); Components belonging to the network; Virtual avatar storage location; and Data channel application server, where The application server is configured as follows: Receive the request from the UE, and The request is sent to the DCSF; and wherein The DCSF is configured as follows: In response to a request from the application server, subscriber information is requested from a component of the home network based on the subscriber identifier; and wherein The components of the home network provide the subscriber information to the DCSF; and wherein The virtual avatar storage location is configured as follows: Generate virtual avatar identifier; Store the virtual avatar identifier together with the subscriber identifier, and Send the virtual avatar identifier to the components of the home network and to the application server; and wherein The application server is further configured to: The virtual avatar identifier is sent to the UE and to the data channel application server; and wherein The virtual avatar storage location is further configured as follows: The virtual avatar definition data is stored together with the virtual avatar identifier.
15. The system according to claim 14, wherein, The virtual avatar is stored in the core network.