Patent Application
20130260733
The present disclosure relates generally to a method and a capability manager for supporting provision of capabilities between two user terminals.
In modern user terminals for communication, there are typically multiple options available for communication and usage of services in a communication network. For example, a user terminal may be capable of supporting several different types of communication such as voice calls, video telephony, messaging based on Short Message Service (SMS) and Multimedia Message Service (MMS), text chats, file sharing, video sharing, online games, and also different encoding schemes and protocols, to mention a few illustrative examples. In this description, the term “capabilities” basically refers to such communication types, encoding schemes and protocols.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed to enable such differentiated services and sessions for user terminals connected to different access networks. The signalling protocol “SIP” (Session Initiation Protocol) can further be used for initiating and controlling communication sessions between different entities, as controlled by specific session control nodes in the IMS network, sometimes referred to as Call Session Control Function (CSCF) nodes. IMS also allows a user to have more than one terminal that can be addressed by the same identity, typically a telephone number.
There is thus a mixture of different user terminals in use today, having more or less differentiated capabilities, and when two user terminals shall execute some communication with each other, it is a common practice that they compare their capabilities first in order to know which type of communication is available for these two particular terminals. The communication type to use must be supported by both terminals, otherwise it cannot be used.
In the following description, the term “user terminal” is used to represent any terminal, user equipment, device, etc. which is capable of communication with an opposite entity such as another user terminal over a communications network. Some non-limiting examples of user terminals that can be used in this context include mobile phones, smartphones, laptop computers, tablets, television units, media players, and game consoles. Each of these terminal categories includes in turn a myriad of different brands and models with different functions and communication possibilities. It can thus be readily understood that the above provision of capabilities is necessary to find out what options are available.
One existing mechanism for exchanging capabilities between entities is the so-called “SIP Options” method, which is schematically illustrated in
In particular, the SIP Options message from terminal 100 may include the capabilities of terminal 100, e.g. presented basically in the form of a list or record indicating which communication types the terminal 100 is capable of using. The opposite user terminal 102 conventionally responds by returning a so-called “200 OK” message to terminal 100, in an action 1:2, which typically always includes the capabilities of terminal 102 indicating which communication types the terminal 102 is capable of using. Thereby, the capabilities of the terminals 100, 102 have been exchanged and each terminal can determine which communication types are possible to use, i.e. those supported by both terminals. The capabilities of either terminal are thus exposed in this way at the opposite side and the available communication options can also be displayed on the terminals 100, 102, e.g. by showing or lightening corresponding icons or the like on the screen, such that their respective users can easily see which options are available before selecting and activating a communication type to use.
Another known mechanism, schematically illustrated in
In this case, it is not necessary to exchange capabilities in specific request and response messages between the terminals 200, 202, as in the above SIP Option method. Once retrieved, the capabilities of terminal 202 are known and used by terminal 200 to determine which types of communication are possible to use, and corresponding icons or the like may be displayed on the screen of terminal 200 indicating to its user which options are available. The user of terminal 200 can thus select and activate an available communication type, and a session request or the like is then issued to terminal 202 over a session control node 206, in an action 2:3. Terminal 202 will then respond accordingly to the session request in another shown action 2:4.
However, there are some drawbacks associated with the above procedures. A user may not be willing to expose his/her terminal(s) for starting, e.g., a video call or a text chat with anybody, depending on the current situation and/or depending on who is calling which could be a totally unknown person. One possibility often used to avoid unwanted calls is to block the terminal altogether from incoming calls, which can also be done selectively e.g. using so-called “black lists” or “white lists”. Still, when using the SIP Options method of
Even if the presence method of
It is an object of the invention to address at least some of the problems and issues outlined above, and to enable a terminal user to control whether the capabilities of his/her user terminal and corresponding options for communication will be exposed at an opposite user terminal. It is possible to achieve these objects and others by using a method and a capability manager as defined in the attached independent claims.
According to one aspect, a method is provided in a capability manager for supporting provision of capabilities of a first user terminal to a second user terminal. In this method, the capability manager receives a capability message issued by the first user terminal and directed to the second user terminal. The received capability message comprising capabilities of the first user terminal. Filtering rules, which have been pre-configured in the capability manager for the first user terminal to control exposure of the capabilities, are then applied on the capabilities in the capability message. The capability manager then modifies the capability message by omitting at least one of the capabilities based on the filtering rules, and forwards the modified capability message towards the second user terminal. Thereby, only the capabilities left in the modified capability message, if any, can be exposed at the second user terminal if they correspond to capabilities of the second user terminal.
According to another aspect, a capability manager is configured to support provision of capabilities of a first user terminal to a second user terminal. The capability manager comprises a receiving unit adapted to receive a capability message issued by the first user terminal and directed to the second user terminal, and the received capability message comprises capabilities of the first user terminal. The capability manager also comprises a logic unit adapted to apply filtering rules on the capabilities in the capability message, wherein the filtering rules have been pre-configured for the first user terminal. The logic unit is further adapted to modify the capability message by omitting at least one of the capabilities based on the filtering rules. The capability manager also comprises a forwarding unit adapted to forward the modified message towards the second user terminal.
When the above method and capability manager are implemented and used, the user of the first user terminal is able to control the exposure of terminal capabilities and corresponding options for communication at any opposite user terminal receiving the capability message, by pre-configuring the filtering rules in any desired manner in the capability manager. For example, if the user does not want to expose a particular capability and corresponding type of communication depending on the situation, he/she can configure the filtering rules such that this capability will be omitted from the capability message when this situation occurs.
The above method and capability manager may be configured and implemented according to different optional embodiments which are possible to select and combine in any suitable manner depending on implementation. In some possible embodiments, the capability message could be a capability request sent to the second user terminal such as a SIP Options message, or a response to a capability request received from the second user terminal such as a 200 OK message.
In further possible embodiments, the filtering rules may pertain to at least one of identity of a user of the second user terminal, identity of the first user terminal, current status or activity of the first user terminal and its user, current geographical location of the first user terminal, time or day, and type of service. Further, the capability manager may be implemented in a communication services network such that its features and functions are put into practice at a single central location. In that case, the filtering rules could be configurable by the first terminal user by using any of: a client in the first user terminal, a downloadable application, and an interactive web interface. In the above network implementation, the capability manager may be connected to a session control node, e.g. a CSCF node of a SIP network, which handles communication between the first and second user devices in the communication services network. The session control node is thus responsible for receiving and routing the capability message in the network. Alternatively, the capability manager may be implemented in the first user terminal such that no network implemented capability manager is needed.
The filtering rules may be employed by means of an existing function of Presence Authorization Rules or Mobile Multimedia Telephony (MMTel) service.
Further possible features and benefits of this solution will become apparent from the detailed description below.
The solution will now be described in more detail by means of exemplary embodiments and with reference to the accompanying drawings, in which:
Briefly described, a solution is provided to enable a user of a first user device to control the exposure of capabilities to a second user device by configuring filtering rules in a capability manager. When the first user device issues a capability message directed to a second user device and containing a more or less complete set of capabilities, e.g. using the SIP Options method, the message is routed over the capability manager which applies the previously configured filtering rules and modifies the capability message by omitting at least one of the capabilities based on the filtering rules. Thereby, the modified capability message will contain a reduced set of capabilities when forwarded to the second user device. The filtering rules can be pre-configured in any manner by the user to filter out one or more capabilities depending on the situation, which will be described in more detail below. It is also possible that the filtering rules could dictate that no capabilities should be left in the message at all.
In this description, the term “capability message” is used to represent any message sent from a first user terminal to another communication entity, such as another user terminal like in the examples below, which message contains, at least when sent from the first terminal, information on capabilities of the first user terminal. Some examples of a capability message include the above-described messages SIP Options and 200 OK, although the solution is not limited to any particular capability messages. By configuring the filtering rules in the capability manager, the terminal user is able to control if, how and when his/her terminal's capabilities will be exposed in any opposite communication entities. It is an advantage that the user is thereby able to pre-configure such filtering rules to obtain tailored and personalized exposure of terminal capabilities in opposite terminals and entities in a relatively easy and reliable way. In this context, exposure of terminal capabilities is typically done by displaying corresponding options for communication, i.e. the available types of communication such as voice, video, chat, messaging, file transfer, etc., on the opposite terminal's screen.
The pre-configured filtering rules may pertain to the current time or day, or to the type of service such that certain types of services should be exposed but not others depending on the situation. According to other possible examples, the filtering rules may pertain to the identity of a user of the second user terminal. For example, the filtering rules may be configured such that the option of a voice call should be exposed to any opposite party while the option of a video call, a text chat, etc. should be exposed only to a set of known parties but not to other e.g. unknown parties.
In another example, the configured filtering rules may pertain to the identity of the first user terminal. If the first user owns more than one terminal and has configured a set of filtering rules for these terminals, the filtering rules may be defined to dictate that one set of one or more capabilities should be omitted from the capability message when using one terminal while another set of capabilities should be omitted when using another terminal. For example, the user may not want to reveal all the advanced possibilities of communication that a particular lavish terminal might have, e.g. to a potentially malicious caller.
In yet another example, the configured filtering rules may pertain to a current status or activity of the first user terminal and its user, such as engaged in a session, on hold, sleeping, in meeting, driving a vehicle, and so forth. The configured filtering rules may also refer to current geographical location of the first user terminal. For example, the option of a video call may be omitted from the capability message when located at work or in an area not covered by the user's home network. In general, the filtering rules may be configured so as to pertain to any of the above factors, or any combination thereof.
The capability manager described herein may be implemented in a communication services network such as an IMS network, or in the first user terminal, which will be described in more detail below. Further, the filtering rules may be employed in practice by means of an existing function of the known Presence Authorization Rules or a known Mobile Multimedia Telephony (MMTel) service.
Some examples of how the solution may be used in practice when the capability manager is implemented in a communication services network 310, will now be described with reference to
A next action 3:2 illustrates that the user has made some input command, such as entering a telephone number, which triggers the terminal 300 to issue a capability request, thus being a capability message such as the above-described SIP Options message, directed to the opposite user terminal 302. When this message reaches the session control node 306, it is routed to the capability manager 304 as shown by an arrow directed thereto. When receiving the capability request, the capability manager 304 applies the pre-configured filtering rules 304a, in an action 3:3, and modifies the message by omitting at least one of the capabilities from the message, based on the filtering rules. As mentioned above, it is possible that all capabilities are omitted from the message depending on the filtering rules and the current situation. It may also happen in some cases that the filtering rules allow all capabilities to be exposed at the opposite terminal, i.e. no capability needs to be omitted according to the rules, which is however outside the scope of this example.
A next action 3:4 illustrates that the modified capability message is forwarded as a “filtered request” from the capability manager 304 and routed by the session control node 306 to the second user terminal 302. Depending on what capabilities the second terminal 302 itself has, it will expose options for communication according to those capabilities in the received message which are also valid for the second terminal 302. In this context, it may happen that none of the first terminal's capabilities present in the capability message, if any, are common with those of the second terminal 302, and in that case no options for communication will be exposed at all.
According to regular procedures, the second terminal 302 also duly sends a response to the capability message received from terminal 300, as shown in an action 3:5, which is routed by the session control node 306 to terminal 300. The response in this action is typically a 200 OK message which always should contain the capabilities of the sending terminal 302, and it may likewise be processed by the capability manager 304 in a similar manner, not shown here for simplicity.
When receiving the response message, the capability manager 304 applies the pre-configured filtering rules 304a, in an action 4:3, and modifies the message by omitting at least one of the capabilities from the message, based on the filtering rules, which is similar to the operation in action 3:3 above. A next action 4:4 illustrates that the modified response message is forwarded as a “filtered response” from the capability manager 304, as routed by the session control node 306, to the second user terminal 302.
By using the solution exemplified by the above scenarios of
A procedure for supporting provision of capabilities of a first user terminal to a second user terminal, will now be described with reference to the flow chart in
In a first action 500, the capability manager receives a capability message issued by the first user terminal and directed to the second user terminal, basically corresponding to actions 3:2 and 4:2 above. The received capability message comprising capabilities of the first user terminal, which message could be, without limitation, a capability request such as the SIP Options message, or a response to a capability request from another terminal such as the 200 OK. The capability manager then applies the previously pre-configured filtering rules on the capabilities in the capability message, in a next action 502, basically corresponding to actions 3:3 and 4:3 above.
In a further action 504, the capability manager modifies the received capability message by omitting at least one of the capabilities therein, based on the filtering rules. The capability manager then forwards the modified capability message towards the second user terminal, in a final shown action 506, basically corresponding to actions 3:4 and 4:4 above.
As mentioned above,
A detailed but non-limiting example of how a capability manager can be configured to accomplish the above-described solution, is illustrated by the block diagram in
The capability manager 700 comprises a receiving unit 700a adapted to receive a capability message “CM” issued by the first user terminal and directed to the second user terminal. The capability message comprises capabilities of the first user terminal. As shown in the above examples, the capability message CM may be received from a session control node in a communication services network or from a local message function within the first terminal.
The capability manager 700 also comprises a logic unit 700b adapted to apply the filtering rules 700c on the capabilities in the capability message CM. The logic unit 700b is further adapted to modify the received capability message by omitting at least one of the capabilities therein based on the filtering rules 700c. The capability manager 700 also comprises a forwarding unit 700d adapted to forward the modified message “CM-mod” towards the second user terminal.
It should be noted that
The functional units 700a-d described above can be implemented in the capability manager 700 by means of program modules of a respective computer program comprising code means which, when run by a processor “P” causes the capability manager 700 to perform the above-described actions and procedures. The processor P may comprise a single Central Processing Unit (CPU), or could comprise two or more processing units. For example, the processor P may include a general purpose microprocessor, an instruction set processor and/or related chips sets and/or a special purpose microprocessor such as an Application Specific Integrated Circuit (ASIC). The processor P may also comprise a storage for caching purposes.
Each computer program may be carried by a computer program product in the capability manager 700 in the form of a memory “M” having a computer readable medium and being connected to the processor P. The computer program product or memory M thus comprises a computer readable medium on which the computer program is stored e.g. in the form of computer program modules “m”. For example, the memory M may be a flash memory, a Random-Access Memory (RAM), a Read-Only Memory (ROM) or an Electrically Erasable Programmable ROM (EEPROM), and the program modules m could in alternative embodiments be distributed on different computer program products in the form of memories within the capability manager 700.
While the solution has been described with reference to specific exemplary embodiments, the description is generally only intended to illustrate the inventive concept and should not be taken as limiting the scope of the solution. For example, the terms “capability manager”, “user device”, “capabilities”, “capability message”, “session control node” and “filtering rules” have been used throughout this description, although any other corresponding nodes, functions, and/or parameters could also be used having the features and characteristics described here. The solution is defined by the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 12161536.3 | Mar 2012 | EP | regional |
| Number | Date | Country | |
|---|---|---|---|
| 61617162 | Mar 2012 | US |
