WO2025258941A1

WO2025258941A1 - Methods and apparatuses for facilitating user profile exchange between rich communication services clients

Info

Publication number: WO2025258941A1
Application number: PCT/KR2025/007830
Authority: WO
Inventors: Sunil Kumar NAGARAJU; Manasini Jayaramaraju
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2024-06-13
Filing date: 2025-06-09
Publication date: 2025-12-18
Anticipated expiration: 2026-12-13

Abstract

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. Disclosed is a method for facilitating a user profile exchange between one or more Rich Communication Services (RCS) clients at a first RCS client (302-1). First, a first user profile is created comprising attribute(s) associated with the first RCS client's user. Then, the first user profile is transmitted, to a profile server (304), using one or more Session Initiation Protocol (SIP) session procedures. Further, a unique profile identifier or a unique profile Uniform Resource Locator (URL) is received, from the profile server (304), corresponding to the first user profile in response to transmitting the first user profile. Moreover, the unique profile identifier or the unique profile URL is transmitted, to a second RCS client (302-2), via the one or more SIP session procedures. The unique profile identifier or the unique profile URL enables the second RCS client (302-2) to obtain the first user profile from the profile server (304).

Description

METHODS AND APPARATUSES FOR FACILITATING USER PROFILE EXCHANGE BETWEEN RICH COMMUNICATION SERVICES CLIENTS

The present invention generally relates to wireless communication systems, and more particularly, relates to methods and apparatuses for facilitating a user profile exchange between one or more Rich Communication Services (RCS) clients.

Fifth generation (5G) mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in “Sub 6 gigahertz (GHz)” bands such as 3.5GHz, but also in “Above 6GHz” bands referred to as millimeter wave (mmWave) including 28GHz and 39GHz. In addition, it has been considered to implement sixth generation (6G) mobile communication technologies (referred to as Beyond 5G systems) in terahertz (THz) bands (for example, 95GHz to 3THz bands) in order to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

At the beginning of the development of 5G mobile communication technologies, in order to support services and to satisfy performance requirements in connection with enhanced Mobile BroadBand (eMBB), Ultra Reliable Low Latency Communications (URLLC), and massive Machine-Type Communications (mMTC), there has been ongoing standardization regarding beamforming and massive multi input multi output (MIMO) for mitigating radio-wave path loss and increasing radio-wave transmission distances in mmWave, supporting numerologies (for example, operating multiple subcarrier spacings) for efficiently utilizing mmWave resources and dynamic operation of slot formats, initial access technologies for supporting multi-beam transmission and broadbands, definition and operation of BandWidth Part (BWP), new channel coding methods such as a Low Density Parity Check (LDPC) code for large amount of data transmission and a polar code for highly reliable transmission of control information, L2 pre-processing, and network slicing for providing a dedicated network specialized to a specific service.

Currently, there are ongoing discussions regarding improvement and performance enhancement of initial 5G mobile communication technologies in view of services to be supported by 5G mobile communication technologies, and there has been physical layer standardization regarding technologies such as Vehicle-to-everything (V2X) for aiding driving determination by autonomous vehicles based on information regarding positions and states of vehicles transmitted by the vehicles and for enhancing user convenience, New Radio Unlicensed (NR-U) aimed at system operations conforming to various regulation-related requirements in unlicensed bands, new radio (NR) user equipment (UE) Power Saving, Non-Terrestrial Network (NTN) which is UE-satellite direct communication for providing coverage in an area in which communication with terrestrial networks is unavailable, and positioning.

Moreover, there has been ongoing standardization in air interface architecture/protocol regarding technologies such as Industrial Internet of Things (IIoT) for supporting new services through interworking and convergence with other industries, Integrated Access and Backhaul (IAB) for providing a node for network service area expansion by supporting a wireless backhaul link and an access link in an integrated manner, mobility enhancement including conditional handover and Dual Active Protocol Stack (DAPS) handover, and two-step random access for simplifying random access procedures (2-step random access channel (RACH) for NR). There also has been ongoing standardization in system architecture/service regarding a 5G baseline architecture (for example, service based architecture or service based interface) for combining Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) technologies, and Mobile Edge Computing (MEC) for receiving services based on UE positions.

As 5G mobile communication systems are commercialized, connected devices that have been exponentially increasing will be connected to communication networks, and it is accordingly expected that enhanced functions and performances of 5G mobile communication systems and integrated operations of connected devices will be necessary. To this end, new research is scheduled in connection with eXtended Reality (XR) for efficiently supporting Augmented Reality (AR), Virtual Reality (VR), Mixed Reality (MR) and the like, 5G performance improvement and complexity reduction by utilizing Artificial Intelligence (AI) and Machine Learning (ML), AI service support, metaverse service support, and drone communication.

Furthermore, such development of 5G mobile communication systems will serve as a basis for developing not only new waveforms for providing coverage in terahertz bands of 6G mobile communication technologies, multi-antenna transmission technologies such as Full Dimensional MIMO (FD-MIMO), array antennas and large-scale antennas, metamaterial-based lenses and antennas for improving coverage of terahertz band signals, high-dimensional space multiplexing technology using Orbital Angular Momentum (OAM), and Reconfigurable Intelligent Surface (RIS), but also full-duplex technology for increasing frequency efficiency of 6G mobile communication technologies and improving system networks, AI-based communication technology for implementing system optimization by utilizing satellites and Artificial Intelligence (AI) from the design stage and internalizing end-to-end AI support functions, and next-generation distributed computing technology for implementing services at levels of complexity exceeding the limit of UE operation capability by utilizing ultra-high-performance communication and computing resources.

Rich Communication Services (RCS) is a communication protocol standard designed to enhance traditional Short Message Service (SMS) by offering a range of advanced messaging capabilities over Internet Protocol (IP) networks. The RCS introduces several features that go beyond the capabilities of SMS, such as real-time typing indicators, read receipts, high-resolution photo and video sharing, group messaging, location sharing, and interactive media experiences. Such features contribute to a more dynamic and engaging communication experience.

However, despite many advantages, the conventional RCS messaging services lack support for exchanging basic user profile details, such as user’s profile picture, name, status message, and location. The exchange of user profile information has become a fundamental aspect of modern messaging services. There are various over-the-top (OTT) messaging applications which offer this functionality. These applications allow users to share profile information such as their profile picture, name, status message, and last seen status, providing a richer and more personalized messaging experience. In contrast, RCS messaging currently does not support the user profile exchange feature, thereby affecting the overall user experience.

Therefore, there exists a need for improved methods and devices to overcome the above-mentioned limitations.

An objective of the present disclosure is to provide methods and apparatuses for facilitating a user profile exchange between one or more RCS clients.

This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.

According to an embodiment of the present disclosure, a method for facilitating a user profile exchange between one or more Rich Communication Services (RCS) clients at a first RCS client is disclosed. The method includes creating a first user profile comprising one or more attributes associated with a user of the first RCS client. The method also includes transmitting, to a profile server, the first user profile using one or more communication protocols within one or more Session Initiation Protocol (SIP) session procedures. The one or more SIP session procedures comprise at least one of an SIP header procedure, a content body procedure, and a capability discovery procedure. Further, the method includes receiving, from the profile server, at least one of a unique profile identifier or a unique profile Uniform Resource Locator (URL) corresponding to the first user profile in response to transmitting the first user profile. Moreover, the method includes transmitting, to a second RCS client, at least one of the unique profile identifier or the unique profile URL via the one or more SIP session procedures. The unique profile identifier enables the second RCS client to obtain the first user profile from the profile server.

According to another embodiment of the present disclosure, a method for facilitating a user profile exchange between one or more Rich Communication Services (RCS) clients at a profile server is disclosed. The method includes receiving, from a first RCS client, a first user profile using one or more communication protocols within one or more Session Initiation Protocol (SIP) session procedures. The first user profile comprises one or more attributes associated with a user of the first RCS client. The method also includes transmitting, to the first RCS client, at least one of a unique profile identifier or a unique profile Uniform Resource Locator (URL) corresponding to the first user profile in response to receiving the first user profile. Further, the method includes receiving, from a second RCS client, a profile data request using the one or more SIP session procedures. The profile data request comprises at least one of the unique profile identifier or the unique profile URL corresponding to the first user profile. Moreover, the method includes transmitting, to the second RCS client, the first user profile based on at least one of the unique profile identifier or the unique profile URL in response to receiving the profile data request.

According to yet another embodiment of the present disclosure, a Rich Communication Services (RCS) client for facilitating a user profile exchange between one or more RCS clients is disclosed. The RCS client includes a memory, and at least one processor communicatively coupled to the memory. The at least one processor is configured to create a first user profile comprising one or more attributes associated with a user of the first RCS client. The at least one processor is also configured to transmit, to a profile server, the first user profile using one or more communication protocols within one or more Session Initiation Protocol (SIP) session procedures. The one or more SIP session procedures comprise at least one of an SIP header procedure, a content body procedure, and a capability discovery procedure. The at least one processor is further configured to receive, from the profile server, at least one of a unique profile identifier or a unique profile Uniform Resource Locator (URL) corresponding to the first user profile in response to transmitting the first user profile. Moreover, the at least one processor is configured to transmit, to a second RCS client, at least one of the unique profile identifier or the unique profile URL via the one or more SIP session procedures. The unique profile identifier or the unique profile URL enables the second RCS client to obtain the first user profile from the profile server.

According to yet another embodiment of the present disclosure, a profile server for facilitating a user profile exchange between one or more Rich Communication Services (RCS) clients is disclosed. The profile server includes a memory, and at least one processor communicatively coupled to the memory. The at least one processor is configured to receive, from a first RCS client, a first user profile using one or more communication protocols within one or more Session Initiation Protocol (SIP) session procedures. The first user profile comprises one or more attributes associated with a user of the first RCS client. The at least one processor is also configured to transmit, to the first RCS client, at least one of a unique profile identifier or a unique profile Uniform Resource Locator (URL) corresponding to the first user profile in response to receiving the first user profile. The at least one processor is further configured to receive, from a second RCS client, a profile data request using the one or more SIP session procedures. The profile data request comprises at least one of the unique profile identifier or the unique profile URL corresponding to the first user profile. Moreover, the at least one processor is configured to transmit, to the second RCS client, the first user profile based on at least one of the unique profile identifier or the unique profile URL in response to receiving the profile data request.

To further clarify the advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings.

According to the present disclosure, it is possible to facilitate a user profile exchange between one or more RCS clients.

As a result, interoperability between RCS clients can be improved, and user experience can be enhanced through seamless profile sharing.

These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:

Figure 1A illustrates an example implementation of an over-the-top (OTT) messaging application supporting user profile exchange;

Figure 1B illustrates an example implementation of a Rich Communication Services (RCS) messaging service;

Figure 2 illustrates a sequence flow diagram depicting a first RCS client viewing contact information of a second RCS client;

Figure 3 illustrates an example environment for facilitating the user profile exchange between the one or more RCS clients, in accordance with an embodiment of the present disclosure;

Figure 4 illustrates a sequence flow diagram depicting a method for facilitating the user profile exchange between the one or more RCS clients, in accordance with an embodiment of the present disclosure;

Figure 5 illustrates a sequence flow diagram depicting a method for sharing the user profile information between the one or more RCS clients, in accordance with an embodiment of the present disclosure;

Figure 6 illustrates a sequence flow diagram depicting a method for generating a unique profile Uniform Resource Locator (URL) of the first RCS client by the second RCS client, in accordance with an embodiment of the present disclosure;

Figure 7 illustrates a sequence flow diagram depicting a method for initial profile picture synchronization, in accordance with an embodiment of the present disclosure;

Figure 8 illustrates a sequence flow diagram depicting a method for the initial profile picture synchronization, in accordance with another embodiment of the present disclosure;

Figure 9 illustrates a sequence flow diagram depicting a method for the initial profile picture synchronization, in accordance with yet another embodiment of the present disclosure;

Figure 10 illustrates a flowchart depicting a method for facilitating the user profile exchange between the one or more RCS clients at the first RCS client, in accordance with an embodiment of the present disclosure;

Figure 11 illustrates a flowchart depicting a method for facilitating the user profile exchange between the one or more RCS clients at the profile server, in accordance with an embodiment of the present disclosure;

Figure 12 illustrates an example block diagram of the RCS client, in accordance with an embodiment of the present disclosure; and

Figure 13 illustrates an example block diagram of the profile server, in accordance with an embodiment of the present disclosure.

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the various embodiments and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.

It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.

Whether or not a certain feature or element was limited to being used only once, it may still be referred to as “one or more features” or “one or more elements” or “at least one feature” or “at least one element.” Furthermore, the use of the terms “one or more” or “at least one” feature or element do not preclude there being none of that feature or element, unless otherwise specified by limiting language including, but not limited to, “there needs to be one or more…” or “one or more elements is required.”

Reference is made herein to some “embodiments.” It should be understood that an embodiment is an example of a possible implementation of any features and/or elements of the present disclosure. Some embodiments have been described for the purpose of explaining one or more of the potential ways in which the specific features and/or elements of the proposed disclosure fulfil the requirements of uniqueness, utility, and non-obviousness.

Use of the phrases and/or terms including, but not limited to, “a first embodiment,” “a further embodiment,” “an alternate embodiment,” “one embodiment,” “an embodiment,” “multiple embodiments,” “some embodiments,” “other embodiments,” “further embodiment”, “furthermore embodiment”, “additional embodiment” or other variants thereof do not necessarily refer to the same embodiments. Unless otherwise specified, one or more particular features and/or elements described in connection with one or more embodiments may be found in one embodiment, or may be found in more than one embodiment, or may be found in all embodiments, or may be found in no embodiments. Although one or more features and/or elements may be described herein in the context of only a single embodiment, or in the context of more than one embodiment, or in the context of all embodiments, the features and/or elements may instead be provided separately or in any appropriate combination or not at all. Conversely, any features and/or elements described in the context of separate embodiments may alternatively be realized as existing together in the context of a single embodiment.

Any particular and all details set forth herein are used in the context of some embodiments and therefore should not necessarily be taken as limiting factors to the proposed disclosure.

The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by “comprises... a” does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

Figure 1A illustrates an example implementation 100 of an OTT messaging application supporting user profile exchange. As shown in Figure 1A, a User Interface (UI) 102a displayed on a user equipment of a user ‘A’ may include contact details of a user ‘B’ on the user equipment of the user ‘A’. The users ‘A’ and ‘B’ may be in conversation using the OTT messaging application supporting the user profile exchange. Furthermore, the UI 102a includes several fields such as a profile picture field 104 displaying a profile picture assigned to the user ‘B’, a username field 106 displaying the name of the user ‘B’ (e.g., Amulya), and a contact number field 108 displaying the contact number of the user ‘B’. A UI 102b displayed on the user equipment of the user ‘A’ may correspond to a UI of a messaging application installed on the user equipment of the user ‘A’. The messaging application may be the OTT messaging application supporting the user profile exchange. Therefore, as indicated in area 110 of the UI 102b, the messaging application displays the profile picture of the user ‘B’ (e.g., Amulya).

Figure 1B illustrates an example implementation 120 of an RCS messaging service. As shown in Figure 1B, a UI 122a may display contact details of a user ‘B’ on a user equipment of a user ‘A’. The users ‘A’ and ‘B’ may be RCS users and in conversation using RCS-based messaging. The UI 122a includes several fields such as a profile picture field 124 displaying a profile picture assigned to the user ‘B’, a username field 126 displaying the name of the user ‘B’ (e.g., Amulya), and a contact number field 128 displaying the contact number of the user ‘B’. A UI 122b displayed on the user equipment of the user ‘A’ may correspond to a UI of an RCS messaging application. As indicated in area 130 of the screen 122b, the information (e.g., the profile picture) of the RCS user ‘B’ is not visible to the RCS user ‘A’. This is because, the conventional RCS protocol does not define a standard mechanism or flow for transmitting or exchanging user profile information such as profile pictures, usernames, status messages, location data, or other personal identifiers between the RCS users. As a result, RCS-based messaging experiences lack personalization that is widely supported in modern OTT messaging platforms.

Figure 2 illustrates a sequence flow diagram 200 depicting a first Rich Communication Services (RCS) client (i.e., a User Equipment (UE)-1 202-1) viewing contact information of a second RCS client (i.e., a UE-2 202-2). The sequence flow diagram 200 illustrates a sequence of operations between the first RCS client 202-1 and the second RCS client 202-2. In an embodiment, the RCS clients 202-1 and 202-2 may correspond to RCS communication clients. Further, the RCS clients 202-1 and 202-2 may correspond to UEs capable of supporting one or more RCS features including, but not limited to, rich messaging, file transfer, group chat, and audio and video messaging. Examples of RCS clients 202-1 and 202-2 may include, but are not limited to, smartphones, tablets, personal computers, laptop computers, and Internet-of-Things (IoT) enabled devices.

At operation 204, the UE-1 202-1 opens the UE-2’s contact. For example, a user of the UE-1 202-1 may select the contact of the user of the UE-2 202-2 on the UE-1 202-1. This may trigger a capability discovery procedure. In RCS, the capability discovery procedure may refer to a mechanism to determine the one or more RCS features supported by the RCS clients. This is achieved using Session Initiation Protocol (SIP) OPTIONS messages (including SIP headers and an optional content body).

The SIP headers play a crucial role in routing, handling, and processing SIP requests and responses. The SIP headers may include parameters and properties of SIP messages. For example, a “Call-Info” header may provide additional metadata related to a call or a session, such as links to relevant web pages, documents, or other resources. The structure of the “Call-Info” header may include a Uniform Resource Identifier (URI), which may be a Uniform Resource Locator (URL) or another type of resource related to the call, and optional parameters that offer additional context or information. In addition to the SIP headers, the SIP messages may contain the content body, which carries an actual payload of the message. The payload may include media descriptions, authorization credentials, or application-specific data. For example, a SIP REGISTER message may include authentication credentials in the content body, while a SIP MESSAGE request may carry plain text user messages. The content body is formatted using Session Description Protocol (SDP), which describes media session details. Further, depending on type of data being exchanged and specific requirements of the message, different content-encoding formats may be used. Examples of the content-encoding formats may include ‘application/sdp’ for SDP data in SIP INVITE messages, ‘text/plain’ for plain text messages, ‘text/xml’ for structured eXtensible Markup Language (XML)-based data in SIP NOTIFY messages, ‘multipart/mixed’ for multiple content types in a single message such as in REFER requests, and ‘application/json’ for Javascript Object Notation (JSON) data in custom SIP headers. Additionally, for enhanced service usability, the RCS may implement a capability discovery mechanism, allowing users to identify which RCS features are accessible by corresponding contacts at a given time. According to RCC.71 and RCC.07 specifications, this is achieved by two main methods - SIP OPTIONS exchange and presence-based discovery. The SIP OPTIONS method may involve an end-to-end message that queries and shares service capabilities between the users, often requiring an Options Application Server (Options-AS) to support multiple devices and optimize performance. The Presence-based method, as defined by the Open Mobile Alliance (OMA) SIMPLE Presence standards, queries a centralized server for user capabilities. This approach typically requires a Presence Server and optionally an XML Document Management (XDM) Server to manage presence information effectively.

At operation 206, the UE-1 202-1 and UE-2 202-2 may perform SIP OPTIONS based capability discovery. For example, the UE-1 202-1 attempts to discover capabilities (or, supported one or more RCS features) of the UE-2 202-2 using the SIP OPTIONS. At operation 208, the UE-1 202-1 transmits a SIP OPTIONS request message to the UE-2 202-2 for querying the UE-2’s 202-2 capability information. At operation 210, the UE-2 202-2 transmits a 200 OK response message to the UE-1 202-1 in response to the SIP OPTIONS request message. The response message may include the capability information of the UE-2 202-2 indicating the supported one or more RCS features. At 212, the UE-1 202-1 concludes that UE-2’s profile (i.e., profile information of the user of the UE-2 202-2) is not visible. This may occur because the current SIP OPTIONS mechanism does not support the exchange of the user profile information.

Additionally, the current SIP based methods face several additional challenges. For instance, the presence-based approach in SIP involves significant deployment complexity, as implementing SIP PRESENCE requires additional infrastructure components such as presence servers and XDM servers, which increases both system complexity and operational costs. Furthermore, operator support for SIP PRESENCE is limited, with many network operators lacking native support, thereby restricting the widespread use of presence-based user profile information exchange. Additionally, a SIP PUBLISH method, which is intended for capability queries, is not universally supported across operators, further constraining its practical utility. There are also privacy concerns, as current mechanisms do not allow users to selectively share private versus public profile information (such as controlling visibility of profile pictures), which may potentially expose sensitive data. Furthermore, the absence of effective user profile synchronization across multiple devices results in inconsistencies and limits the availability of accurate profile information on secondary user devices.

As explained above, conventional techniques do not have any provision to exchange RCS users profile information. Further, using the presence-based methods is costlier in terms of server infrastructure and every operator does not support capability exchange using presence. To address the above-mentioned challenges, there is a need for a client-side solution that extends the SIP OPTIONS message to support the exchange of user profile information.

The present disclosure provides a solution to the above-mentioned problem(s). The present disclosure relates to techniques for sharing user profile information in an IP Multimedia Subsystem (IMS). Particularly, the present disclosure related to methods and apparatuses for facilitating a user profile exchange between one or more rich communication services (RCS) clients. The present disclosure includes sharing real-time user profile information using the SIP OPTIONS message. The present disclosure provides a mechanism for user profile information exchange among one or more RCS users using the SIP OPTIONS message and with the usage of Presence Information Data Format (PIDF) inside the SIP OPTIONS message. Embodiments of the present disclosure are explained in detail in the forthcoming paragraphs.

Figure 3 illustrates an example environment 300 for facilitating the user profile exchange between the one or more RCS clients, in accordance with an embodiment of the present disclosure.

In an embodiment, the environment 300 may include a first RCS client (RCS Client-1) 302-1 and a second RCS client (RCS Client-2) 302-2 (collectively referred to as the “RCS client” 302). The first RCS client 302-1 and the second RCS client 302-2 may correspond to the UE-1 202-1 and the UE-2 202-2 respectively. The environment 300 may also include a profile server 304. The profile server 304 may refer to a server device responsible for managing and storing user profile information associated with the RCS clients 302. Examples of the profile server may include, but are not limited to, a HyperText Transfer Protocol (HTTP) content server, and an options application server. The profile server 304 may also maintain a plurality of user profiles, corresponding access levels, and processes associated with the RCS clients. In an embodiment, the profile server 304 may include a profile controller configured to maintain a plurality of user profiles based on the access levels associated with each of the user profiles, as explained in detail in the forthcoming paragraphs.

As shown in Figure 3, the first RCS client 302-1 may upload a user profile (also referred to as a “first user profile”) associated with a user of the first RCS client 302-1 at the profile server 304, as explained in detail in the forthcoming paragraphs. The user profile may include one or more attributes associated with the user of the first RCS client 302-1. The one or more attributes may include a profile picture, a name, a status message, a location, one or more preferred links, a last available timestamp, a configuration access level, and a profile change timestamp associated with the user of the first RCS client 302-1. The one or more attributes may allow RCS users to convey corresponding availability status, provide a visual representation, share textual information, disclose location, and link to relevant websites, all of which are updated and managed through the RCS client. The user profile may be one of a new user profile or an updated user profile. The last available timestamp may refer to the last time at which the RCS client was available on an RCS network.

In an embodiment, the configuration access level may refer to the accessibility of the user profile information. Examples of the configuration access level may include, but is not limited to, ‘everyone’, ‘all contacts’, ‘selected contacts’, and ‘no one’. For the configuration access level ‘everyone’, the user profile information may be visible to everyone irrespective of whether a contact of a user viewing the user profile information is saved on the RCS client. For the configuration access level ‘all contacts’, the user profile information may be visible to all saved contacts only. For the configuration access level ‘selected contacts’, the user profile information may be visible to user-selected contacts only. Further, for the configuration access level ‘no one’, the user profile information may not be visible to anyone. In an embodiment, whenever there is a change in the configuration access levels (e.g., changing from ‘everyone’ to ‘selected contacts’), a last shared user profile information may be maintained at the first RCS client until a next profile exchange occurs from the first RCS client. This approach may be referred to as lazy propagation. Alternatively, the first RCS client may maintain a list of contacts with whom the user profile has been exchanged and may trigger a profile exchange (either through OPTIONS, Publish/Notify, or SIP header/content body) to ensure fast propagation.

In an embodiment, the profile change timestamp may refer to the last time when the user profile was modified. Additionally, the profile change timestamp may indicate whether the user profile information is an updated profile information or same as previous profile information. The profile change timestamp may help in avoiding querying the user profile information (e.g., the profile picture) from the server again and again. The one or more RCS clients may download the profile picture from the profile server 304 based on the profile change timestamp. Each RCS client may be capable of locally storing up-to-date user profile information for all of user’s RCS contacts. The user profile information may be requested from the profile server/other RCS client whenever there is a change in the contact book (e.g., adding a new contact), or when the user opens a specific contact from the contact list, or when the user initiates a conversation with a particular contact, or when the user opens a conversation or thread with a specific contact. This ensures that the RCS client maintains the latest user profile information for all contacts, enabling the user to access accurate and up-to-date details about corresponding RCS contacts, such as availability status, profile picture, and other relevant information, as and when required.

It should be noted that although Figure 3 illustrates only the first RCS client 302-1 uploading the user profile at the profile server 304, the second RCS client 302-2 may also upload the user profile associated with a user of the second RCS client 302-2 at the profile server 304. The first RCS client 302-1 may also download the user profile associated with users of other RCS clients (e.g., the second RCS client 302-2) from the profile server 304.

In an embodiment, the first RCS client 302-1 and the second RCS client 302-2 may also exchange the user profile among themselves through one or more communication protocols within one or more SIP session procedures, as discussed in detail in conjunction with Figures 4-11 in the forthcoming paragraphs. The one or more SIP session procedures may include at least one of an SIP header procedure, a content body procedure, and a capability discovery procedure such as the SIP OPTIONS or Publish/Notify message, which may be triggered in a manner defined in section 3 of RCC 71 specification. Further, the one or more communication protocols may include an SIP, a Hypertext Transfer Protocol (HTTP), and a Message Session Relay Protocol (MSRP).

In an embodiment, the one or more RCS clients may utilize the one or more SIP session procedures without requiring the user profile information to revoke any previously shared user profile information.

Figure 4 illustrates a sequence flow diagram depicting a method 400 for facilitating the user profile exchange between the one or more RCS clients, in accordance with an embodiment of the present disclosure. The sequence flow diagram of Figure 4 illustrates a sequence of operations between the first RCS client (also referred to as “UE-1”) 302-1, the second RCS client (also referred to as “UE-2”) 302-2, and the profile server 304.

At operation 402, the user profile (i.e., the first user profile) associated with the user of the UE-1 302-1 may be created at the UE-1 302-1. In an embodiment, creating the user profile may include defining one or more SIP parameters corresponding to each of the one or more attributes (e.g., the profile picture, the name (also referred to as the “profile name”), the status message, the location, the one or more preferred links, the last available timestamp, the configuration access level, and the profile change timestamp). The one or more SIP parameters may be used for sharing the one or more attributes of the user profile with other RCS clients. For example, for sharing the profile name, an SIP parameter ‘profile-name’ may be defined. Similarly, other SIP parameters ‘profile-image’, ‘profile-location’, ‘profile-status’, ‘profile-timestamp’, and ‘profile-weblink’ may be defined for sharing the profile picture, the location, the status message, the last available timestamp, and the one or more preferred links, respectively. In an embodiment, at operation 402, either the new user profile may be created, or an existing user profile may be updated at the UE-1 302-1. For example, updating the existing user profile may include updating the profile picture, or updating the status message, etc. The profile change timestamp may be associated with the updated user profile.

At operation 404, the UE-1 302-1 may transmit the created/updated user profile to the profile server 304. The UE-1 302-1 may transmit the created/updated user profile to the profile server 304 using the one or more communication protocols within the one or more SIP session procedures. In an embodiment, for transmitting the user profile to the profile server 304, the UE-1 302-1 may encapsulate the user profile within an SIP message using the one or more SIP parameters. For example, the UE-1 302-1 may encapsulate the one or more attributes within the corresponding SIP parameter. Thereafter, the UE-1 302-1 may transmit the user profile to the profile server 304 via the SIP message.

In an embodiment, the UE-1 302-1 may transmit the one or more attributes to the profile server 304 using one or more SIP headers. The one or more SIP headers may include a ‘Call-Info’ header, an ‘Alert-Info’ header, and a ‘User-Info’ header. In another embodiment, the UE-1 302-1 may transmit the one or more attributes to the profile server 304 in the content body of the one or more SIP messages based on the one or more content-encoding formats (e.g., ‘application/sdp’, ‘text/plain’, ‘text/xml’, ‘multipart/mixed’, and ‘application/json’). The one or more content-encoding formats may be selected based on one of a type of data associated with each of the one or more attributes or a type of the one or more communication protocols. For example, the one or more content-encoding formats selected based on the type of the one or more communication protocols may include a Session Description Protocol (SDP), a Common Profile for Instant Messaging (CPIM) protocol, the XML, the JSON, and the TEXT. In yet another embodiment, the UE-1 302-1 may transmit the one or more attributes to the profile server 304 in one of the SIP OPTIONS message using a multipart SDP content body and an SIP Publish message using an XML tag. In a further embodiment, the UE-1 302-1 may transmit the one or more attributes to the profile server 304 in a content body of one or more CPIM messages.

At operation 406, the UE-1 302-1 may receive a 200 OK response message from the profile server 304 in response to transmitting the created/updated user profile. The response message may include at least one of a unique profile identifier or a unique profile URL corresponding to the transmitted user profile. Throughout the disclosure, the terms “unique profile identifier” and the term “unique profile URL” are interchangeably referred to as a “Profile ID” and a “Profile URL” respectively, and imply a similar meaning. In the context of the UE-1, the received unique profile URL and the unique profile identifier may also be referred to as “UE-1 Profile URL” and “UE-1 Profile ID” respectively. The unique profile identifier may represent a key for accessing the complete user profile of a particular user. Further, the unique profile URL may be a path for accessing the complete user profile. The profile server 304 (specifically, the profile controller) may be configured to maintain the user profile, the corresponding access levels, and the processes associated with a particular RCS client using at least one of the unique profile identifier or the unique profile ID associated with that RCS client. In an embodiment, the UE-1 302-1 may define an SIP parameter ‘profile-id’ for sharing the unique profile identifier with other RCS clients, as discussed in detail in the forthcoming paragraphs. Further, the SIP parameter ‘profile-id’ may be categorized as ‘profile-id-xxx’, where the ‘xxx’ represents a specific category of the user profile, such as private, public, family, work, etc., depending on the configuration access level associated with the user profile. For example, for a public user profile, the SIP parameter may be ‘profile-id-pub’, and for a private user profile, the SIP parameter may be ‘profile-id-priv’, and so on. Particularly, the ‘profile-id’ may represent the user profile information of a particular RCS client at the profile server 304. The ‘profile-id-pub’ represents a public representation of the user profile information for a particular RCS client. The ‘profile-id-priv’ represents a private representation of the user profile information for a particular RCS client. Further, ‘profile-id-work’ represents profile information of a work profile of a particular RCS client, and so on. Furthermore, the profile URL may be categorized as ‘profile-url-xxx’, where the ‘xxx’ represents a specific category of the user profile, such as private, public, family, office, etc., depending on the associated configuration access level. For example, ‘profile-url’ may represent a URL for a default or public profile available to all users, ‘profile-url-priv’ may represent a URL corresponding to a private user profile, and ‘profile-url-ofc’ may represent a URL for a work profile which may be accessible only to office contacts within a particular RCS client, and so on.

At operation 408, the user profile (i.e., a second user profile) associated with the user of the UE-2 302-2 may be created at the UE-2 302-2. At operation 410, the UE-2 302-2 may transmit the user profile to the profile server 304. At operation 412, the UE-2 302-2 may receive the 200 OK response message from the profile server 304 in response to transmitting the user profile. The 200 OK response message may include at least one of another unique profile identifier or another unique profile URL corresponding to the second user profile. In the context of the UE-2, the received another unique profile URL and the unique profile identifier may also be referred to as "UE-2 Profile URL" and "UE-2 Profile ID" respectively. The operations 408-412 may be similar to the operations 402-406 and therefore are not described in detail again for the sake of brevity. Additionally, operations 414-416 may be similar to the operations 204-206 of Figure 2, and therefore are not described in detail again for the sake of brevity.

At operation 418, the UE-1 302-1 may transmit the SIP OPTIONS message with 'Call-info' header containing the UE-1 Profile URL or the UE-1 Profile ID to the UE-2 302-2. The UE-1 302-1 may also utilize another SIP session procedure (such as the content body procedure or piggyback with the capability discovery procedure) for transmitting the UE-1 Profile URL or the UE-1 Profile ID to the UE-2 302-2. The UE-1 Profile URL or the UE-1 Profile ID may enable the UE-2 302-2 to obtain the first user profile from the profile server 304.

In an embodiment, user profile information such as the Profile ID, Profile URL, and one or more attributes may be transmitted to the UE-2 302-2 using the one or more SIP headers. The one or more SIP headers may include standard headers such as 'Call-Info' and 'Alert-Info'. Alternatively, a profile-specific header, such as 'User-Info', may be defined to carry the user profile information. The Profile URL included in the one or more SIP headers may be either a plain-text URL or a hashed URL for added privacy and security. The user profile information may be piggybacked onto the SIP OPTIONS message, as shown in an example SIP OPTIONS message below.

In another embodiment, the user profile information may be transmitted to the UE-2 302-2 within the content body of the SIP message. A format and a structure of the content body may be determined based on specific content encoding, such as in the SIP MESSAGE content body or an RCS CPIM message. Depending on the type of the user profile information being exchanged, the content body may be formatted using the one or more content-encoding formats (e.g., 'application/sdp', 'text/plain', 'text/xml', 'multipart/mixed', and 'application/json'). For instance, an XML-based user profile information may be shared using a format such as xxx.rcs-profile+xml. As an example of transmitting the user profile information as part of the content body is provided below.

In yet another embodiment, the user profile information may be transmitted using the multipart SDP content body within the SIP message. For example, the user profile information may be piggybacked with the SIP OPTIONS message as the multipart SDP content body, as shown in an example below.

At operation 420, the UE-2 302-2 may transmit a profile data request to the profile server 304 for obtaining the first user profile (i.e., UE-1 profile). The profile data request may include the UE-1 Profile ID or the UE-1 Profile URL transmitted to the UE-2 302-2 by the UE-1 302-1 in operation 418. In an embodiment, the UE-2 302-2 may transmit the profile data request to the profile server 304 using the one or more SIP session procedures, as discussed above. At operation 422, the UE-2 302-2 may receive a 200 OK response message from the profile server 304 in response to the profile data request. The response message may include the first user profile. Consequently, at operation 424, the UE-2 302-2 may be able to view the first user profile.

At operation 426, the UE-2 302-2 may transmit a 200 OK response message with the ‘Call-Info’ header containing the UE-2 Profile URL or the UE-2 Profile-ID to the UE-1 302-1. The UE-2 302-2 may also utilize another SIP session procedure (such as the content body procedure or piggyback with the capability discovery procedure) for transmitting the UE-2 Profile URL or the UE-2 Profile ID to the UE-1 302-1, as discussed above. The UE-2 Profile URL or the UE-2 Profile ID may enable the UE-1 302-1 to obtain the second user profile from the profile server 304. The operations 428-432 may be similar to operations 420-424 and therefore are not described in detail again for the sake of brevity. The method 400 enables the user profile exchange between the one or more RCS clients, thereby enhancing interoperability, enabling richer communication experiences, and ensuring consistent profile visibility across different RCS devices.

Figure 5 illustrates a sequence flow diagram depicting a method 500 for sharing the user profile information between the one or more RCS clients, in accordance with an embodiment of the present disclosure. The method 500 may utilize the SIP OPTIONS and SIP PUBLISH messages, along with introduction of one or more profile header extensions. The method 500 may include a sequence of operations between the first RCS client (also referred to as the “UE-1”) 302-1, the second RCS client (also referred to as the “UE-2”) 302-2, and the profile server 304.

At operation 502, the UE-1 302-1 may transmit a message including the one or more attributes and profile picture information to the profile server 304. At operation 504, the UE-1 302-1 may receive a 200 OK acknowledgment message from the profile server 304 in response to the message transmitted in operation 502. The operations 506-508 may be similar to 502-504 and therefore are not described in detail again for the sake of brevity. For exchanging the profile picture information, the RCS client may embed a picture URL in the SIP OPTIONS message. In this case, the URL may include new headers, such as “p-profile info” or “p-asserted identity” with additional profile attributes. At operation 510, the UE-2 302-2 may add the contact information of the UE-1 302-1. At operation 512, the UE-2 302-2 may transmit the SIP OPTIONS/PUBLISH message with the UE-2 Profile URL (or UE-2 Profile content URI) to the UE-1 302-1. At operation 514, the UE-1 302-1 may transmit a 200 OK OPTIONS or a NOTIFY message containing the UE-1 Profile URL (or, UE-1 Profile content URI) to the UE-2 302-2.

Figure 6 illustrates a sequence flow diagram depicting a method 600 for generating the unique profile URL of the first RCS client (UE-1) 702-1 by the second RCS client (UE-2) 702-2, in accordance with an embodiment of the present disclosure. The method 600 may include a sequence of operations between the first RCS client (also referred to as the “UE-1”) 302-1, the second RCS client (also referred to as the “UE-2”) 302-2, the profile server 304, and the profile controller 602. In an embodiment, the method 600 may enable a remote party (e.g., the UE-2 302-2) to generate a Fully Qualified Domain Name (FQDN) for the UE-1 Profile URL, leveraging configuration parameters and procedures defined in RCC 07 specification.

At operation 604, the UE-1 302-1 may transmit a message containing the one or more profile attributes and the profile picture information to the profile controller 602 using a file transfer (FT) procedure. At operation 606, the profile controller 602 may transmit the user profile information (or, profile content) to the profile server 304. At operation 608, the profile controller 602 may receive a 200 OK acknowledgment message from the profile server 304 in response to transmitting the user profile information. At operation 610, the UE-2 302-2 may add contact details of the UE-1 302-1. At operation 612, the UE-2 302-2 may generate the UE-1 Profile URL. At operation 614, the UE-2 302-2 may transmit a get profile message (i.e., the profile data request) to the profile controller 602. At operation 616, the profile controller 602 may authorize the UE-2 302-2 to obtain the UE-1 profile, provided such access is allowed by the UE-1 302-1. For example, the profile controller 602 may authorize the UE-2 302-2 to obtain the UE-1 profile based on access level permissions configured by the user of the UE-1 (i.e., the user whose profile is being accessed). If such access is not allowed by the UE-1 302-1, the profile controller 602 may block the profile data request. At operation 618, the profile controller 602 transmits a 200 OK acknowledgment message to the UE-2 302-2. The acknowledgement message may include the first user profile.

Through the method 600, the one or more RCS clients may be enabled to access the user profile information of their contacts by independently generating the corresponding Profile URL. The generated Profile URL may point to a folder or resource including all relevant user profile information.

Figure 7 illustrates a sequence flow diagram depicting a method 700 for initial profile picture synchronization, in accordance with an embodiment of the present disclosure. The method 700 may include a sequence of operations between the first RCS client (also referred to as the “UE-1”) 702-1, the second RCS client (also referred to as the “UE-2”) 702-2, an options application server 704, and a HTTP content server 706.

At operation 710, the user of the UE-1 702-1 may change the profile picture. At operation 712, upon detecting a change in the profile picture, the UE-1 702-1 may transmit a POST request including the updated profile picture information to the HTTP content server 706. At operation 714, the UE-1 702-1 may receive a 200 OK acknowledgment message from the HTTP content server 706 in response to transmitting the POST request. The acknowledgement message may include a profile picture URL corresponding to the updated profile picture. At operation 716, the UE-1 702-1 may save the profile picture URL along with file expiry information. Operations 718-724 may be similar to the operations 710-716 and therefore are not described in detail again for the sake of brevity.

At operation 726, the UE-2 702-2 may add or update contact information of the UE-1 702-1. At operation 728, the UE-2 702-2 may transmit an OPTIONS request with the UE-2 Profile to the UE-1 702-1. At operation 730, the UE-1 702-1 may transmit a 200 OK acknowledgment message to the UE-2 702-2 in response to receiving the UE-2 Profile. The acknowledgement message may be without the profile picture URL corresponding to the UE-1 702-1. At operation 732, the UE-1 702-1 may add or update the contact information of the UE-2 702-2. At operation 734, the UE-1 702-1 may send the OPTIONS request with the UE-1 Profile to the UE-2 702-2. During the operation 734, the profile picture of the UE-1 702-1 may not have expired at the HTTP content server 706. At operation 736, the UE-2 702-2 may transmit a 200 OK acknowledgment message to the UE-1 702-1 in response to receiving the UE-1 Profile. The acknowledgment message may include the profile picture URL corresponding to the UE-2 702-2. At operations 738-740, the UE-2 702-2 may retrieve the UE-1 profile picture information from the HTTP content server 706. Further, at operations 742-744, the UE-1 702-1 may retrieve the UE-2 profile picture information from the HTTP content server 706. The method 700 describes mutual exchange of the user profile information, including the profile picture URLs, between the UE-2 702-2 and the UE-1 702-1. The UE-2 702-2 may first request the UE-1 Profile, followed by the UE-1 702-1 requesting the UE-2 profile, with both RCS clients retrieving the respective profile picture information from the HTTP content server 706.

Figure 8 illustrates a sequence flow diagram depicting a method 800 for the initial profile picture synchronization, in accordance with another embodiment of the present disclosure. The method 800 may include a sequence of operations between the first RCS client (also referred to as the “UE-1”) 702-1, the second RCS client (also referred to as the “UE-2”) 702-2, the options application server 704, and the HTTP content server 706.

The method 800 may begin at operation 802, where the UE-1 and the UE-2 profile pictures may be uploaded and available at the HTTP content server 706. At operation 804, the UE-2 702-2 may add or update the contact information of the UE-1 702-1. At operation 806, the UE-2 702-2 may transmit the OPTIONS request to the UE-1 702-1 with the UE-2 profile. At operation 808, the UE-1 702-1 may transmit a 200 OK acknowledgment message to the UE-2 in response to the OPTIONS request. The acknowledgement message may not include the UE-1 profile. At operation 810, the UE-1 702-1 may add or update the contact information of the UE-2 702-2. At operation 812, the UE-1 702-1 may transmit the OPTIONS request to the UE-2 702-2 with the UE-1 profile. At operation 814, it may be determined that the UE-2 profile picture file has expired at the HTTP content server 706. At operation 816, the UE-2 702-2 may upload a new profile picture at the HTTP content server 706. At operation 818, the UE-2 702-2 may receive a 200 OK acknowledgment message from the HTTP content server 706 in response to uploading the new profile picture. At operation 820, the UE-2 702-2 may save the new profile picture URL with the file expiry information. At operation 822, the UE-2 702-2 may transmit a 200 OK acknowledgment message to the UE-1 702-2. The acknowledgement message may include the new profile picture URL corresponding to the UE-2 702-2.

Figure 9 illustrates a sequence flow diagram depicting a method 900 for the initial profile picture synchronization, in accordance with yet another embodiment of the present disclosure. The method 900 may include a sequence of operations between the first RCS client (also referred to as the “UE-1”) 702-1, the second RCS client (also referred to as the “UE-2”) 702-2, the options application server 704, and the HTTP content server 706.

The method 900 may begin at operation 902, where the UE-1 and the UE-2 profile pictures may be uploaded and available at the HTTP content server 706. At operation 904, the UE-1 702-1 may change an existing profile picture. At operation 906, in response to changing the existing profile picture, the UE-1 702-1 may upload the changed profile picture to the HTTP content server 706. At operation 908, the UE-1 702-1 may receive a 200 OK acknowledgment message from the HTTP content server 706 in response to uploading the changed profile picture. The acknowledgement message may include an updated profile picture URL corresponding to the changed profile picture. At operation 910, the UE-1 702-1 may save the updated profile picture URL. At operation 912, the UE-2 702-2 may open the contact information of the UE-1 702-1. At operation 914, the UE-2 702-2 may send the SIP OPTIONS message to the UE-1 702-1 with a profile picture request. At operation 916, the UE-2 702-2 may receive a 200 OK acknowledgment message from the UE-1 702-1 in response to the profile picture request. The acknowledgement message may include the updated profile picture URL. At operation 918, the UE-2 702-2 may transmit a get picture request (i.e., the profile data request) to the HTTP content server 706. The get picture request may include the updated profile picture URL received from the UE-1 702-1. At operation 920, the UE-2 702-2 may receive a 200 OK acknowledgment message from the HTTP content server 706 in response to the get picture request. The acknowledgement message may include the changed profile picture corresponding to the UE-1 702-1.

Figure 10 illustrates a flowchart depicting a method 1000 for facilitating the user profile exchange between the one or more RCS clients 302 at the first RCS client 302-1, in accordance with an embodiment of the present disclosure.

At step 1002, the method 1000 may include creating the first user profile comprising the one or more attributes associated with the user of the first RCS client 302-1. The one or more attributes may include the profile picture, the name, the status message, the location, the one or more preferred links, the last available timestamp, the configuration access level, and the profile change timestamp associated with the user of the first RCS client 302-1. The first user profile may be one of the new user profile and the updated user profile. In an embodiment, for creating the first user profile, the method 1000 may include defining the one or more SIP parameters corresponding to each of the one or more attributes.

At step 1004, the method 1000 may include transmitting, to the profile server 304, the first user profile using the one or more communication protocols within the one or more SIP session procedures. The one or more SIP session procedures may include at least one of the SIP header procedure, the content body procedure, and the capability discovery procedure. Further, the one or more communication protocols may include the SIP, the HTTP, and the MSRP. In an embodiment, for transmitting the first user profile, the method 1000 may include encapsulating the first user profile within the SIP message using the one or more parameters. The method 1000 may also include transmitting, to the profile server 304, the first user profile via the SIP message.

In an embodiment, for transmitting the first user profile, the method 1000 may include transmitting the one or more attributes using the one or more SIP headers. The one or more SIP headers may include the Call-Info header, the Alert-Info header, and the User-Info header. In another embodiment, for transmitting the first user profile, the method 1000 may include transmitting the one or more attributes in the content body of the one or more SIP messages based on the one or more content-encoding formats. The one or more content-encoding formats may be selected based on one of the type of data associated with each of the one or more attributes or the type of the one or more communication protocols. In yet another embodiment, for transmitting the first user profile, the method 1000 may include transmitting the one or more attributes in one of the SIP OPTIONS message using the multipart SDP content body and the SIP Publish message using the XML tag. In a further embodiment, for transmitting the first user profile, the method 1000 may include transmitting the one or more attributes in the content body of the one or more CPIM messages.

At step 1006, the method 1000 may include receiving, from the profile server 304, at least one of the unique profile identifier or the unique profile URL corresponding to the first user profile in response to transmitting the first user profile.

At step 1008, the method 1000 may include transmitting, to the second RCS client 302-2, at least one of the unique profile identifier or the unique profile URL via the one or more SIP session procedures. The unique profile identifier or the unique profile URL enables the second RCS client 302-2 to obtain the first user profile from the profile server 304.

In an embodiment, the method 1000 may include generating the unique profile URL corresponding to the one or more RCS clients 302.

In an embodiment, the method 1000 may also include defining the feature tag for identifying support of the user profile exchange. The feature tag may indicate one or more RCS capabilities or the one or more RCS features supported by the one or more RCS clients 302.

Figure 11 illustrates a flowchart depicting a method 1100 for facilitating the user profile exchange between the one or more RCS clients 302 at the profile server 304, in accordance with an embodiment of the present disclosure.

At step 1102, the method 1100 may include receiving, from the first RCS client 302-1, the first user profile using the one or more communication protocols within the one or more SIP session procedures. The first user profile may include the one or more attributes associated with the user of the first RCS client 302-1. The one or more SIP session procedures may include the SIP header procedure, the content body procedure, and the capability discovery procedure. Further, the one or more communication protocols include the SIP, the HTTP, and the MSRP. The one or more attributes may include the profile picture, the name, the status message, the location, the one or more preferred links, the last available timestamp, the configuration access level, and the profile change timestamp associated with the user of the first RCS client 302-1. The first user profile may be one of the new user profile and the updated user profile.

At step 1104, the method 1100 may include transmitting, to the first RCS client 302-1, at least one of the unique profile identifier or the unique profile URL corresponding to the first user profile in response to receiving the first user profile.

At step 1106, the method 1100 may include receiving, from the second RCS client 302-2, the profile data request using the one or more SIP session procedures. The profile data request may include at least one of the unique profile identifier or the unique profile URL corresponding to the first user profile.

At step 1108, the method 1100 may include transmitting, to the second RCS client 302-2, the first user profile based on at least one of the unique profile identifier or the unique profile URL in response to receiving the profile data request.

In an embodiment, the method 1100 may include receiving the plurality of user profiles from the one or more RCS clients 302. The method 1100 may also include maintaining, using the profile controller 602, the plurality of user profiles based on the configuration access level associated with each of the user profiles.

Figure 12 illustrates an example block diagram of the RCS client 302, in accordance with an embodiment of the present disclosure. The RCS client 302 may include one or more processors 1202 (also referred to as the “processor” 1202), a memory unit 1204 (also referred to as the “memory” 1204), and a communication unit 1206 (e.g., communicator or communication interface).

In an embodiment, the processor 1202 may be a single processing unit or a number of units, all of which could include multiple computing units. The processor 1202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 1202 is configured to fetch and execute computer-readable instructions and data stored in the memory 1204 to perform operations/functions associated with the RCS client 302, as discussed throughout the present disclosure. The processor 1202 may include one or a plurality of processors. At this time, one or a plurality of processors 1202 may be a general-purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU). The one or a plurality of processors 1202 may control the processing of the input data in accordance with a predefined operating rule or artificial intelligence (AI) model stored in the non-volatile memory and the volatile memory, i.e., memory unit 1204. The predefined operating rule or artificial intelligence model is provided through training or learning.

In an embodiment, the memory 1204 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.

In an embodiment, the communication unit 1206 may be configured to perform one or more functions for transmitting and receiving signals via a wireless channel.

Figure 13 illustrates an example block diagram of the profile server 304, in accordance with an embodiment of the present disclosure. The profile server 304 may include one or more processors 1302 (also referred to as the “processor” 1302), a memory unit 1304 (also referred to as the “memory” 1304), and a communication unit 1306 (e.g., communicator or communication interface). The processor 1302, the memory 1304, and the communication unit 1306 may be similar to the processor 1202, the memory 1204, and the communication unit 1206 of Figure 12. Therefore, the description of the processor 1302, the memory 1304, and the communication unit 1306 has been omitted in respect of Figure 13 for the sake of brevity.

The present disclosure provides various advantages. The present disclosure provides an optimized way of sending user profile information among the RCS Clients using existing RCS flows and architecture, thereby providing enhanced messaging experience for the RCS users. Further, the present disclosure improves messaging application engagement and user chat experience and also provides enhanced self-expression for the users. Moreover, the present disclosure provides a more scalable and widely adoptable solution, addressing the deployment complexity, limited operator support, and privacy concerns associated with the existing systems.

While specific language has been used to describe the present subject matter, any limitations arising on account thereto, are not intended. As would be apparent to a person in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein. The drawings and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment.

Claims

A rich communication services (RCS) client for facilitating a profile exchange between one or more RCS clients, comprising:

a memory; and

at least one processor communicatively coupled to the memory and configured to:

create a first profile comprising one or more attributes associated with a user of the first RCS client;

transmit, to a profile server, the first profile using one or more communication protocols within one or more session initiation protocol (SIP) session procedures, wherein the one or more SIP session procedures comprise at least one of an SIP header procedure, a content body procedure, or a capability discovery procedure;

receive, from the profile server, at least one of a unique profile identifier or a unique profile uniform resource locator (URL) corresponding to the first profile; and

transmit, to a second RCS client, at least one of the unique profile identifier or the unique profile URL via the one or more SIP session procedures.
The RCS client of the claim 1,

wherein the unique profile identifier or the unique profile URL enables the second RCS client to obtain the first profile from the profile server, and

wherein the one or more attributes comprise at least one of a profile picture, a name, a status message, a location, one or more preferred links, a last available timestamp, a configuration access level, or a profile change timestamp associated with the user of the first RCS client.
The RCS client of the claim 1,

wherein to create the first profile, the at least one processor is configured to define one or more SIP parameters corresponding to each of the one or more attributes,

wherein the first profile is one of a new profile or an updated profile, and

wherein the at least one processor is further configured to generate the unique profile URL corresponding to the one or more RCS clients, and to define a feature tag for identifying support of the profile exchange.
The RCS client of the claim 1,

wherein to transmit the first profile, at least one processor is configured to:

encapsulate the first profile within an SIP message using one or more parameters; and

transmit, to the profile server, the first profile via the SIP message.
The RCS client of the claim 1,

wherein to transmit the first profile, the at least one processor is configured to:

transmit the one or more attributes using one or more SIP headers, wherein the one or more SIP headers comprise a call-info header, an alert-info header, and a user-Info header.
The RCS client of the claim 1,

wherein to transmit the first profile, the at least one processor is configured to:

transmit the one or more attributes in a content body of one or more SIP messages based on one or more content-encoding formats, wherein the one or more content-encoding formats are selected based on one of a type of data associated with each of the one or more attributes or a type of the one or more communication protocols.
The RCS client of the claim 1,

wherein to transmit the first profile, the at least one processor is configured to:

transmit the one or more attributes in one of an SIP OPTIONS message using a multipart session description protocol (SDP) content body and an SIP publish message using an extensible markup language (XML) tag.
The RCS client of the claim 1,

wherein to transmit the first profile, the at least one processor is configured to:

transmit the one or more attributes in a content body of one or more common profile for instant messaging (CPIM) messages.
A profile server for facilitating a profile exchange between one or more rich communication services (RCS) clients, comprising:

a memory; and

at least one processor communicatively coupled to the memory and configured to:

receive, from a first RCS client, a first profile using one or more communication protocols within one or more session initiation protocol (SIP) session procedures, wherein the first profile comprises one or more attributes associated with a user of the first RCS client;

transmit, to the first RCS client, at least one of a unique profile identifier or a unique profile uniform resource locator (URL) corresponding to the first profile;

receive, from a second RCS client, a profile data request using the one or more SIP session procedures, the profile data request comprises at least one of the unique profile identifier or the unique profile URL corresponding to the first profile; and

transmit, to the second RCS client, the first profile based on at least one of the unique profile identifier or the unique profile URL.
The profile server of claim 9,

wherein the one or more SIP session procedures comprise at least one of a SIP header procedure, a content body procedure, or a capability discovery procedure,

wherein the one or more attributes comprise at least one of a profile picture, a name, a status message, a location, one or more preferred links, a last available timestamp, a configuration access level, or a profile change timestamp associated with the user of the first RCS client, and

wherein the first profile is one of a new profile and an updated profile.
The profile server of claim 9,

wherein the at least one processor is further configured to:

receive a plurality of profiles from the one or more RCS clients; and

maintain the plurality of profiles based on a configuration access level associated with each of the profiles.
The profile server of claim 9,

wherein the one or more communication protocols include an SIP, a hypertext transfer protocol (HTTP), and a message session relay protocol (MSRP).
A method performed by a rich communication services (RCS) client for facilitating a profile exchange between one or more RCS clients, comprising:

creating a first profile comprising one or more attributes associated with a user of the first RCS client;

transmitting, to a profile server, the first profile using one or more communication protocols within one or more session initiation protocol (SIP) session procedures, wherein the one or more SIP session procedures comprise at least one of an SIP header procedure, a content body procedure, or a capability discovery procedure;

receiving, from the profile server, at least one of a unique profile identifier or a unique profile uniform resource locator (URL) corresponding to the first profile; and

transmitting, to a second RCS client, at least one of the unique profile identifier or the unique profile URL via the one or more SIP session procedures.
The method of the claim 13,

wherein the unique profile identifier or the unique profile URL enables the second RCS client to obtain the first profile from the profile server, and

wherein the one or more attributes comprise at least one of a profile picture, a name, a status message, a location, one or more preferred links, a last available timestamp, a configuration access level, or a profile change timestamp associated with the user of the first RCS client.
A method performed by a profile server for facilitating a profile exchange between one or more rich communication services (RCS) clients, comprising:

receiving, from a first RCS client, a first profile using one or more communication protocols within one or more session initiation protocol (SIP) session procedures, wherein the first profile comprises one or more attributes associated with a user of the first RCS client;

transmitting, to the first RCS client, at least one of a unique profile identifier or a unique profile uniform resource locator (URL) corresponding to the first profile;

receiving, from a second RCS client, a profile data request using the one or more SIP session procedures, the profile data request comprises at least one of the unique profile identifier or the unique profile URL corresponding to the first profile; and

transmitting, to the second RCS client, the first profile based on at least one of the unique profile identifier or the unique profile URL.