US20090150562A1 - Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity - Google Patents

Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity Download PDF

Info

Publication number
US20090150562A1
US20090150562A1 US11/952,921 US95292107A US2009150562A1 US 20090150562 A1 US20090150562 A1 US 20090150562A1 US 95292107 A US95292107 A US 95292107A US 2009150562 A1 US2009150562 A1 US 2009150562A1
Authority
US
United States
Prior art keywords
device
communication
apparatus
policy
session
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/952,921
Inventor
Youngae Kim
Andrew Allen
Adrian Buckley
Jan John-Luc Bakker
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BlackBerry Ltd
Original Assignee
BlackBerry Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BlackBerry Ltd filed Critical BlackBerry Ltd
Priority to US11/952,921 priority Critical patent/US20090150562A1/en
Assigned to RESEARCH IN MOTION LIMITED reassignment RESEARCH IN MOTION LIMITED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BUCKLEY, ADRIAN, ALLEN, ANDREW, KIM, YOUNGAE, BAKKER, JAN JOHN-LUC
Publication of US20090150562A1 publication Critical patent/US20090150562A1/en
Assigned to BLACKBERRY LIMITED reassignment BLACKBERRY LIMITED CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: RESEARCH IN MOTION LIMITED
Application status is Abandoned legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1003Signalling or session protocols
    • H04L65/1006SIP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1013Network architectures, gateways, control or user entities
    • H04L65/1016IMS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1013Network architectures, gateways, control or user entities
    • H04L65/1063Application servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1073Registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1083In-session procedures
    • H04L65/1086In-session procedures session scope modification
    • H04L65/1089In-session procedures session scope modification by adding or removing media
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/2803Home automation networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/2803Home automation networks
    • H04L12/2807Exchanging configuration information on appliance services in a home automation network
    • H04L12/2812Exchanging configuration information on appliance services in a home automation network describing content present in a home automation network, e.g. audio video content
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. local area networks [LAN], wide area networks [WAN]
    • H04L12/2803Home automation networks
    • H04L2012/2847Home automation networks characterised by the type of home appliance used
    • H04L2012/2849Audio/video appliances
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00 contains provisionally no documents
    • H04L29/02Communication control; Communication processing contains provisionally no documents
    • H04L29/06Communication control; Communication processing contains provisionally no documents characterised by a protocol
    • H04L29/06176Arrangements for real-time multimedia communications
    • H04L29/06183Signalling, control or architecture
    • H04L29/0619Signalling or session protocols
    • H04L29/06197SIP [Session Initiation Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/50Network service management, i.e. ensuring proper service fulfillment according to an agreement or contract between two parties, e.g. between an IT-provider and a customer
    • H04L41/508Network service management, i.e. ensuring proper service fulfillment according to an agreement or contract between two parties, e.g. between an IT-provider and a customer based on type of value added network service under agreement
    • H04L41/509Network service management, i.e. ensuring proper service fulfillment according to an agreement or contract between two parties, e.g. between an IT-provider and a customer based on type of value added network service under agreement wherein the managed service relates to media content delivery, e.g. audio / video / TV
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00Arrangements for user-to-user messaging in packet-switching networks, e.g. e-mail or instant messages
    • H04L51/10Messages including multimedia information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/30Network-specific arrangements or communication protocols supporting networked applications involving profiles
    • H04L67/306User profiles

Abstract

An apparatus, and an associated method, for directing communications of a communication session to a selected communication device, or devices, of a group of commonly-registered devices. A device-direction policy is created and stored at a network entity. The policy identifies preferred devices to which communications of a communication session are to be provided. A SIP Invite, or other communication-session initiation message, is provided to the network entity. The network entity detects the message, accesses the policy, and forwards on the message in accordance with the policy.

Description

  • The present disclosure relates generally to a manner by which to direct a communication session or a communication message to a communication device of a group of devices having a common registration identity. More particularly, the present disclosure relates to an apparatus, and an associated method, for setting preferences for the routing of communication-session invitations or communication messages to a selected device, or devices, of the group.
  • The preferences include preferences based upon the types of media that are to be communicated pursuant to the communication session or communication message. A communication session invitation or communication message is forwarded to a device in conformity with the preferences.
  • BACKGROUND OF THE DISCLOSURE
  • For many, ready access to communication systems to permit communication therethrough is a necessity of everyday life. Advancements in communication technologies have permitted the development and deployment of a variety of communication systems that provide for the performance of various communication services. With increased capabilities of digital, and other, technologies, communication services that can be carried out include communication services that are increasingly data-intensive. Multimedia communication services, for instance, communication services that are formed of multiple media types, e.g., audio, text, and video, are amongst the communication services that have been developed and deployed as a result of advancements in digital communication technologies.
  • Multimedia communication services are, for instance, implementable by way of radio communication networks in which communication stations, i.e., devices, are capable of participating in a multimedia communication service. A cellular communication system is an exemplary type of radio communication system whose infrastructures have been widely deployed and whose services are widely utilized in many parts of the world. The multi-media capabilities are generally available only in new-generation devices. That is to say, older-generation, cellular communication stations generally are not multi-media capable. When a multi-media communication service is to be performed, the communication station that is to be a party to the communication service must be capable of participating pursuant to sending and receiving of the multi-media data of the communication service.
  • Conventionally, communication stations are provided with a single identity. Analogous to a conventional, telephonic system, communication stations are conventionally identified by a single identity, such as a telephone number that identifies a single telephone or cellular communication station. Technological advancements, however, permit concepts other than a single-mapping concept in which a single identity, e.g., a telephone number, maps uniquely only to a single line or device. For instance, the SIP (Session Initiation Protocol)-based signaling, as well as other Internet-based communication technology signaling, supports the concept of multiple devices that are registered with the same identity, such as a user identity, or URI. The SIP also supports the capability of multi-media communications including text, other types of messaging, along with audio and video within a single communication session or single Communication Message. A communication session is an association established between two or more devices or users for the purposes of communication (including real time and non real time) using any media type (including audio, video, text, data) or combinations of media types. A Communication Message is an atomic communication exchange between two or more devices or users that contains one or more media types (including audio, video, text, data).
  • With SIP, as well as the other Internet-based technologies, a user is able to have different identities. For instance, different identities are given to family, friends, co-workers, etc. And, communication filtering and diverting services are provided, based upon which identity to which a particular communication is addressed. A user, e.g., configures a call forwarding service to permit an address provided to family members to reach the user directly, while other communications are handled in other manners. For instance, communications from friends are forwarded to the user's personal voicemail while, e.g., communications of co-workers are forwarded to the office phone of the user and the user's office voicemail.
  • Additionally, the user is not required to have different identities for the user's home phone, personal mobile phone, work phone, corporate mobile phone, vacation home phone, laptop computer, VoIP (Voice Over Internet Protocol) client, fax machine, etc. Instead, a user is, if desired, reachable by way of a call placed to a single identity through routing of the call to the user's desired device such as the user's home phone, personal mobile phone, work phone, laptop computer, VoIP (Voice Over Internet Protocol) client, fax machine, etc. By providing the capability of using a single identity to identify multiple devices, multiple calling numbers, or other addressing indicia, need not be known by a calling party. Business cards with multiple calling numbers and address books with multiple numbers associated with a single person need not be used or maintained.
  • An additional advantage of the use of a single identity to identify multiple devices is that a user is able to direct communication sessions or Communication Messages in which different types of media are communicated to different devices, depending, e.g., upon which device is able to make use of the communicated media. For instance, a user is able to elect to accept a video call on a laptop computer rather than on a mobile phone.
  • Various issues and challenges, however, remain with respect to communications with devices that are registered with a common identity. Procedures relating to the direction of an SIP invitation, or analogous session initiation, remain to be resolved or improved. And, e.g., procedures in operation relating to modification of an ongoing communication session also remain to be resolved or improved.
  • It is in light of this background information relating to communications in a communication system that the significant improvements of the present disclosure have evolved.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates a functional block diagram of a communication system in which an embodiment of the present disclosure is operable.
  • FIG. 2 illustrates a representation of exemplary information forming a device direction policy of an embodiment of the present disclosure.
  • FIG. 3 illustrates a representation illustrating exemplary mapping of a media type to user-preferred devices.
  • FIG. 4 illustrates a representation, similar to that shown in FIG. 3, but of other exemplary information forming a device direction policy.
  • FIG. 5 illustrates another representation, here illustrating the device direction policy indexed together with radio access types of radio networks.
  • FIG. 6 illustrates exemplary signaling generated pursuant to operation of an embodiment of the present disclosure.
  • FIG. 7 illustrates a functional block diagram representative of signaling generated during another embodiment of the present disclosure.
  • FIG. 8 illustrates a method flow diagram representative of the method of operation of an embodiment of the present disclosure.
  • DETAILED DESCRIPTION
  • The present description, accordingly, advantageously provides disclosure of an apparatus, and an associated method, by which to direct a communication session or Communication Message to a communication device of a group of devices having a common registration identity.
  • Through operation of an embodiment described in the present disclosure, a manner is provided for setting preferences for the routing of a communication session or Communication message to a selected device, or set of devices, of the group.
  • In one aspect of the present disclosure, the preferences information has a mapping of the types of media offered in the incoming communication session or Communication Message to a preferred device or set of devices. A communication session invitation, preliminary to a communication session, includes identification of characteristics of the associated communication session. A communication message, includes identification of characteristics of the media contained in the communication message. The invitation or communication message is analyzed, and the invitation or communication message is forwarded to a device identified in the preferences.
  • In another aspect of the present description, the preferences form a device direction policy that is stored at a network entity, such as an application server through which an SIP invitation, or communication message, or other analogous session initiation message, is routed. Alternatively, the device direction policy is stored at a network entity, such as user preference profile server or XDMS from which another application server through which a-SIP Invitation or other analogous session initiation message, is routed downloads the device direction policy. The SIP Invite message or communication message such as SIP Message is originated by an initiating party, and the SIP Invite or SIP message identifies an invited party together with identification of the initiating party together with the characteristics of the requested communication session or communication message, such as identification of the media types of which the communication system shall include. The Invite, or communication message, or analogous message is routed to the application server. The contents of the message are identified, and the device direction policy associated with the identity of the invited party is accessed. The policy identifies individual devices associated with the registered identity of the invited party that form preferred devices for the particular media type of a communication session. And, the SIP Invite, SIP Message or other, message is forwarded on to the identified device.
  • The device direction policy is selected by the registrant of the common registration identity or is selected by a system operator. When selected by the system operator, the application server is provisioned with the device direction policy through entry thereof by personnel of the system operator. When user-selected, a user creates the preferences, and sends the preferences to the application server. The message, for instance, is originated at a wireless device and forms, e.g., a USSD message, SIP Publish message, SIP Message message, or XCAP/HTTP request message. The USSD message, or other message, includes the preferences, i.e., entries, forming the device direction policy. In one implementation, the message includes an XML-formatted listing. Once delivered to the network, and routed to the application server, preference profile server or XDMS, the preferences are stored, subsequently to be accessed when an invitation is made to initiate a communication session or an incoming communication message is received.
  • In another aspect of the present disclosure, a mechanism is provided by which to enable on a per-session or per message basis, redirection due to a modification of the characteristics of the communication session, such as addition of an additional media type to the communication session. An inviting user requests modification of the media types of the communication session, and the message is routed to the application server, or other network entity. The media of the additional media type is then forwarded according to the preferences stored at the network entity.
  • Thereby, communications are carried out in accordance with the device direction policy that is set by the user, system operator, or other appropriate party. Modifications to an ongoing communication session are also handled according to the device direction policy.
  • In these, and other aspects, therefore, an apparatus, and an associated method, is provided for a communication device of a first device group. The first device group is comprised of at least one communication device. A device direction policy setter is configured to set, at the communication device, a device direction policy associated with the first device group that identifies device-direction handling of communication sessions or communication messages of selected media types. A memory element is configured to store the device direction policy.
  • In these, and other further aspects of the present disclosure, an apparatus, and an associated method, is provided for a communication network element that operates pursuant to a communication session or a communication message that includes at least one media type. A detector is configured to detect a request for initiation of the communication session or reception of a communication message. A memory element is configured to store a device direction policy that identifies device-direction handling of communication sessions and communication messages of selected media types. A request forwarder is configured to forward the request for initiation in conformity with the device direction policy. A request terminator is configured to send the request to terminate the ongoing communication session.
  • Referring first, therefore, to FIG. 1, a communication system, shown generally at 10, provides for communications between communication devices pursuant to a communication session, such as a communication session that includes multiple media types, viz., any combination of audio, text, and video media. In the exemplary implementation, the communication system provides for packet-based communications and, specifically, the communication systems provides for SIP (Session Initiation Protocol)-based services. In other implementations, other types of communication schemes and protocols are utilized. More generally, the communication system 10 is representative of any of various communication systems capable of communicating data between a set of communication stations, i.e., devices, in which a network entity is used to forward an initiation, re-initiation, or other message, such as an SIP Invite message or SIP Message method that are forwarded to a desired invited device of a group of devices identified by a common registration identity.
  • The communication system includes a network part, here including radio access networks (RANs) 14 and 16. The networks 14 and 16 are connected by way of a network 18, such as the Internet. Here, communications stations 22 and 24-1 through 24-N are positionable in communication connectivity to carry out a communication service. In the exemplary implementation shown in FIG. 1, the device 22 and the device 24-2 comprise wireless devices, such as wireless devices operable in a cellular mobile communication system. The device 22 forms an inviting party station, or device, and one or more of the devices 24 forms an invited device. The devices 24 are all identified by a common registration identification. But, each of the individual devices is identified by a separate address, e.g., a GRUU or individual telephone number or individual SIP URI or SIPS URI or other URI.
  • The network 18 is shown to include an application server 28 that is accessed pursuant to a communication session initiation or a communication message reception. The application-level server acts as a back-to-back user agent (B2BUA). The server thereby is capable of operation to act as the termination point for the SIP dialog and to direct, or redirect, messages to the preferred device of the invited user. Specifically with respect to an SIP-based session, a communication session is initiated with a SIP Invitation generated by the inviting device that is sent here by way of a radio air interface 32, through the radio access network 14, and through the network 18 for delivery to the application server 28. The application server 28 directs, or redirects, the Invite message on to one or more of devices 24.
  • The network includes apparatus 36 of an embodiment of the present disclosure. In the exemplary implementation, the apparatus is embodied at another network entity, or distributed amongst multiple entities of the network. The apparatus is here shown to include a memory element 38, a device direction policy setter 42, and a B2BUA (back-to-back user agent) entity 46 that operates as a detector, filter, forwarder, and terminator. The memory element includes storage locations capable of storing data forming a device direction policy 48.
  • The lines 52 and 54 are representative of policy information provided to the policy setter 42. The line 52 is representative of input information provided by a system operator, and the line 54 is representative input information provided by a device 24, here for purposes of example, by the device 24-2. In whatsoever manner that the device direction policy information is obtained, the setter operates to cause storage, at the memory 38, of information, such as in the form of the listing, the device direction policy. In one implementation, the setter comprises memory access lines that set the contents of a memory device, such as the memory element 38. The device direction policy is, for instance, indexed together with a common registration identity that is associated with the devices 24-1 through 24-N based on media types. Other commonly-referenced devices, analogous to the devices 24, have analogous policies that are also stored at the memory element. The SIP Invite, or a communication message or other session initiation message, is delivered to the application server, here represented by way of the line 58. The detector functionality of the entity 46 detects the Invite, or a communication message or other messages. And, the device direction policy of the registration identity identified in the Invite or a communication message or other messages is accessed. The device direction policy identifies to which device to forward the message based on media types. And, the forwarding functionality of the entity 46 operates to cause forwarding of the message to the device, or devices, identified in the device direction policy. Further communication operations may commence thereafter.
  • The device 24-2 includes further apparatus 66 of an embodiment of the present disclosure. Formation of the apparatus at the device 24-2, which is a wireless device, is exemplary. The apparatus, or analogous functionality, is also, or alternately, positioned at other devices 24 which are any kind of SIP enabled devices. The elements forming the apparatus are functionally represented, implementable in any desired manner, including, for instance, by algorithms executable by processing circuitry. The apparatus includes a device direction policy setter 68, a memory element 72, a message generator 74, and transceiver (TX/RX) circuitry 76. The memory element includes storage locations for data forming a device direction policy based on media types for the devices 24 that share the common registration identity. The setter receives information, here indicated by way of the line 82, that is, e.g., provided by user input by way of a user interface (not shown). In one implementation, the setter comprises memory access lines that are used to set the contents of a memory device, such as the memory element 72. The information provided to the setter 68 permits the setter to set device direction policy that is stored at the memory element 72. The device direction policy is represented by the block 84. The policy stored at the memory is provided to the message generator 74 that generates a message, e.g., a SIP Publish message, a SIP Message message, XCAP/HTTP request message, or USSD message, that is provided to the transmit part of the transceiver circuitry 76 and is sent, here by way of a radio air interface 88, to the radio access network and forwarded to the application server 28. The information contained in the message is provided, represented by the line 54, to the setter 42 of the application server. When the device direction policy, stored and maintained at the application server or other network entity, such as a user preference profile server on XDMS, is user-input, the apparatus 66 maintained at the device 24 is utilized and operated in the manner just-described. Operation of an embodiment of the present disclosure, including the embodiment shown in FIG. 1, provides a manner by which to cause an invitation to a session to be directed to the preferred device of a user based upon the media type or types offered in the Invitation. Also, in an ongoing session that uses one or more media types, if a re-invitation containing an offer is received for the same session that adds or modifies one or more media types, the new media type is able to be routed to a different device from the one currently in the session. For example, if a user is receiving an audio session on a mobile phone and the user wishes to accept an added video streaming media on another device, such as a laptop computer of the user, the additional media is routed thereto. Also, in ongoing sessions that use more than one media types, a user may request to redirect one of communication sessions based on media type to another device. The application server terminates the previously ongoing one of sessions which will be routed to a new device, establishes a new session to the new device and redirects the messages based on the media type to the new device. For example, if a user is receiving an audio session and a video session on a mobile phone and the user wishes to redirect the video session to another device, the ongoing video session is terminated on the original device. And then the new video session is established to a new device and additional video media is routed to the new device. Operation of an embodiment of the present disclosure therefore satisfies various requirements of the OMA-RD_COM-V10-20070927-D specification, specifically CPM-MLD-002, CPM-MLD-006, and CPM-MLD-012. CPM-MLD-002 states that the CPM enabler shall be able to deliver continuous media to all or a subset of the devices with which the CPM user is registered based on media characteristics, communication capabilities, user preferences, and/or service provider's policy. CPM-MLD-006 states that the CPM enabler shall be able to deliver a CPM session invitation to all or a subset of the devices of the CPM user dependent upon the user's preferences, device capabilities, and/or service provider's policy. CPM-MLD-012 states that the CPM enabler shall allow a CPM user to choose which of his/her devices shall be used for the added/modified continuous media within the current CPM session.
  • The simplest basic SIP session case is between the devices, here the devices 22 and 24, of two users with only SIP proxies that do not perform application level functions. Using the basic SIP session case without any intermediate application level function, and without operation of an embodiment of the present disclosure, any redirection of sessions or communication messages to provide a solution to this problem would require that the inviting user's device support the functionality to redirect sessions and/or communication messages to individual devices of the invited user and support redirection of one of the media types of a session to another device of the invited user. There would likely be charging implications on the inviting user if multiple separate SIP dialogs are established between the inviting user's terminal and the separate devices of the invited user as each dialog would likely be billed as a separate session, particularly if the inviting user is using an expensive bandwidth connection like those in mobile networks.
  • An embodiment of the present disclosure permits the invited user to redirect the session or certain media types of the session and/or communication messages, and the service provider of the invited user or receiving user provides the application level server 28 and apparatus 36. The solutions for redirection of the session or certain media types of the session and/or communication messages are based upon the use of the application level server 28 that includes, and acts as a back-to-back (B2BUA), and hence is able to terminate the SIP dialog and redirect sessions and/or communication messages to the appropriate device or devices 24 of the invited user.
  • The user has, e.g., terminals 24 that support Globally Routable User Agent URIs (GRIUs), as per draft-ietf-sip-gruu, which allow the user to register all of the user's devices 24 with a single identity (URI) but address them individually using the GRUU that uniquely identifies the device. Alternatively the user has, e.g., terminals that use separate URIs or telephone numbers but the user also registers all these devices with a single URI that can be used to address the user.
  • When the user receives an invitation to a session, the session is directed to the preferred device 24 of the user based upon the media type or types offered in the Invitation. When the User receives an incoming communication message, the communication message is directed to the preferred device 24 of the user based upon the media type or types indicated in the communication message. The server 28 supports the ability for the user to set user preferences, e.g., expressed as XML documents derived from the IETF's Common-Policy and its extensions, and/or the service provider to set policy in order to configure which device or devices 24 of the user are invited to the session based on the media characteristics of the session, and shall here be given the name Media tokens. The Media tokens include, e.g.: media characteristics, Service Communication ID. With the Media token, the user is also able to communicate a Public User Identity, whereby the Public user ID includes, e.g.: GRIUs, SIP URIs or SIPS URI or Telephone Numbers (TEL URI) or other URI or an instance ID e.g. MAC address, IMEI, PIN, ESN etc. the Communication Capabilities of the devices. The IETF's common-policy and its extensions in OMA PAG and ETIS TISPAN WG3 and XCAP, per RFC 4825, or some other mechanism, such as a web based interface or the SIP Publish mechanism, RFC 3903, is used to transfer the user preferences that configure which device or devices 24 are invited. The user preference is, e.g., stored in an XDMS or some other database that stores User Preferences. Other methods such as USSD or SMS are alternately used to set user preferences.
  • A user preference is expressed, e.g., by XML documents derived from the IETF's Common-Policy xml Schema and its extensions. The common-policy framework describes conditions, actions and transformations. Conditions allow the application server 28 to filter SIP requests. If conditions evaluate to true, associated optional transformations and/or actions are executed. Actions and transformations are application-specific. An example action comprises a ‘split-off’ of some media from a re-invite, i.e., transform the re-invite, and to originate a second invite to another UE with the split-off media, i.e. action. Alternatively, the TISPAN WG3's simservs.xsd document is used as a framework to specify management of the service.
  • The service is configured with an ordered set of rules. The XML schema (e.g. DTD, XML Schema, or other XML schema) reuses the rule syntax as specified by the common policy draft (see, e.g., RFC 4745). In one implementation, the rules take the following form:
  • <?xml version=″1.0″ encoding=″UTF-8″?>
    <cp:ruleset xmlns=″urn:ietf:params:xml:ns:common-policy″>
       <cp:rule id=″rule66″>
        <cp:conditions>
          condition1
          condition2
        </cp:conditions>
        <cp:actions>
         <split-media m=”<some media>”>
          <target>
           targetAddress1
          </target>
         </split-media>
        </cp:actions>
        <cp:transform>
         <split-media m=”<some media>”/>
        </cp:transform>
       </cp:rule>
    </cp:ruleset>
  • The above service is performable at any time or is performed automatically, e.g., if the user reconfigures user's device where the ruleset//rule//action//split-media element (if present) initiates a session towards targetAddress1 comprising certain media and the ruleset//rule//transformation//split-media element (if present) initiates a session towards the original targetaddress comprising other or remaining media.
  • The service is configured with an ordered set of rules. The XML schema reuses the rule syntax as specified by the common policy draft (see, e.g., RFC 4745). In one implementation, the rules take the following form:
  • <?xml version=″1.0″ encoding=″UTF-8″?>
    <cp:ruleset xmlns=″urn:ietf:params:xml:ns:common-policy″>
       <cp:rule id=″rule66″>
        <cp:conditions>
          condition1
          condition2
        </cp:conditions>
        <cp:actions>
         <split-media csi=”icsi1,icsi2”>
          <target>
           targetAddress1
          </target>
         </split-media>
        </cp:actions>
        <cp:transform>
         <split-media csi=” icsi3,icsi4”/>
        </cp:transform>
       </cp:rule>
    </cp:ruleset>
  • The above service is performable at any time or is performed automatically, e.g., if the user reconfigures user's device where the ruleset//rule//action//split-media element (if present) initiates a session towards targetAddress1 comprising certain Communication Service IDs (e.g. icsi) and the ruleset//rule//transformation//split-media element (if present) initiates a session towards the original targetaddress comprising other or remaining Communication Service IDs (e.g. icsi).
  • In the particular case of ICSI used to indicate the IMS communication service, the values indicated in the XML extension element to IETF common-Policy (e.g. in //split-media element's csi parameter in the example) can be matched against the ICSI as represented in the IMS SIP method (e.g. P-Asserted-service value or Accept-Contact or other header field).
  • In the particular case of ICSI used to indicate the IMS communication service, the values indicated in the XML extension element to IETF common-Policy (e.g. in ...//split-media element's csi parameter in the example) can be matched against the value within quotes of the g. ims.app_ref media feature tag as defined in subclause 7.9.2 of 24.229 and RFC 3840.
  • When a Communication Service ID (e.g., IMS Communication Server Identifier (ICSI)) is sent from the UE to the network, the Communication Service ID shall implicitly define a set of media characteristics. FIG. 2 illustrates exemplary information forming a listing 102 that is stored at the application server. The column 104 lists communication service identifications (IDs), and the column 106 identifies user preferences.
  • The user preference information, in an exemplary implementation, has a mapping of media types offered in the incoming session or communication message to a selected device or devices 24. The device identifiers comprise, e.g., GRIUs, SIP URIs or SIPS URI or Telephone Numbers (TEL URI) or other URI. When an incoming Invitation or communication message arrives at the application server 28, the server compares the media types identified in the invitation or communication message and routes the Invitation communication message to the addresses, e.g., the GRUU, SIP URIs, SIPS URI or Telephone Numbers (TEL URIs) that correspond to the media type or types listed in a User Preference mapping. FIGS. 3 and 4 illustrate exemplary listings 112 and 114 that identify exemplary user preferences, shown in the columns 116 of the listings 112 and 114. The user preferences are indexed together with media types in the listing 112, and the user preferences are indexed together with device capabilities in the listing 114.
  • In an alternate implementation, the user preference information contains a mapping between media types and media feature tags (as per, e.g., RFC 3840), and the user's device 24 registers media feature tags for those media capabilities that the device supports. In this case when the incoming Invitation or communication message arrives at the server 28, the server compares the media types in the invitation and adds an Accept-Contact header (see, e.g., RFC 3841) to the invitation or communication message containing the media feature tags that correspond to the media type listed in a user preference mapping before forwarding the invitation, or multiple invitations communication messages. The Accept-Contact header causes the SIP network to route the invitation or communication message to those devices that have explicitly registered those media feature tags (as per, e.g., RFC 3840 and RFC 3841). This implementation differs from procedures conventionally provided pursuant to RFC 3840 and RFC 3841 as the conventional procedures only provide for the inviting user's device 22 indicating caller preferences in an Accept-Contact header. However, in many cases, the inviting user's device does not support RFC 3841. Also, RFC 3841 teaches only a manner for an inviting user to request to reach a device with certain capabilities based on the inviting user's preferences. Here, in contrast, it is the invited user that sets the preferences and the RFC 3841 and RFC 3840 mechanisms are used to route the session to the devices that support certain capabilities.
  • The accept-contact header information is, e.g., mapped to common-policy documents set forth above. This would be an internal representation allowing a user or administrator to modify the representation using various mechanisms. Concurrent access to the same rules needs to be guarded in order to prevent user experiences inconsistent with the user's expectation. For example, using Accept-Contact mapping, a set of rules with unique rule-ids and priority are created that do not interfere with rules created using other mechanisms. An alternative would be to allow Accept-Contact resulting rules, i.e., rules active for the period of the registration or rules active until the next modification, to override rules provisioned using other mechanisms. Some rules apply to all UEs registered with a particular range of public user identifiers and some rules, e.g. those resulting from mapping accept-contact information to common-policy or another representation, apply only to a particular UE.
  • The setting of the preferences is, in one implementation, is automatic and is performed by the device. E.g., when comprised, of a UE, the setting is performed at the time of registration, whereby the tokens communicated in the SIP REGISTRATION message are passed to the application server 28 via a third party registration and subscription to a Reg Event package. In this variation on the above techniques, the server subscribes to the registration event package using the mechanisms specified in RFC 3680 and draft-ietf-sipping-gruu-reg-events in order to determine the capabilities of the devices and their corresponding addresses, e.g., GRIUs, SIP URIs, SIPS URI or Telephone Numbers (TEL URIs). The server is then able to route the invitation or communication message based upon the media types in the invitation to the devices that indicated support for those media types/capabilities in the registration event package. The user may enable this selective routing based on the User Preferences.
  • A device comprising a UE can change its characters by moving from one Radio Access Type (RAT) to another, in that a UE that was once capable of supporting video over I-WLAN is now using GPRS over GERAN. As such, the application server 28 may well need to alter the settings based on where the UE is positioned.
  • FIG. 5 illustrates another representative listing 124. Here, the listing stored with the application server indexes, together with the Media tokens, identification of a list of acceptable RAT types, shown in the column 126, that media can be delivered over. While, not shown, a listing analogous to the listing 124 instead identifies which media tokens are not allowed over a RAT.
  • Here, when the UE registers in the SIP REGISTER, a P-Network-Access-Info header is provided. This information is communicated to the application server 28 so that the application server can adapt its routing tables. Alternately, the application server subscribes to a presence function or a domain selection function to determine the RAT in which the UE is registered.
  • In one implementation, a UAprof is used to communicate the device capability information to the application server. Thus, after the UE registers with the network, the UE communicates its capabilities via the UAprof or some other mechanism.
  • And, in one embodiment, the user is able to interrogate, activate and deactivate the settings in the network. Furthermore, given that a user may have many Public User IDs, one of the User IDs may be in use by another person, e.g., a family member. Thus, the application server 28 only divulges the settings for a Public User ID to the person who created that setting or a person that is using that public user ID. Thus, when the application server receives a request to interrogate the user preferences in the network, the server performs:
  • Public User received = one stored
      Yes show configuration information for that public user ID
    Private User ID received = one stored
      Yes show all configuration information provided by that Private
      user ID
  • The user is also be able to set a master Private User ID that, by default, states who can change settings for all public users' IDs whereby other public users' IDs can only change their settings.
  • In an exemplary GSM-based, or other, implementation, USSD is used in the CS (circuit-switched) domain to activate, interrogate, deactivate, modify the user policy. XCAP or SIP PUBLISH, MESSAGE can be used in the IMS domain. The USSD or SIP message contains, e.g., the following information elements: a subscriber ID, e.g., IMSI; a terminal ID, e.g., an IMEI; a combination of the above, e.g., a GRUU; an action being taken, such as activate, deactivate, modify, or interrogate, and a policy information (Public User ID, Media Token). FIG. 6 illustrates a signaling diagram, shown generally at 140, representative of exemplary signaling using USSD-formatted messaging. A communication device 22, here a mobile device, generates and sends a USSD message 142 that includes a subscriber ID, a device ID, service data, and other information. The message is routed through radio access network elements, here including a base transceiver station (BTS) 144 and a base station controller (BSC) 146 for delivery to an MSC/VLR (Mobile Switching Center/Visited Location Register) 148. The MSC/VLR forwards on the message information as the message 152 for delivery to the access server 28. A response message 154 is returned to by the access server 28 to the MSC/VLR 148. And, the MSC/VLR forms a USSD-formatted message 156 that includes the response information to the device 22.
  • Analogously, the user is also able to deactivate policies. The user is able to set, e.g., the following preferences: policies for all registered Public User IDs; and policies for public user IDs listed.
  • The user is also able to deactivate policies. When the user deactivates policies, the user is able to set the following preferences: policies for all registered Public User IDs; and policies for public user IDs listed.
  • The user is also able to register settings in the network in the exemplary embodiment. the following are returned and displayed:
  • Public User ID A
      Media Token A
    Public User ID B
      Media Token A
      Media Token B
    Instance ID
      Device Capabilities
  • The user, in the exemplary implementation, is further able to modify policy settings.
  • The examples are in eight-bit binary. Alternately, four-bit binary, or another scheme, is instead used. Also, in one implementation, the information is coded in XML. An exemplary, general syntax is:
  • Operation to perform
      ETag, rule ID
      Length
        Length
          Choice (Public User ID|Instance ID)
        Number of Media Tokens
          Length Media Token A
            Media Token A
          Length media token N
            Media Token N
    Private User ID:
      Public User ID Token1
        Media Token A
        Media Token B
        Etag
    Public User ID Token2
        Media Token C
        Media Token D
        Etag
  • In one implementation, XCAP is used to manage media forwarding policies stored on servers or stored behind aggregation servers, such as, e.g., in an XDM architecture, in which policies are actually stored on UEs rather than servers, or a combination thereof. XCAP is mappable to USSD.
  • The user/operator preferences, as described above, are stored in a device 24. When the device comprises a UE, information is stored in the memory of a fixed memory element of the UE, or the information is stored on a removable memory module such as but not limited to: (U)SIM, Compact Flash, Memory Stick, MicroSD, R-UIM, UICC etc.
  • In one implementation, when the information is provisioned in the network, the network sends a configuration message to all the devices 24 where one of the Public User IDs is registered. This configuration message is constructed, e.g., using proprietary encoding, e.g., OTA over SMS or USSD etc or using OMA DM. A UE is further configured, e.g., to have a local copy of the latest received/modified rules as stored in the network in Common-Policy XML format or another representation. XCAP uses the Etag mechanism to indicate that rules as known to the UE have changed. A mapping of Etag to other transports mentioned above ensures that the UE is not changing ‘yesterday's’ rules. In short, for example, the UE will attempt to change a rule identified by its id. and add the Etag as stored on the UE to the request. If the Etag is not the same as the one stored on the server, the server informs the UE and possibly presents the rule as stored on the server. If the Etag is the same, the request of the UE succeeds and a new Etag is generated and returned to the UE, for storage on the UE.
  • Alternatively, modified rules are pushed to all devices known to have local representation of the identified rules, upon change.
  • With respect to a modification of an ongoing session, once a user has accepted a session on one or more of the devices 24, the decision made as to where to route additional media types or modified media types is influenced by the fact that the user has already accepted the session on one device 24 and based of the nature of the session the user may choose, on a per session basis, to decide whether to accept the session on the same device or redirect the session to another device.
  • An embodiment of the present disclosure further provides a mechanism that enables on a per session basis, a user to redirect the addition or modification of a new media type for that session to another device of the user. FIG. 7, for instance, illustrates a scenario in which the inviting device 22 sends an Invite (Invite(Text)) that is provided to the server 28 and then text information (TEXT) is forwarded on to a selected device 24-1 with which a text-based communication session commences. Subsequently, a Re-Invite (Re-Invite(Video)) is sent for an additional media type, here to modify the session to include video. The additional media service session is carried out with the device 24-2. A SIP Invite (SIP INVITE) is sent to the selected device 24-2 and video (VIDEO) is then provided to the device 24-2.
  • For the case when the user receives an invitation, a communication message, or a re-invitation, e.g., a SIP INVITE request that creates a new SIP dialog or that is received on the existing SIP Dialog of the existing SIP session, offering to establish a new Communication Session or add a new media type or modify an existing media type, the user's device sends a SIP 3xx, e.g., a SIP 300 (Multiple Choices) response or SIP 302 (Moved Temporarily response) or other SIP 3xx response. The SIP 3xx response includes one or more contact headers containing the GRUU, SIP URI, SIPS URI or Telephone Number (TEL URI) or other URI of the device or devices the user wishes the communication server to redirect the re-invitation to. Upon receiving the 3xx response the communication Server invites the device or devices specified in the Contact(s) in the 3xx response. In addition the contact header(s) may contain one or more media tokens that indicate the media types that indicate the media types that are to be redirected to the associated contact. When the additional device accepts the session with a 200 OK response, the Communication Server sends a 200 OK response back on the SIP dialog with the inviting user.
  • One embodiment includes such a directive as part of the SIP 3xx body as noted below.
  • <?xml version=″1.0″ encoding=″UTF-8″?>
    <cp:ruleset xmlns=″urn:ietf:params:xml:ns:common-policy″>
    <cp:rule id=″f3g44r3″>
    <cp:actions>
     <split-media m=”<some media>”>
      <target>
       targetAddress1
      </target>
     </split-media>
    </cp:actions>
    <cp:transform>
     <split-media m=”<some media>”/>
    </cp:transform>
    </cp:rule>
    </cp:ruleset>
  • Another embodiment indicates the media lines that are to be sent to another UE in the SDP. Multiple SDP bodies (i.e. requiring m-part support) can be included each indicating also the ‘target; address’ as noted below.
  • SIP3xx method
    [..]
    SIP body start
      SIP m-part body 1 start
        <SDP body A>
      SIP m-part body 1 end
      SIP m-part body 2 start
        <target address 1>
      SIP m-part body 2 end
      SIP m-part body 3 start
        <SDP body B>
      SIP m-part body 3 end
      SIP m-part body 4 start
        <target address 2>
      SIP m-part body 4 end
    SIP body end

    Or with recursive multipart bodies:
  • SIP3xx method
    [..]
    SIP body start
      SIP m-part body 1 start
        SIP m-part body 1a start
          <SDP body A>
        SIP m-part body 1a end
        SIP m-part body 1b start
          <target address 1>
        SIP m-part body 1b end
      SIP m-part body 1 end
      SIP m-part body 2 start
        SIP m-part body 2a start
          <SDP body A>
        SIP m-part body 2a end
        SIP m-part body 2b start
          <target address 1>
        SIP m-part body 2b end
      SIP m-part body 2 end
    SIP body end
  • In an alternative implementation the Re-INVITE is not sent to the user. Rather, the application server 28 already has knowledge as to how to handle the new or modified media. In this situation, the communication server shall send SIP INVITE to the appropriate devices (per configuration information).
  • Thus the inviting user that requested the addition of a new media type to the session is informed that the invited user has accepted the session but is unaware that the session is now connected to multiple devices of the invited user. When the communication server 28 receives the different media types for the session, the server filters each media type from messages, forwarding different media to the different devices of the user. E.g., text media type messages are forwarded to the device 24-1, and video media type messages are forwarded to the device 24-2.
  • A variation on this scenario comprises a communication message, an invitation, or a re-invitation that contains an offer to add or modify more than one media type. In this case the user is able to choose to redirect one media type, e.g., audio, to one device, such as the device 24-2, and the other media type, e.g., video, to another device, such as the device 24-N. The SIP 300 (Multiple Choices) response can contain a body. This body contains a list of contacts and corresponding media types, e.g., using media feature tags. The media types in the body identify the contact or contacts that the user wishes the communication server 28 to send an Invite to or the communication message to for that Media Type or types. The contacts comprise, e.g., the GRUU, SIP URI, SIPS URI or Telephone Number (TEL URI) or other URI of the device. Using the SIP 300 response with this message body, the user is able to specify that one Invitation or communication message with one media type is sent to one device and another Invitation or communication message containing another media type is sent to another device. When the communication server receives the SIP 300 (Multiple Choices) response, the server uses the body to determine which contact or contacts to send Invites or communication messages containing specific media types. For a situation in which the re-invitation contains an offer to add more than one media type and the user chooses to accept one media type, e.g., audio) on the current device, such as the device 24-1 and the other media type, e.g., video, on another device, such as the device 24-2, the SIP 300 (Multiple Choices) response body contains the contact of the current device along with the contact of the other device with the media type to be routed to each device associated with that contact. The communication server then re-invites the current device with an offer containing just those media types associated with the contact of the current device in the SIP 300 (Multiple Choices) response body and sends an invitation to the other device containing the media types associated with the contact of the this device in the SIP 300 other (Multiple Choices) response body. Note that in the case the session is already associated with the additional device, then the communication server 28 would re-invite that device using the existing dialog.
  • In the case in which the media type is modified for a communication session and redirected to another device resulting in no active session on the current device, the current device sends a SIP BYE to the communication server. Or, the communication server sends a SIP BYE to the current device after the session has been transferred to the new device. The body in the SIP 300 Response is, e.g., in XML format or some other encoding.
  • In an alternate implementation, the SIP REFER method (as per, e.g., RFC 3515) is used to by the invited user's device to request the communication server to send invitations with offers of different Media Types or communication messages to different devices of the user. The SIP REFER request contains, e.g., a recipient-list body (per draft-ietf-sip-multiple-refer). This body contains a list of URIs which can be GRIUs, SIP URIs, SIPS URI or Telephone Numbers (TEL URI) or other URIs and these URIs can contain a Method parameter that contains the SIP method for the Communication Server to send to that URI entry in the list. The URI can also contain a header parameter that can contain the headers of the SIP request including the session description in a header parameter known as “body”, and, thus, the invited device or receiving device can include the media type in the header parameter, e.g., within the session description of the SIP INVITE or the Content-Type of the SIP MESSAGE. This is based upon RFC 3261 text as follows:
  • Headers: Header fields to be included in a request constructed
      from the URI.
     Headers fields in the SIP request can be specified with the “?”
     mechanism within a URI. The header names and values are
     encoded in ampersand separated hname = hvalue pairs. The
     special hname “body” indicates that the associated hvalue is
     the message-body of the SIP request.
  • The SIP REFER request is sent within the same dialog as the invitation, or re-invitation, or the request is sent outside of any dialog and for the case of a communication session the Target-Dialog header (as per, e.g., RFC 4538) can be used to associate the SIP REFER request with the original dialog on which the invitation or re-invitation was received. The use of the Target-Dialog header allows the communication server to authorize the SIP REFER request and associate the invitations sent as a result of it to the session originally established. If needed, as above, the original device sends an Invitation back to itself in order to modify the media type of the existing session by including it own URI (GRUU, SIP URI, SIPS URI or Telephone Number (TEL URI) or other URI in the entry in the recipient list and including the Replaces header (as per, e.g., RFC 3891) in order to indicate that the new dialog initiated as a result of the REFER should replace the existing dialog and existing session. In this case as well as the case that the Media Type is modified and redirected to another device resulting in no active session on the current device, the current device sends a SIP BYE to the Communication Server or the Communication Server sends a SIP BYE to the current device after the session has been transferred to the new device. Note when the added media type or types is only redirected to one other device, the SIP REFER request does not need to include a body containing a recipient list as the URI of the device that the new media type is redirected to can be include in the Refer-To header in the SIP REFER request. The URI in the Refer-To header also contains, e.g., the method parameter including the INVITE and the header parameter “body” including the session description as described previously.
  • As in the previous-described scenario, when the additional device accepts the session with a 200 OK response, the communication server sends a 200 OK response back on the SIP dialog with the inviting user. Thus the inviting user that requested the addition of a new media type to the session is informed that the invited user has accepted the session but is unaware that the session is now connected to multiple devices of the invited user. When the communication Server receives the different media types for the session or communication messages it filters each media type from messages, forwarding different media to the different devices of the user, e.g., text media type messages are forwarded to the communication device 24-1 and video media type messages are forwarded to the communication device 24-2.
  • Analogous techniques are also applicable to SIP MESSAGE method with SIP INVITE method replaced by SIP MESSAGE method. Further, in other implementation, other SIP METHODS such as SIP MESSAGE or SIP PUBLISH are substituted for REFER in the description given hereinabove.
  • In the above scenario, it is also possible that, when the application server detects a change of RAT via session continuity, the application server performs the above operations on behalf of the user. In that the server sends a Re-INVITE to the party that is not moving RATs.
  • The server can further be configured such that, when the server detects a session continuity with specific parameters, the server redirects some or all of the media types to different devices. Take for example an example in which a user is outside in a video call and then moves into a house. The UE then performs a session continuity onto the WLAN in the house. The UE will perform a SIP REGISTRATION and this will cause the server to be updated with the UE's access technology. The server may release that the UE is at home and then could either prompt the user if they want to transfer the video to the TV and, if so, request transfer the video per solutions described above; or automatically transfer the video to the TV per solutions described above.
  • FIG. 8 illustrates a method flow diagram, shown generally at 214, representative of the method of operation of an embodiment of the present disclosure. The method facilitates communication of a communication device of a first device group comprised of at least one communication device.
  • First, and as indicated by the block 216, a device direction policy associated with the first device group is set at the communication device. The device direction policy identifies device direction handling of communication sessions or communication messages of selected media types. Then, and as indicated by the block 218, the device direction policy is stored at the communication device.
  • The device direction policy is stored, indicated by the block 222, at a communication network. The device direction policy stored at the network, e.g., is provided thereto by the communication device. Then, and as indicated by the block 224, a request for initiation of a communication session or reception of a communication message is detected. The device direction policy is accessed, indicated by the block 226. And, as indicated by the block 228, the request for initiation is forwarded in conformity with the device direction policy.
  • Presently preferred embodiments of the disclosure and many of its improvements and advantages have been described with a degree of particularity. The description is of preferred examples of implementing the disclosure, and the description of preferred examples is not necessarily intended to limit the scope of the disclosure. The scope of the disclosure is defined by the following claims.

Claims (25)

1. Apparatus for a communication device of a first device group comprised of at least one communication device, said apparatus comprising:
a device direction policy setter configured to set at the communication device a device direction policy associated with the first device group that identifies device-direction handling of communication sessions of selected media types; and
a memory element configured to store the device direction policy.
2. The apparatus of claim 1 wherein said device direction policy setter is further configured to set the device direction policy responsive to network-generated instructions.
3. The apparatus of claim 1 wherein said device direction policy setter is further configured to set the device direction policy responsive to device-provided instructions.
4. The apparatus of claim 1 wherein said device direction policy setter is further configured to set user preference information.
5. The apparatus of claim 4 wherein said user preference information comprises a device-identifying information.
6. The apparatus of claim 4 wherein the user preference information further comprises media feature tags that identify communication-device-supported media capabilities.
7. The apparatus of claim 1 further comprising a policy message generator configured to generate messages including a policy message that identifies the device direction policy.
8. The apparatus of claim 1 wherein the device direction policy comprises a plurality of entries, each entry associated with at least one selected media type.
9. The apparatus of claim 1 wherein the device direction policy further comprises identification of device-direction handling of modifications of communication sessions.
10. The apparatus of claim 1 further comprising a message generator configured to generate a policy message that further identifies the device direction policy pursuant to communication session modification.
11. A method in a communication device of a first device group comprised of at least one communication device for facilitating communication, said method comprising:
setting a device direction policy associated with the first device group that identifies device-direction handling of communication sessions of selected media types; and
storing the device direction policy.
12. The method of claim 11 further comprising:
generating a message that identifies the device direction policy.
13. An apparatus for a communication network element that operates pursuant to a communication session that includes at least one media type, said apparatus comprising:
a detector configured to detect a request for initiation of the communication session;
a memory element coupled to the detector, the memory element configured to store a device direction policy that identifies device-direction handling of communication sessions of selected media types; and
a request forwarder coupled to the memory element, the request forwarder configured to forward the request for initiation in conformity with the device direction policy.
14. The apparatus of claim 13 wherein said detector is configured to detect a SIP, Session Initiation Protocol, Invitation message.
15. The apparatus of claim 14 wherein the SIP, Session Initiation Protocol, Invitation message comprises identification of at least one media type of the communication session.
16. The apparatus of claim 13 further comprising a filter configured to filter each media type from a message.
17. The apparatus of claim 13 wherein said memory element is configured to store a device-selected device direction policy which includes the user preference information.
18. The apparatus of claim 13 wherein said memory element is configured to store a network-selected device direction policy.
19. The apparatus of claim 13 wherein the device direction policy comprises a plurality of entries, each entry associated with at least one selected media type.
20. The apparatus of claim 13 wherein the device direction policy further comprises identification of device-direction handling of modifications of communication sessions.
21. The apparatus of claim 13 wherein said detector is further configured to detect a request for modification of the communication session.
22. The apparatus of claim 21 wherein said request forwarder is further configured to forward the request for modification.
23. The apparatus of claim 13 wherein said message generator is further configured to generate a SIP INVITE for transmission in conformity with a device direction policy.
24. The apparatus of claim 13 wherein said message generator is further configured to generate a SIP BYE to terminate an old session whose media type message is redirected to a new session.
25. A method for facilitating communication pursuant to a communication session by way of a communication network, said method comprising:
detecting a request for initiation of the communication session;
accessing a device direction policy that identifies device-direction handling of communication sessions of selected media types; and
forwarding the request for initiation in conformity with the device direction policy.
US11/952,921 2007-12-07 2007-12-07 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity Abandoned US20090150562A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/952,921 US20090150562A1 (en) 2007-12-07 2007-12-07 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US11/952,921 US20090150562A1 (en) 2007-12-07 2007-12-07 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
EP08150155.3A EP2068532B1 (en) 2007-12-07 2008-01-10 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
EP12154938.0A EP2456170B1 (en) 2007-12-07 2008-01-10 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
EP12154939.8A EP2456171B1 (en) 2007-12-07 2008-01-10 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
CA2847920A CA2847920C (en) 2007-12-07 2008-12-04 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
CA2710936A CA2710936C (en) 2007-12-07 2008-12-04 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
PCT/US2008/085580 WO2009073812A2 (en) 2007-12-07 2008-12-04 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US13/617,511 US9264452B2 (en) 2007-12-07 2012-09-14 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US13/617,288 US20130013735A1 (en) 2007-12-07 2012-09-14 Apparatus and Method for Directing a Communication Session to a Communication Device of a Group of Devices Having a Common Registration Identity
US13/955,095 US9935985B2 (en) 2007-12-07 2013-07-31 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity

Related Child Applications (3)

Application Number Title Priority Date Filing Date
US13/617,511 Continuation US9264452B2 (en) 2007-12-07 2012-09-14 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US13/617,288 Continuation US20130013735A1 (en) 2007-12-07 2012-09-14 Apparatus and Method for Directing a Communication Session to a Communication Device of a Group of Devices Having a Common Registration Identity
US13/955,095 Continuation US9935985B2 (en) 2007-12-07 2013-07-31 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity

Publications (1)

Publication Number Publication Date
US20090150562A1 true US20090150562A1 (en) 2009-06-11

Family

ID=40718500

Family Applications (4)

Application Number Title Priority Date Filing Date
US11/952,921 Abandoned US20090150562A1 (en) 2007-12-07 2007-12-07 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US13/617,288 Abandoned US20130013735A1 (en) 2007-12-07 2012-09-14 Apparatus and Method for Directing a Communication Session to a Communication Device of a Group of Devices Having a Common Registration Identity
US13/617,511 Active US9264452B2 (en) 2007-12-07 2012-09-14 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US13/955,095 Active 2028-09-17 US9935985B2 (en) 2007-12-07 2013-07-31 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity

Family Applications After (3)

Application Number Title Priority Date Filing Date
US13/617,288 Abandoned US20130013735A1 (en) 2007-12-07 2012-09-14 Apparatus and Method for Directing a Communication Session to a Communication Device of a Group of Devices Having a Common Registration Identity
US13/617,511 Active US9264452B2 (en) 2007-12-07 2012-09-14 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US13/955,095 Active 2028-09-17 US9935985B2 (en) 2007-12-07 2013-07-31 Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity

Country Status (4)

Country Link
US (4) US20090150562A1 (en)
EP (3) EP2456171B1 (en)
CA (2) CA2847920C (en)
WO (1) WO2009073812A2 (en)

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090113000A1 (en) * 2007-10-29 2009-04-30 Motorola, Inc. method for requesting the termination of a communication session
US20090245492A1 (en) * 2008-03-26 2009-10-01 Avaya Technology, Llc Survivable phone behavior using sip signaling in a sip network configuration
US20090245098A1 (en) * 2008-03-26 2009-10-01 Avaya Technology, Llc Failover/failback trigger using sip messages in a sip survivable configuration
US20090245183A1 (en) * 2008-03-26 2009-10-01 Avaya Technology, Llc Simultaneous active registration in a sip survivable network configuration
US20100070563A1 (en) * 2008-03-26 2010-03-18 Avaya Inc. Registering an Endpoint With a Sliding Window of Controllers in a List of Controllers of a Survivable Network
US20100138484A1 (en) * 2008-11-28 2010-06-03 Samsung Electronics Co.,Ltd Method and system for controlling session for interworking in converged ip messaging service
US20100215036A1 (en) * 2009-02-20 2010-08-26 Samsung Electronics Electronics Co., Ltd. Method for transferring session in converged internet protocol messaging system
US20100312841A1 (en) * 2009-05-14 2010-12-09 Serhad Doken Controlling Media and Informing Controller Status in Collaborative Sessions
US20100312834A1 (en) * 2009-05-14 2010-12-09 Serhad Doken Maintaining Controllee Information in Collaborative Sessions
US20110047280A1 (en) * 2008-05-02 2011-02-24 Hyeon-Sang Eom System and method for transferring a session between multiple clients
US20110196976A1 (en) * 2008-10-21 2011-08-11 Mitsubishi Electric Corporation Communication system and communication device
US20110264813A1 (en) * 2008-09-19 2011-10-27 Brijesh Kumar Nair Method and system for managing communication session establishment
US20120016996A1 (en) * 2010-07-16 2012-01-19 Sai Samavedam Sip-based call session server and message-routing method
CN102457772A (en) * 2010-10-29 2012-05-16 华为终端有限公司 Information display method and information display device
US20120173736A1 (en) * 2009-09-18 2012-07-05 Deutsche Telekom Ag Method for supporting a user equipment lacking globally routable user agent uri - gruu support in an internet protocol multimedia subsystem - ims
US20120246311A1 (en) * 2009-12-21 2012-09-27 Nec Corporation Session management system, session management device, session management method and session management program
US20120282915A1 (en) * 2011-05-06 2012-11-08 Verizon Patent And Licensing Inc. Connecting device via multiple carriers
EP2530907A1 (en) * 2011-06-03 2012-12-05 Apple Inc. Sending Files from One Device to Another Device over a Network
WO2013048024A1 (en) * 2011-09-29 2013-04-04 Samsung Electronics Co., Ltd. Method and apparatus for communication connection service
US20130097265A1 (en) * 2010-06-23 2013-04-18 Lg Electronics Inc. Method for transferring and storing cpm service message and service thereof
US20130122955A1 (en) * 2009-01-23 2013-05-16 Qualcomm Incorporated System and method for push-to-share file distribution with previews
US20130229949A1 (en) * 2011-08-31 2013-09-05 Metaswitch Networks Ltd. Processing Requests
US20140079070A1 (en) * 2011-04-18 2014-03-20 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
US20140143314A1 (en) * 2012-11-22 2014-05-22 Hitachi, Ltd. Communication system
US20140280562A1 (en) * 2013-03-15 2014-09-18 Sorenson Communications, Inc. Communication systems and related methods for communicating with devices having a plurality of unique identifiers
WO2015126398A1 (en) * 2014-02-20 2015-08-27 Empire Technology Development, Llc Device authentication in ad-hoc networks
EP2938041A1 (en) * 2014-04-25 2015-10-28 Vodafone IP Licensing limited Method and system for selection in multi-device scenario
US9210202B2 (en) 2007-06-20 2015-12-08 Qualcomm Incorporated System and method for sharing media in a group communication among wireless communication devices
US9264452B2 (en) 2007-12-07 2016-02-16 Blackberry Limited Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US20160162568A1 (en) * 2013-07-15 2016-06-09 Samsung Electronics Co., Ltd. Method and device for forming group using communication history information
US20170013024A1 (en) * 2015-07-07 2017-01-12 T-Mobile Usa, Inc. Message Delivery Based on Subsets of Network Identities
US20170041284A1 (en) * 2015-08-03 2017-02-09 Verizon Patent And Licensing Inc. Providing a service to a user device based on a capability of the user device when the user device shares an identifier
WO2017059886A1 (en) * 2015-10-05 2017-04-13 Telefonaktiebolaget Lm Ericsson (Publ) Method for determining whether to apply a media specific action
US9674675B2 (en) 2007-06-20 2017-06-06 Qualcomm Incorporated Synchronizing floor control and media sharing in a half-duplex PTT system
US9764712B2 (en) 2014-04-09 2017-09-19 Empire Technology Development Llc Sensor data anomaly detector
EP3185617A4 (en) * 2015-10-21 2018-03-21 NEC Platforms, Ltd. Meeting management system, meeting management device, wireless terminal, meeting management method, and meeting management program

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299418A1 (en) * 2009-05-22 2010-11-25 Samsung Electronics Co., Ltd. Configuration and administrative control over notification processing in oma dm
US9237239B2 (en) * 2010-08-20 2016-01-12 Genband Us Llc Method for augmenting a voice call
GB2484922B (en) * 2010-10-25 2014-10-08 Sca Ipla Holdings Inc Infrastructure equipment and method
US9544253B2 (en) * 2014-07-09 2017-01-10 Genband Us Llc Multimedia conversation transfer
US9276982B2 (en) * 2014-07-09 2016-03-01 Genband Us Llc Multimedia conversation transfer
KR20160126388A (en) * 2015-04-23 2016-11-02 삼성전자주식회사 Electronic device and call processing method thereof

Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6188758B1 (en) * 1997-09-02 2001-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and device in telecommunications network
US20010043694A1 (en) * 2000-01-04 2001-11-22 Victor Chartrand System and method for routing calls to multi-function telephone numbers
US20020187777A1 (en) * 1999-10-15 2002-12-12 Osterhout Gregory T. Portable call management system
US20030023730A1 (en) * 2001-07-27 2003-01-30 Michael Wengrovitz Multiple host arrangement for multimedia sessions using session initiation protocol (SIP) communication
US20030039238A1 (en) * 2001-08-24 2003-02-27 Ollis Jeffrey D. Architecture for linking multiple internet protocol telephony devices having a common telephone number
US20030110234A1 (en) * 2001-11-08 2003-06-12 Lightsurf Technologies, Inc. System and methodology for delivering media to multiple disparate client devices based on their capabilities
US6625258B1 (en) * 1999-12-27 2003-09-23 Nortel Networks Ltd System and method for providing unified communication services support
US20040083291A1 (en) * 2002-10-28 2004-04-29 Pekka Pessi System and method for conveying terminal capability and user preferences-dependent content characteristics for content adaptation
US20040249951A1 (en) * 2003-04-08 2004-12-09 3Com Corporation Method and system for providing directory based services
US20050018659A1 (en) * 2003-07-23 2005-01-27 Gallant John K. Method and system for suppressing early media in a communications network
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
US20050069099A1 (en) * 2003-09-29 2005-03-31 Siemens Information And Communication System and method for providing information regarding an identity's media availability
US20050096029A1 (en) * 2003-10-29 2005-05-05 Lucent Technologies Inc. Method and system for call forwarding in multimedia telecommunication networks
US6985961B1 (en) * 2001-12-04 2006-01-10 Nortel Networks Limited System for routing incoming message to various devices based on media capabilities and type of media session
US20060105766A1 (en) * 2004-10-26 2006-05-18 Azada Maria R Method for delivering a call to a dual-mode mobile unit using a single number
US20060189340A1 (en) * 2005-01-26 2006-08-24 Samsung Electronics Co., Ltd. Method and system for guaranteeing seamless session when replacing PoC terminal in PoC system
US20060235994A1 (en) * 2005-04-15 2006-10-19 Alcatel System and method for routing communication sessions based on priority, presence and preference information
US20060235981A1 (en) * 2005-04-19 2006-10-19 Nokia Corporation Providing a second service to a group of users using a first service
US7130282B2 (en) * 2002-09-20 2006-10-31 Qualcomm Inc Communication device for providing multimedia in a group communication network
US20070250569A1 (en) * 2006-04-25 2007-10-25 Nokia Corporation Third-party session modification
US20070258477A1 (en) * 2006-05-04 2007-11-08 Lg Electronics Inc. Method and terminal for establishing PT session in order to use PT box
US20070281676A1 (en) * 2006-06-01 2007-12-06 Motorola, Inc. Multi model address book
US20080083010A1 (en) * 2006-09-29 2008-04-03 Nortel Networks Limited Method and system for trusted contextual communications
WO2008074117A1 (en) * 2006-12-19 2008-06-26 Bce Inc. Method, system and apparatus for causing a communication device to join a communication session
US20090004907A1 (en) * 2007-06-26 2009-01-01 Lucent Technologies Inc. Connector converters for portable electronic device power adapters
US20090017856A1 (en) * 2005-10-31 2009-01-15 Henrik Albertsson Transfer of Part of a Push to Talk Session
US20090049087A1 (en) * 2007-08-17 2009-02-19 Tekelec Methods, systems, and computer program products for providing a universal uniform resource identifier (UURI)
US20100217698A1 (en) * 2007-11-08 2010-08-26 Kang Jiao Charging method, network system, charging system, and application server
US20130318248A1 (en) * 2007-12-07 2013-11-28 Blackberry Limited Apparatus and Method for Directing a Communication Session to a Communication Device of a Group of Devices Having a Common Registration Identity

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60306754T2 (en) * 2003-05-21 2007-07-12 Siemens S.P.A. A method for downloading software with support for mobile sessions in mobile communication systems
FI20045175A0 (en) * 2004-05-12 2004-05-12 Nokia Corp start a session for real-time media communication service
KR20070108311A (en) * 2005-11-15 2007-11-09 삼성전자주식회사 Floor managing system, method and terminal apparatus for processing multimedia calling service in poc system
KR101250589B1 (en) * 2006-10-02 2013-04-03 삼성전자주식회사 PoC System And Method and Terminal Apparatus for Establishing and Managing Multimedia PoC Session to Processing Multimedia Calling Service
WO2008119177A1 (en) * 2007-03-30 2008-10-09 Société De Commercialisation Des Produits De La Recherche Appliquée - Socpra Sciences Et Génie Session mobility between communicating devices
CN101364883B (en) * 2007-08-06 2011-12-28 华为技术有限公司 A multi-terminal session method and communication system and related equipment

Patent Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6188758B1 (en) * 1997-09-02 2001-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Method and device in telecommunications network
US20020187777A1 (en) * 1999-10-15 2002-12-12 Osterhout Gregory T. Portable call management system
US6625258B1 (en) * 1999-12-27 2003-09-23 Nortel Networks Ltd System and method for providing unified communication services support
US20010043694A1 (en) * 2000-01-04 2001-11-22 Victor Chartrand System and method for routing calls to multi-function telephone numbers
US20030023730A1 (en) * 2001-07-27 2003-01-30 Michael Wengrovitz Multiple host arrangement for multimedia sessions using session initiation protocol (SIP) communication
US20030039238A1 (en) * 2001-08-24 2003-02-27 Ollis Jeffrey D. Architecture for linking multiple internet protocol telephony devices having a common telephone number
US20030110234A1 (en) * 2001-11-08 2003-06-12 Lightsurf Technologies, Inc. System and methodology for delivering media to multiple disparate client devices based on their capabilities
US6985961B1 (en) * 2001-12-04 2006-01-10 Nortel Networks Limited System for routing incoming message to various devices based on media capabilities and type of media session
US7130282B2 (en) * 2002-09-20 2006-10-31 Qualcomm Inc Communication device for providing multimedia in a group communication network
US20040083291A1 (en) * 2002-10-28 2004-04-29 Pekka Pessi System and method for conveying terminal capability and user preferences-dependent content characteristics for content adaptation
US20040249951A1 (en) * 2003-04-08 2004-12-09 3Com Corporation Method and system for providing directory based services
US20050018659A1 (en) * 2003-07-23 2005-01-27 Gallant John K. Method and system for suppressing early media in a communications network
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
US20050069099A1 (en) * 2003-09-29 2005-03-31 Siemens Information And Communication System and method for providing information regarding an identity's media availability
US20050096029A1 (en) * 2003-10-29 2005-05-05 Lucent Technologies Inc. Method and system for call forwarding in multimedia telecommunication networks
US20060105766A1 (en) * 2004-10-26 2006-05-18 Azada Maria R Method for delivering a call to a dual-mode mobile unit using a single number
US20060189340A1 (en) * 2005-01-26 2006-08-24 Samsung Electronics Co., Ltd. Method and system for guaranteeing seamless session when replacing PoC terminal in PoC system
US20060235994A1 (en) * 2005-04-15 2006-10-19 Alcatel System and method for routing communication sessions based on priority, presence and preference information
US20060235981A1 (en) * 2005-04-19 2006-10-19 Nokia Corporation Providing a second service to a group of users using a first service
US20090017856A1 (en) * 2005-10-31 2009-01-15 Henrik Albertsson Transfer of Part of a Push to Talk Session
US20070250569A1 (en) * 2006-04-25 2007-10-25 Nokia Corporation Third-party session modification
US20070258477A1 (en) * 2006-05-04 2007-11-08 Lg Electronics Inc. Method and terminal for establishing PT session in order to use PT box
US20070281676A1 (en) * 2006-06-01 2007-12-06 Motorola, Inc. Multi model address book
US20080083010A1 (en) * 2006-09-29 2008-04-03 Nortel Networks Limited Method and system for trusted contextual communications
WO2008074117A1 (en) * 2006-12-19 2008-06-26 Bce Inc. Method, system and apparatus for causing a communication device to join a communication session
US20090004907A1 (en) * 2007-06-26 2009-01-01 Lucent Technologies Inc. Connector converters for portable electronic device power adapters
US20090049087A1 (en) * 2007-08-17 2009-02-19 Tekelec Methods, systems, and computer program products for providing a universal uniform resource identifier (UURI)
US20100217698A1 (en) * 2007-11-08 2010-08-26 Kang Jiao Charging method, network system, charging system, and application server
US20130318248A1 (en) * 2007-12-07 2013-11-28 Blackberry Limited Apparatus and Method for Directing a Communication Session to a Communication Device of a Group of Devices Having a Common Registration Identity

Cited By (69)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9210202B2 (en) 2007-06-20 2015-12-08 Qualcomm Incorporated System and method for sharing media in a group communication among wireless communication devices
US9674675B2 (en) 2007-06-20 2017-06-06 Qualcomm Incorporated Synchronizing floor control and media sharing in a half-duplex PTT system
US20090113000A1 (en) * 2007-10-29 2009-04-30 Motorola, Inc. method for requesting the termination of a communication session
US8122090B2 (en) * 2007-10-29 2012-02-21 Motorola Solutions, Inc. Method for requesting the termination of a communication session
US9264452B2 (en) 2007-12-07 2016-02-16 Blackberry Limited Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US9935985B2 (en) 2007-12-07 2018-04-03 Blackberry Limited Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity
US8107361B2 (en) 2008-03-26 2012-01-31 Avaya Inc. Simultaneous active registration in a SIP survivable network configuration
US20100070563A1 (en) * 2008-03-26 2010-03-18 Avaya Inc. Registering an Endpoint With a Sliding Window of Controllers in a List of Controllers of a Survivable Network
US20090245183A1 (en) * 2008-03-26 2009-10-01 Avaya Technology, Llc Simultaneous active registration in a sip survivable network configuration
US20090245098A1 (en) * 2008-03-26 2009-10-01 Avaya Technology, Llc Failover/failback trigger using sip messages in a sip survivable configuration
US7995466B2 (en) * 2008-03-26 2011-08-09 Avaya Inc. Failover/failback trigger using SIP messages in a SIP survivable configuration
US20090245492A1 (en) * 2008-03-26 2009-10-01 Avaya Technology, Llc Survivable phone behavior using sip signaling in a sip network configuration
US8018848B2 (en) 2008-03-26 2011-09-13 Avaya Inc. Survivable phone behavior using SIP signaling in a SIP network configuration
US8527656B2 (en) 2008-03-26 2013-09-03 Avaya Inc. Registering an endpoint with a sliding window of controllers in a list of controllers of a survivable network
US8799486B2 (en) * 2008-05-02 2014-08-05 Samsung Electronics Co., Ltd System and method for transferring a session between multiple clients
US9906603B2 (en) * 2008-05-02 2018-02-27 Samsung Electronics Co., Ltd System and method for transferring a session between multiple clients
US20140379827A1 (en) * 2008-05-02 2014-12-25 Samsung Electronics Co., Ltd. System and method for transferring a session between multiple clients
US20110047280A1 (en) * 2008-05-02 2011-02-24 Hyeon-Sang Eom System and method for transferring a session between multiple clients
US20110264813A1 (en) * 2008-09-19 2011-10-27 Brijesh Kumar Nair Method and system for managing communication session establishment
US20110196976A1 (en) * 2008-10-21 2011-08-11 Mitsubishi Electric Corporation Communication system and communication device
US20100138484A1 (en) * 2008-11-28 2010-06-03 Samsung Electronics Co.,Ltd Method and system for controlling session for interworking in converged ip messaging service
US9118616B2 (en) * 2008-11-28 2015-08-25 Samsung Electronics Co., Ltd. Method and system for controlling session for interworking in converged IP messaging service
US8566405B2 (en) * 2008-11-28 2013-10-22 Samsung Electronics Co., Ltd Method and system for controlling session for interworking in converged IP messaging service
US20130122955A1 (en) * 2009-01-23 2013-05-16 Qualcomm Incorporated System and method for push-to-share file distribution with previews
US9246863B2 (en) * 2009-02-20 2016-01-26 Samsung Electronics Co., Ltd Method for transferring session in converged Internet protocol messaging system
US20100215036A1 (en) * 2009-02-20 2010-08-26 Samsung Electronics Electronics Co., Ltd. Method for transferring session in converged internet protocol messaging system
US20100312834A1 (en) * 2009-05-14 2010-12-09 Serhad Doken Maintaining Controllee Information in Collaborative Sessions
US20100312841A1 (en) * 2009-05-14 2010-12-09 Serhad Doken Controlling Media and Informing Controller Status in Collaborative Sessions
US9641567B2 (en) * 2009-05-14 2017-05-02 Qualcomm Incorporated Controlling media and informing controller status in collaborative sessions
US9641564B2 (en) 2009-05-14 2017-05-02 Qualcomm Incorporated Maintaining controllee information in collaborative sessions
US20120173736A1 (en) * 2009-09-18 2012-07-05 Deutsche Telekom Ag Method for supporting a user equipment lacking globally routable user agent uri - gruu support in an internet protocol multimedia subsystem - ims
US20120246311A1 (en) * 2009-12-21 2012-09-27 Nec Corporation Session management system, session management device, session management method and session management program
US8930532B2 (en) * 2009-12-21 2015-01-06 Nec Corporation Session management in a thin client system for effective use of the client environment
US20130097265A1 (en) * 2010-06-23 2013-04-18 Lg Electronics Inc. Method for transferring and storing cpm service message and service thereof
US9350695B2 (en) * 2010-06-23 2016-05-24 Lg Electronics Inc. Method for transferring and storing CPM service message and service thereof
US8364828B2 (en) * 2010-07-16 2013-01-29 Telefonaktiebolaget Lm Ericsson (Publ) SIP-based call session server and message-routing method
US20120016996A1 (en) * 2010-07-16 2012-01-19 Sai Samavedam Sip-based call session server and message-routing method
EP2627100A1 (en) * 2010-10-29 2013-08-14 Huawei Device Co., Ltd. Method and device for displaying information
US8908853B2 (en) 2010-10-29 2014-12-09 Huawei Device Co., Ltd. Method and device for displaying information
CN102457772A (en) * 2010-10-29 2012-05-16 华为终端有限公司 Information display method and information display device
EP2627100A4 (en) * 2010-10-29 2014-01-01 Huawei Device Co Ltd Method and device for displaying information
US9338090B2 (en) * 2011-04-18 2016-05-10 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
US20140079070A1 (en) * 2011-04-18 2014-03-20 Nec Corporation Terminal, control device, communication method, communication system, communication module, program, and information processing device
US20120282915A1 (en) * 2011-05-06 2012-11-08 Verizon Patent And Licensing Inc. Connecting device via multiple carriers
US8909224B2 (en) * 2011-05-06 2014-12-09 Verizon Patent And Licensing Inc. Connecting device via multiple carriers
US9888058B2 (en) 2011-06-03 2018-02-06 Apple Inc. Sending files from one device to another device over a network
EP2890089A1 (en) * 2011-06-03 2015-07-01 Apple Inc. Sending files from one device to another device over a network
EP2530907A1 (en) * 2011-06-03 2012-12-05 Apple Inc. Sending Files from One Device to Another Device over a Network
US9294546B2 (en) 2011-06-03 2016-03-22 Apple Inc. Sending files from one device to another device over a network
US9118493B2 (en) * 2011-08-31 2015-08-25 Metaswitch Networks Ltd Processing requests
US20130229949A1 (en) * 2011-08-31 2013-09-05 Metaswitch Networks Ltd. Processing Requests
US9998546B2 (en) 2011-09-29 2018-06-12 Samsung Electronics Co., Ltd Method and apparatus for communication connection service
WO2013048024A1 (en) * 2011-09-29 2013-04-04 Samsung Electronics Co., Ltd. Method and apparatus for communication connection service
US9241246B2 (en) 2011-09-29 2016-01-19 Samsung Electronics Co., Ltd. Method and apparatus for communication connection service
US20140143314A1 (en) * 2012-11-22 2014-05-22 Hitachi, Ltd. Communication system
US9491205B2 (en) * 2013-03-15 2016-11-08 Sorenson Communications, Inc. Communication systems and related methods for communicating with devices having a plurality of unique identifiers
US20140280562A1 (en) * 2013-03-15 2014-09-18 Sorenson Communications, Inc. Communication systems and related methods for communicating with devices having a plurality of unique identifiers
US10185760B2 (en) * 2013-07-15 2019-01-22 Samsung Electronics Co., Ltd. Method and device for forming group using communication history information
US20160162568A1 (en) * 2013-07-15 2016-06-09 Samsung Electronics Co., Ltd. Method and device for forming group using communication history information
WO2015126398A1 (en) * 2014-02-20 2015-08-27 Empire Technology Development, Llc Device authentication in ad-hoc networks
US9813406B2 (en) 2014-02-20 2017-11-07 Empire Technology Development Llc Device authentication in ad-hoc networks
US10005427B2 (en) 2014-04-09 2018-06-26 Empire Technology Development Llc Sensor data anomaly detector
US9764712B2 (en) 2014-04-09 2017-09-19 Empire Technology Development Llc Sensor data anomaly detector
EP2938041A1 (en) * 2014-04-25 2015-10-28 Vodafone IP Licensing limited Method and system for selection in multi-device scenario
US20170013024A1 (en) * 2015-07-07 2017-01-12 T-Mobile Usa, Inc. Message Delivery Based on Subsets of Network Identities
US20170041284A1 (en) * 2015-08-03 2017-02-09 Verizon Patent And Licensing Inc. Providing a service to a user device based on a capability of the user device when the user device shares an identifier
US10200339B2 (en) * 2015-08-03 2019-02-05 Verizon Patent And Licensing Inc. Providing a service to a user device based on a capability of the user device when the user device shares an identifier
WO2017059886A1 (en) * 2015-10-05 2017-04-13 Telefonaktiebolaget Lm Ericsson (Publ) Method for determining whether to apply a media specific action
EP3185617A4 (en) * 2015-10-21 2018-03-21 NEC Platforms, Ltd. Meeting management system, meeting management device, wireless terminal, meeting management method, and meeting management program

Also Published As

Publication number Publication date
CA2710936A1 (en) 2009-06-11
EP2456171A1 (en) 2012-05-23
EP2456170A9 (en) 2013-08-28
WO2009073812A3 (en) 2009-10-08
EP2068532A1 (en) 2009-06-10
EP2456171B1 (en) 2016-11-02
WO2009073812A2 (en) 2009-06-11
US20130013796A1 (en) 2013-01-10
US9935985B2 (en) 2018-04-03
CA2847920C (en) 2017-03-14
CA2710936C (en) 2014-06-17
US9264452B2 (en) 2016-02-16
US20130013735A1 (en) 2013-01-10
CA2847920A1 (en) 2009-06-11
US20130318248A1 (en) 2013-11-28
EP2456170B1 (en) 2015-09-30
EP2456170A1 (en) 2012-05-23
EP2068532B1 (en) 2015-12-09
EP2456171A9 (en) 2013-08-28

Similar Documents

Publication Publication Date Title
CA2609639C (en) Method and apparatus for identifying an ims service
KR101332709B1 (en) System and method for implementing media and media transfer between devices
US8923276B2 (en) Internet protocol telephony voice/video message deposit and retrieval
EP1758300B1 (en) A method of informing the capability change of the terminal to the network
US7660898B2 (en) Presence enhanced telephony service architecture
KR101332706B1 (en) System and method for implementing a transfer of control of a collaborative session using sip protocol
CN101223755B (en) Method and apparatus for allocating a server in an IMS network
US8327024B2 (en) System and method for SMS/IP interoperability
JP4700105B2 (en) Ip multimedia subsystem (ims) definitive call forwarding
US7324505B2 (en) Sustained VOIP call logs using PoC contact lists
JP4806707B2 (en) Service provisioning in a communication system
AU2007204558B2 (en) System and method for routing an incoming call to a proper domain in a network environment including IMS
EP1676399B1 (en) System and method for presence-based routing of communication requests over a network
US8880062B2 (en) Service profile handling in the IMS
AU2006211050B2 (en) Method and apparatus for transmission of user identities in a IP Multimedia Subsystem
CN1886999B (en) Method and communication system for automatically discovering the multimedia service capability
US20050170861A1 (en) Method and system to subscription of events using sip protocol
US7933994B1 (en) Extracting embedded NAIS (network access identifiers)
US9210224B2 (en) Service provisioning in a communication system
CN103220323B (en) Service control means for
JP5190072B2 (en) Group access to Ip multimedia subsystem service
US8266203B2 (en) Method for obtaining device information of user terminals and communication service function entity
CN102624735B (en) Method for routing messages via IMS
US9031067B2 (en) Routing messages
US20040006623A1 (en) Service providing mechanism

Legal Events

Date Code Title Description
AS Assignment

Owner name: RESEARCH IN MOTION LIMITED, CANADA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KIM, YOUNGAE;ALLEN, ANDREW;BUCKLEY, ADRIAN;AND OTHERS;REEL/FRAME:020572/0103;SIGNING DATES FROM 20071210 TO 20080227

AS Assignment

Owner name: BLACKBERRY LIMITED, ONTARIO

Free format text: CHANGE OF NAME;ASSIGNOR:RESEARCH IN MOTION LIMITED;REEL/FRAME:034016/0738

Effective date: 20130709