TECHNICAL FIELD

The present disclosure relates to methods for exchanging service capabilities between two user equipments, and user equipments capable of executing such methods.

BACKGROUND

With an increasing number of services made available to end-users subscribing to fixed or wireless network access, there is a rising demand for making such services easily accessible, not only during established usage but also as an initial introduction to the services.

Rich Communication Services (RCS) is a group of services which relate to a global program that deploys inter-operator services within an industry ecosystem. RCS has been created by GSM Association (GSMA) with a purpose of offering richer communication services supported by a strong ecosystem and a variety of architecture implementation options.

RCE and Voice over Long Term Evolution (VoLTE) share the same IP Multimedia Subsystem (IMS) investment and leverages the same IMS capabilities.

For consumers, RCS combine voice and SMS with instant messaging or chat, live video sharing and file transfer across different types of devices, or user equipments (UE), and networks, and provide main features, such as e.g. an enhanced phonebook, providing service capabilities and enhanced contact information, such as e.g. presence and service discovery; enhanced messaging, which enables a large variety of messaging options, including chat, emoticons, location sharing and file sharing, and enriched calls, which enables multimedia content sharing during a voice call, video call and video sharing.

RCS requires exchanging of service capabilities to be successfully executed between two RCS capable UEs, i.e. that a UE reviles which services it has available to the other UE, prior to establishing of an actual RCS based service between the two UEs.

Section 2.6.2 of RCS 5.1, version 2.0 describes two possible mechanisms for service capabilities exchange, namely SIP OPTIONS and Presence. Even though the standard does not require the service capabilities exchange process to provide any authorization or any privacy management framework, in principle any user can request capabilities associated with another user, being registered to one or more UEs or devices, from any UE or device. When e.g. a service capabilities exchange is executed using the Presence alternative, a privacy framework is made available to the users. Section 2.6.1.3 of RCS 5.1, version 2.0 indicates that when users already have established a social Presence relationship, service capabilities can be requested and acquired via a Presence subscription, but only if the present authorization rules allow that.

Also, nowadays users of Over The Top (OTT) services, such as e.g. Facebook™ Google Hangouts™ or Skype™ are provided with the option of controlling which users can see their service capabilities, and, as a consequence, under such circumstances users must first establish a social relationship before these service capabilities can be exchanged. It is reasonable to expect that also RCS users may want to find corresponding functionality in RCS, i.e. the ability to have control over their service visibility.

A typical scenario, involving two users, communicating via respective UEs may be described as follows, with reference to a simplified signalling scheme illustrated inFIG. 1.

A first user, who is registered with, and capable of communicating via a UE, here referred to as first UE110a, is an RCS user, i.e. the first user is subscribing to RCS and is using an RCS enabled UE. The first user now wants to communicate with a second user via an IMS network, here represented by IMS core100, and a second UE110b.

The second user is very concerned about his privacy. Therefore he decides to limit the number of users he wants to authorize to contact him via RCS services to his family and a limited number of RCS subscribing friends. Such an authorization procedure implies that the first user is only willing to share associated service capabilities related information with a limited list of RCS users, while remaining RCS users who may try to initiate RCS services with the first user will not succeed. Furthermore, the latter category of users will not even be able to become aware of whether or not the first user is an RCS user. Consequently, the second user connects to the IMS core100and configures his privacy settings by provisioning his authorization rules accordingly, as indicated in step1:1ofFIG. 1. Such a provisioning does not include the first user mentioned above.

Even though the first user is a very good friend of the second user, he is not among the friends authorized by the second user in step1:1, or in any previous authorization provisioning step. There are a number of reasons why the second user may not be among the authorized RCS users. Let us e.g. assume that the first user has just recently acquired an RCS capable or enabled UE and an RSC subscription of which the second user is not yet aware of, i.e. the second user is unaware of that the first user is a potential RCS counterpart.

When the first user has gone through his imported contacts and wants to discover which ones of his contacts who are RCS users, and thus provide for usage of RCS, he initiates a service capabilities exchange request, requesting for a service capabilities exchange to be executed, as indicated with another step1:2. Typically, such a request is executed by using a commonly known OPTIONS or Presence mechanism as mentioned above. In the present scenario, it is determined by the IMS core100that, since the first user has not been authorized to access the requested service capabilities, such a request will result in a response from the IMS core100to the first user, rejecting the request, and instead of exposing the capabilities associated with the second user indicating to the first user that the second user is not found, and, thus, that the first user is not authorized to access the service capabilities associated with the second user, as indicated with a final step1:3. More specifically, the address book of the first user will typically present the second user as a legacy user, having no RCS capabilities, even though in this case the second user is in fact an RCS enabled user who may even be very keen on communicating via such servicers with the first user. More information on this process can be found in chapter 2.6 of RCS 5.1 Advanced Communications Services and Client Specification, Version 3.0, 25 Sep. 2013.

The described deficiency may also be an obstacle for new users discovery and may contribute to the delay of introduction and spreading of use of this type, as well as similar types of services.

SUMMARY

It is an object of the present document to address, or at least alleviate, at least some of the problems described above.

According to a first aspect, a method to be executed in a first UE of a first user for communicating with a second UE of a second user is suggested, wherein the first UE is capable of applying a service which requires exchange of service capabilities between users for enabling the two users to communicate via the mentioned service, and wherein the first user is not authorized to access the service capabilities associated with the second user. The method comprise: providing a service capabilities request, requesting an exchange of service capabilities associated with the two users, where the service capabilities request is provided via a first signaling protocol; identifying a response to the service capabilities request, received by the first UE, as a rejection to the service capabilities request; providing a service capabilities exchange invitation to the second UE, via a second signaling protocol other than the first signaling protocol, wherein the invitation is requesting an exchange of service capabilities associated with the two users; identifying the second user as a user with which the first user cannot communicate via the two UEs and the mentioned service, in case the service capabilities exchange invitation does not result in the requested exchange of service capabilities, or identifying the second user as a user with which the first user can now communicate via the two UEs and the mentioned service, in case the service capabilities exchange invitation results in the requested exchange of service capabilities.

By applying the method suggested above, also a user which has not been authorized to access the service capabilities of another user will be able to request an exchange of service capabilities associated with these two users.

Once the service capabilities exchange process has been finalized the first UE will be able to execute a service which is requiring a service capabilities exchange before service execution when communicating with the second UE can be initiated, at least partly based on the exchanged service capabilities.

In order to enable the first UE to communicate accordingly with the second UE, the signaling protocol other than the first signaling protocol is chosen from signaling protocols which are not affected by any authorization rules of the second user that relates to the mentioned service. Such a signaling protocol may e.g. be a Short Messaging Service (SMS), a short Messaging Service over Session Initiation Protocol (SMS over SIP), or a Multimedia Messaging Services (MMS).

Typically, the service capabilities exchange invitation comprises a text message which relates to the mentioned service. Thereby, a message provided in a service capabilities exchange invitation may e.g. be configured such that further information about a certain service, or type of service, is provided in the invitation.

According to one embodiment, the mentioned service is a Rich Communication Service (RCS). In such a situation the service capabilities exchange invitation may comprise text, and optionally also a link to further RCS related information, typically so that use of RCS is promoted, also among users which are presently not RCS users.

According to one embodiment the service capabilities exchange invitation is a message which is generated automatically, upon identifying the response to the service capabilities exchange request as a rejection of the request, i.e. without requiring any interaction from the user, while according to another embodiment the service capabilities exchange invitation is instead a message which is generated upon user consent of the first user and upon identifying the response to the service capabilities exchange request as a rejection of the request.

According to a second aspect, a corresponding method executable in a second UE of a second user is provided, where the second UE is capable of communicating with a first UE of a first user, and of applying a service which require exchange of service capabilities associated with users, for enabling the two users to communicate via the mentioned service, and wherein the first user is not authorized to access the service capabilities associated with the second user. The method comprise: receiving a service capabilities exchange invitation, requesting an exchange of service capabilities associated with the two users, from the first UE, wherein the invitation is received via a second signaling protocol other than a first signaling protocol which has been previously applied by the first UE when unsuccessfully requesting an exchange of service capabilities associated with the two users; presenting the service capabilities exchange invitation to the second user, such that the second user is provided with the options of allowing the second user to accept or reject the requested service capabilities exchange, in case the second UE is capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities, or presenting a message contained in the service capabilities exchange invitation, in case the second UE is not capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities.

Once a service capabilities exchange has been executed between the two UEs, the second UE will be able to execute the suggested service when communicating with the first UE, wherein the service execution is executed at least partly based on the exchanged service capabilities.

In association with performing the requested service capabilities exchange the suggested method also comprise: updating the authorization rules of the second user such that the first user is allowed to access the service capabilities associated with the second user, and initiation of the requested service capabilities exchange, in case the second user accepts the service capabilities exchange invitation, or terminating the communication with the first UE and rejecting the requested service capabilities exchange, in case the second user rejects the request or in case the second UE is not capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities.

According to a third aspect a first UE capable of communicating with a second UE and of applying a service which requires exchange of service capabilities between users for enabling said users to communicate via the mentioned service is suggested. The suggested first UE comprise a processor and a memory, where the memory comprise instructions which when executed by the processor causes the first UE to: provide a service capabilities request via a first signaling protocol, wherein the request is requesting an exchange of service capabilities associated with the users of the two UEs when a first user, being a user of the first UE, is not authorized to access the service capabilities associated with a second user, being a user of the second UE; identify a response to the service capabilities request, received by the first UE, as a rejection to the service capabilities request; provide a service capabilities exchange invitation to the second UE via a second signaling protocol other than the first signaling protocol, wherein the first UE is requesting an exchange of service capabilities associated with the two users; identify the second user as a user with which the first user cannot communicate via said UEs and the mentioned service, in case the service capabilities exchange invitation does not result in the requested exchange of service capabilities, or identify the second user as a user with which the first user can now communicate via said UEs, in case the service capabilities exchange invitation results in the requested exchange of service capabilities.

The memory of the first UE may further comprise instructions which when executed by the processor causes the first UE to store the exchanged service capabilities associated with the second user. In addition, the memory may further comprise instructions which when executed by the processor causes the first UE to execute the mentioned service at least partly based on the exchanged service capabilities.

As already mentioned above, the signaling protocol other than the first signaling protocol is chosen from signaling protocols which are not affected by any authorization rules of the second user that relates to the mentioned service, which may be e.g. a Short Messaging Service (SMS), a short Messaging Service over Session Initiation Protocol (SMS over SIP), or a Multimedia Messaging Services (MMS).

The memory typically further comprise instructions which when executed by the processor causes the first UE to provide the service capabilities exchange invitation with a text message which relates to the mentioned service, such that, in addition to initiating a service capabilities exchange, the invitation may also have the additional purpose of promoting or informing of a certain service or a group of services.

According to one embodiment the memory further comprise instructions which when executed by the processor causes the first UE to automatically generate the service capabilities exchange invitation upon identifying the response to the service capabilities exchange request as a rejection of the request, while according to another embodiment, the memory instead comprise instructions which when executed by the processor causes the first UE to generate the service capabilities exchange invitation upon user consent and upon identifying the response to the service capabilities exchange request as a rejection of the request.

According to a fourth aspect a first computer program for providing for communication between a first UE and a second UE and for enabling the first UE to apply a service which require exchange of service capabilities between users for enabling these users to communicate via the mentioned service is provided, where the computer program comprises code means which when run on a computer of the first UE causes the computer to: provide a service capabilities request via a first signaling protocol, where the request is configured such that it is requesting an exchange of service capabilities associated with the users of the two UEs, when a first user, being a user of the first UE, is not authorized to access the service capabilities associated with a second user, being a user of the second UE; identify a response to the service capabilities request, received by the first UE, as a rejection to the service capabilities request; provide a service capabilities exchange invitation to the second UE, where the invitation is requesting an exchange of service capabilities associated with the two users, wherein the invitation is provided via a signaling protocol other than the first signaling protocol; identify the second user as a user with which the first user cannot communicate via the two UEs and the mentioned service, in case the service capabilities exchange invitation does not result in the requested exchange of service capabilities, or identify the second user as a user with which the first user can now communicate via the two UEs and the mentioned service, in case the service capabilities exchange invitation results in the requested exchange of service capabilities.

According to a fifth aspect a first computer program product, comprising computer readable code means and a computer program as suggested above, which is stored on a computer readable means, is also provided.

According to a sixth aspect a second UE, capable of communicating with a first UE, such as the one suggested above, and of applying a service which require exchange of service capabilities associated with users, for enabling these users to communicate via the mentioned service, is provided. The second UE comprise a processor and a memory, wherein the memory comprise instructions which when executed by the processor causes the second UE to: receive a service capabilities exchange invitation from the first UE via a second signaling protocol other than a first signaling protocol previously applied by the first UE when unsuccessfully requesting an exchange of service capabilities associated with the users of the two UEs and when the first user, being a user of the first UE, is not authorized to access the service capabilities associated with a second user, being a user of the second UE, the invitation being configured as an invitation requesting an exchange of service capabilities associated with the two users; present options allowing the second user to accept or reject the requested service capabilities exchange, in case the second UE is capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities, or present a message contained in the service capabilities exchange invitation, in case the second UE is not capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities.

The memory further comprise instructions which when executed by the processor causes the second UE to execute the mentioned service, at least partly based on the exchanged service capabilities associated with the second user.

Furthermore, the memory comprise instructions which when executed by the processor causes the second UE to: update the authorization rules of the second user, such that the first user is allowed to access service capabilities associated with the second user, and initiate the requested service capabilities exchange, in case the user of the second UE accepts the service capabilities exchange invitation, or reject the requested service capabilities exchange, in case the second user rejects the request or in case the second UE is not capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities.

According to a seventh aspect, a second computer program for providing for communication between a first UE and a second UE is provided, wherein the second UE is capable of applying a service which requires exchange of service capabilities associate with users for enabling these users to communicate via the mentioned service. This computer program comprises code means which when run on a computer of the second UE causes the computer to: receive a service capabilities exchange invitation, requesting an exchange of service capabilities associated with the two users, wherein the invitation is received from the first UE via a second signaling protocol other than a first signaling protocol previously applied by the first UE when unsuccessfully requesting an exchange of service capabilities associated with the users of the two UEs and when a first user, being a user of the first UE, is not authorized to access the service capabilities associated with a second user, being a user of the second UE; present options allowing the second user to accept or reject the requested service capabilities exchange, in case the second UE is capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities, or present a message contained in the service capabilities exchange invitation, in case the second UE is not capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities.

According to an eights aspect a first UE, capable of communicating with a second UE and of applying a service which require exchange of service capabilities between users for enabling these users to communicate via the mentioned service, is provided which comprise: a first requesting module for providing, via a first signaling protocol, a service capabilities request, requesting an exchange of service capabilities associated with the users of the two UEs, to the second UE, when a first user, being a user of the first UE, is not authorized to access the service capabilities associated with a second user, being a user of the second UE; a first identifying module for identifying a response to the service capabilities request, received from the second UE, as a rejection to the service capabilities request; a second requesting module for providing a service capabilities exchange invitation via a signaling protocol other than the first signaling protocol, the invitation being configured to request an exchange of service capabilities exchange associated with the two users; a second identifying module for identifying the second user as a user with which the first user cannot communicate via said UEs and the mentioned service, in case the service capabilities exchange invitation does not result in the requested service capabilities, or for identifying the second user as a user with which the first user can now communicate via the two UEs and the mentioned service, in case the service capabilities exchange invitation results in the requested exchange of service capabilities.

According to a ninth aspect, a second UE, capable of communicating with a first UE, such as the one mentioned above, and of applying a service which requires exchange of service capabilities associated with users for enabling these users to communicate via the mentioned service, is provided. The second UE comprise: a second receiving module for receiving a service capabilities exchange invitation from the first UE via a second signaling protocol other than a first signaling protocol, previously applied by the first UE when unsuccessfully requesting an exchange of service capabilities associated with the users of said UEs from a first receiving module of the second UE, the invitation being an invitation requesting an exchange of service capabilities associated with the two users, when a first user, being the user of the first UE, is not authorized to access the service capabilities associated with a second user, being the user of the second UE, and a presenting module for presenting the service capabilities exchange invitation to a user of the second UE, such that this user is provided with the options of accepting or rejecting the requested service capabilities exchange, in case the second UE is capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities, or for presenting a message contained in the service capabilities exchange invitation, in case the second UE is not capable of interpreting the service capabilities exchange invitation as a request for exchanging service capabilities.

