Patent Grant
10194479
Field of the Invention
The invention generally relates to IP Multimedia Subsystem (IMS) networks and, more specifically, to IMS users that use (perhaps multiple) discovered user endpoint devices.
Discussion of Related Art
Commonly deployed wireless communication networks, usually referred to as 2.5G networks, support both voice and data services. Typically, mobile handsets are connected to a Base Transceiver Station (BTS) using a Radio Access Network (RAN) that uses a modulation scheme such as CDMA (Code Division Multiple Access) or GSM (Global System for Mobile communications). The BTSs are connected via fixed links to one or more Base Station Controllers (BSCs), and the BSCs are aggregated into switches called Mobile Switching Centers (MSCs). The MSC is connected to the Public Land Mobile Network/Public Switched Telephone Network (PLMN/PSTN), typically through a gateway switch called the Gateway Mobile Switching Center (GMSC). Sometimes the term “core network” is used to collectively describe the MSC, GMSC and associated network elements. Voice traffic uses the so called circuit switched paradigm of communications in which circuits are assigned, i.e., dedicated, to a call for its entire duration; the voice traffic is carried using Time Division Multiplexing (TDM) switching technology. Signaling traffic uses Signaling System 7 (SS7) typically as out of band circuits.
With the advent of Internet Protocol (IP) networking, IP data service is offered to wireless clients by an overlay data network in which a packet control function (PCF) is introduced at the BSC level to connect BSCs to an IP-routed network. The PCF is responsible for packetization of RAN traffic. On the inbound side (core network to RAN) the PCF takes IP packets and reorganizes them for transmission as frames over the radio transport protocol. On the outbound side (RAN to core network) the PCF packetizes radio protocol frames to IP packets. Data connections are handled by this overlay network and the MSC is used primarily to handle circuit switched voice calls.
The development of Voice over IP (VoIP) technology has resulted in the MSC being re-designed to handle packet switched voice traffic along with existing circuit switched traffic. This new architecture is called a soft switch network. The legacy switch is disaggregated into a control and multiplicity of media gateway (MGW) components. The control component (sometimes called the soft switch) uses an open control protocol called the Media Gateway Control Protocol (MGCP) to manage the MGW. The MGW itself has the ability to accept both packet and circuit switched traffic and convert one to the other, under the control of the soft switch. It is thus possible in 2.5G networks to carry both circuit switched and packet switched traffic.
It is widely believed that wireless communications will soon be dominated by multimedia services. This has resulted in new RAN technologies and the resulting networks are called 3G networks. The transition of 2.5G to 3G networks emphasizes packet traffic and new architectures have been proposed to handle multimedia sessions, such as Quality of Service (QoS).
A defining characteristic of 2.5G/3G multimedia services is that since the handset can send or receive IP data packets at any time, the IP context of the handset is maintained as long as the handset is powered on and connected to the network. This is in contrast to traditional telephony where the state of a connection is maintained only while a telephone call is in progress.
In particular, in 3G networks the services are to be provided by so-called Application Servers. Consequently the connection between the service logic and the application server is a “stateful” connection that needs to be maintained for the duration of the service being used. Hence a very large number of stateful connections need to be maintained between the application server complex, hosted in the application domain, and the service logic complex hosted in the service logic domain, in a network servicing a large number of subscribers. Such stateful connections that cross administrative domains have high networking costs and are difficult to maintain operationally.
Typical of proposals for 3G network architecture is the IP Multimedia Subsystem (IMS) architecture, shown in
The basic call server called the Call State Control Function (CSCF) is logically partitioned into three functional entities, the Proxy, Interrogating and Serving CSCF.
The Proxy Call State Control Function (P-CSCF) is the first contact point for the handset, also referred to herein as the User Entity (UE,) within IMS and provides the following functions:
The Interrogating CSCF (I-CSCF) is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area. It provides the following functions:
The Serving CSCF (S-CSCF) actually handles the session states in the network and provides the following functions:
The P-CSCF is the first point of contact for a UE (handset) in an IMS network. The I-CSCF then helps in establishing which S-CSCF “owns” the UE.
The HSS provides initial filter codes (IFCs) to the S-CSCF. The IFC, in effect, maps the service codes with various application servers (ASs). Thus, if the UE later issues a service request or if the service is otherwise triggered the mapped AS will be invoked. The IFC is effectively the “call model” for the UE. These call models are static objects downloaded during registration from the HSS. Every UE in the domain of the S-CSCF will, if they have the services enabled at all, have the same application servers (ASs) mapped to the same services. For example, push-to-talk service for each and every UE having such service will point to the same AS or point to an AS with identical service logic to provide the identical push-to-talk functionality.
Registered UEs may use services by initiating a new session establishment procedure depicted in
As an illustrative example, consider the case of voice mail in which callers to a certain user may leave a voice message if the called user does not respond to the call. This voice mail service is provided by an application server (AS) dedicated to this service and having service logic to provide such functionality. The S-CSCF transfers control to the voice mail application server when a certain service point trigger (SPT) occurs, i.e., an event occurs that causes a trigger within the SPT to “fire.” The IFCs that provide trigger points to the service logic of the S-CSCF are downloaded into the S-CSCF during user registration at session initiation time and remain fixed for the duration of the session. The service profile described above that is consulted by the T-SCSCF is a static object in the sense that the information contained in it is defined once at the time of service inception.
The coverage area of a service provider is typically partitioned into geographical regions called cells. Each cell is served by a BTS, i.e., the BTS radiates energy within a cell. Allocating frequencies to cells in a judicious manner allows re-use of frequencies and, hence, to more efficient use of the operator's spectrum allocation. As a mobile handset roams across cell boundaries, its reception of the signal being radiated by the BTS varies. A crucial component of wireless communication networks is the ability to hand off a moving handset from one BTS to a neighboring BTS. Various handoff algorithms are known in the literature. Broadly speaking, all handoff technologies fall into one of two types: hard handoff, and soft handoff.
In hard handoffs the connection between the current BTS and the handset is severed and a new connection is established between a new BTS and the handset while a telephone call is ongoing. The decision to sever the old connection and start a new connection is based on a pre-determined threshold value of the received signal. In soft handoff technologies the signal strength from two (or more) BTS are compared and the one that has the higher value is selected. The main advantage that handoffs provide is that ongoing calls remain connected as the handset roams in the coverage area. Since the region in which a BTS radiates is limited, a handset that roams out of the range of a BTS will lose connection with the BTS and hence any ongoing call will be dropped. Handoffs ensure that the handset remains connected to some BTS and any ongoing calls do not get dropped.
As the bandwidth provided by wireless networks increases, it is now possible to send and receive multimedia information to handsets. Thus, handsets are no longer used only to make and receive telephone calls. Rather handsets are envisioned to send and receive multimedia information such as video clips, audio files, etc. Handsets have become general purpose computing and communication devices. Wireless networks are now expected to provide broadcast content, video telephony, multimedia conferencing, video streaming services, file upload and download services, and interactive multimedia services.
However, the availability of network coverage supporting multimedia services is highly uneven. In some areas several networks may be available simultaneously that could be used by a handset, whereas in other regions there may be insufficient coverage to support a given network service. For example, at a given location one may have several short-range Wi-Fi or WiMax networks, or 1×RTT EVDO, that could provide multimedia services to a handset (assuming that the handset is capable of supporting multiple modulation schemes).
A handset, however, has an inherent disadvantage since its form factor is generally not suitable for long term use as a display device. The small size of the handset display screen is not amenable to long duration sessions or sessions in which the handset is jointly viewed by several users. In such cases it would be desirable to view the multimedia services on a larger LCD or a TV display device. Many such devices support LAN connections directly or indirectly via commercially available media plugs. Moreover, such devices may also support short range wireless networks such as Wi-Fi and WiMax.
The wireless world is increasingly becoming a world of multiple networks. Some are short range and others support longer ranges of coverage. The information-carrying capacity of these networks varies widely from network to network. Handsets increasingly support multiple wireless connections, including both short range networks such as Bluetooth and Wi-Fi, and long range cellular networks.
The invention provides systems and methods for device discovery in IMS networks. Following discovery, the discovered device communicates information about its capabilities and network connectivity to the handset, which then relays this to a serving node that controls the IMS session in which the handset is participating. The serving node executes logic based on a set of policies to determine whether to associated the discovered device into the IMS session. If a positive determination is made, the serving node associates the discovered device with the IMS session and with the user of the handset. It then causes at least some of the IMS session content to be directed to the discovered device, while retaining the handset within the IMS session.
In general, in one aspect, the invention features a method of associating multiple user endpoints with a single IMS session in an IMS network having a serving node for controlling at least one IMS session for a user and at least a first access network for providing access to UEs. The method involves: associating a first UE with the user and with an IMS session; discovering a second UE in a proximity of the first UE; discovering information about the second UE; communicating the information about the second UE to the serving node; the serving node utilizing computer-implemented policy logic to determine whether to associate the second UE with the user and the IMS session; and if to be associated, the serving node associating the second UE with the IMS session while retaining the association with the first UE.
Other aspects include one or more of the following features. The method further includes the serving node causing an application server to utilize the second UE within the IMS session. The serving node causes the application server to utilize the second UE via the first access network and the first UE. The application server is a media server associated with the IMS session, and the media server transmits real-time streaming media to the first UE; and the first UE relays the real-time streaming media to the second UE. The serving node determines that the second UE is to be associated with the user, obtains a network address of the second UE and establishes an alternative network via a second access network connection to the second UE that does not involve the first UE. The application server utilizes the second UE by transmitting content to the second UE via the alternative network connection. The application server is a media server associated with the IMS session, and the media server transmits real-time streaming media to the second UE via the alternative network connection. After the serving node has associated the second UE with the IMS session, an application server under control of the IMS session utilizes the first and second UEs concurrently within the IMS session. The second UE is discovered as a result of a search message broadcast by the first UE or an advertising message transmitted from the second UE. The second UE is discovered by at least one of the Universal Plug and Play, Jini, RFID, and Bluetooth discovery mechanisms. The serving node determines that the content to be delivered to the second UE requires trans-coding and the serving node directs a media resource control function to establish a trans-coding session. The media resource control function transmits trans-coded real-time streaming content to the first UE for relay to the second UE. The serving node determines that the content to be delivered to the second UE requires trans-coding and directs a media resource control function to establish a trans-coding session, and the media resource control function transmits real-time streaming content to the second UE via the alternative network connection. The trans-coding alters at least one of the color resolution and the spatial resolution of the content to be delivered. The determination whether to associate the second UE with the user and the IMS session is based in part on user choice. The computer-implemented policy logic that determine whether to associate the second UE with the user and the IMS session includes rules that depend on at least one of: (i) a business relationship between the user and a provider of telecommunication services; (ii) a business relationship between the user and an owner or operator of the second UE device; and (iii) a technical specification of the second UE. The serving node associates the second UE with the IMS session and the serving node later terminates the association of the second UE with the IMS session. The termination of the association with the second UE is triggered by the second UE becoming unavailable or by the second UE leaving the proximity of the first UE, the serving node maintaining session continuity with the first UE.
Preferred embodiments of the invention permit IMS user sessions to utilize devices that are discovered by the UE during the course of an IMS session. The embodiments provide for the discovery of available devices, and for choosing whether to add a discovered device to the IMS session. The choice can be made to depend on physical and/or technical factors, such as whether the IMS session involves the use of content that could benefit from the incorporation of the associated device into the IMS session. For example, if the user is receiving video, and a large-screen TV set is discovered, it would be beneficial for the user to view the video on the large screen of the discovered TV set rather than on the small screen of a handset. In addition, the decision to include the discovered device can be made to depend on a set of policies that involve business relationships (such as of the user to owner/operator of the available devices) and cost. The described embodiments allow the signaling channel to remain intact (i.e., it is not generally handed over to an associated device) allowing for a consistent service experience (i.e., the application logic can remain in the domain of the original service provider).
The UE, P-CSCF 404, I-CSCF 406, and HSS are essentially conventional, though the content of HSS 422 is not, as described below. However, in certain embodiments, the UE may have unconventional agent logic, namely PA logic 424, and search module 426, each of which is discussed in more detail below. All of these entities communicate using known and defined protocols.
Serving node 408, in preferred embodiments, includes S-CSCF logic 410 that is largely conventional though it includes certain modifications, discussed below. Serving node 408 also includes ME server logic 412 (more below) to store users' dynamic network topologies and other information, and provisioning logic 414 more below. (Alternatively, the ME server logic and the provisioning logic may each be a separate physical entity like an AS.) The ME server and provisioning logic essentially are co-located special purpose servers within node 408. The serving node 408, and particularly provisioning logic 414, communicates with a call model database 416. This database 416 (not the HSS as is the conventional case) is used to provide the call model information for a given user (more below).
Though not shown in
The logic flow starts in 500 and proceeds to 502 in which the first service request is received after registration. Because of the default IFC, this service request will not trigger an AS corresponding to that service, and instead will trigger activation 504 of the provisioning logic 414. The provisioning logic 414 will then access 506 the call model database 416. One of the input parameters will identify the user. The call model database 416 will retrieve a call model for that particular user. This call model will include the AS identifiers for the various services for that user. The database 416 will provide 508 the call model information to the provisioning logic 414 which in turn will provide it to the S-CSCF logic 410 within serving node 408. The S-CSCF 410 will construct a new set of filter codes, i.e., NFC, and thus a new call model, for that user (and will trigger the service requested initially using the NFC). The NFC will have SPTs identifying the corresponding ASs. This approach allows for dynamic construction of the NFCs (e.g., post registration) and allows the call model (e.g., NFC with associated SPTs) to be constructed uniquely for each user.
The above logic allows each user to have a call model and NFC that can differ from all other call models served by that S-CSCF. This functionality may be used in many ways. Per-user differentiated call models is useful though not strictly necessary to practice preferred embodiments of the invention.
This form of per user call model customization, in which different users may invoke different service logic functionality for the same given service request, is not provided in a conventional IMS network. In conventional IMS arrangements, the HSS provides static call models at UE registration. Each user gets the same ASs within their IFC and thus the same service experience (for services they are authorized to use). Moreover, the above approach allows for full portability of call models. No matter where a UE exists in the IMS network, that UE's call model may be constructed and used for that UE's service experience.
The term handoff as used herein denotes the transfer of a service delivery from one network and/or device to another network and/or device. The handoff does not involve the dropping of an access network connection. This meaning contrasts with the meaning of the term that often appears in the prior art (referred to in the background section above), in which handoff means the dropping of a first connection in favor of a second connection based on the relative signal strengths of the two connections.
The context of an end user may change. For example, as a user roams, his or her context may change. Alternatively, even in non-roaming situations, the user context may change as new devices and capabilities emerge or become activated.
At any given moment, the user may be in close proximity to any number of devices that are capable of acting as a UE for a certain service (application). For example, the user may be near a TV that could be used to display multimedia content. Or the user may be in close proximity to a personal computer that could be used to receive multimedia information from a network connection, provided network connectivity and authorization to use such a device in this manner could be obtained.
The described methods allow a roaming user to discover (directly or indirectly) several kinds of information and invoke several kinds of corresponding relevant policies to consider when and how to use such capabilities and devices:
Policies may reside either in the UE or in a designated server in the network. In a preferred embodiment, the policies reside in the network.
An increasing number of mobile handsets support short-range wireless technologies such as Bluetooth and Wi-Fi. According to certain embodiments, a “dynamic profile” is constructed, in part, by logic that executes in the handset. This logic may be executed continuously, periodically at some network determined time interval, or on demand when the user requests a particular service. When executed, the logic senses (or otherwise discovers) the presence of associated devices in the immediate vicinity of the handset using a short-range wireless technology such as Wi-Fi.
Home and personal networking systems increasingly feature the ability to discover new devices using so-called discovery protocols. One such example is the Universal Plug and Play (UPnP) protocol that allows the dynamic discovery of devices. According to certain embodiments, dynamic device discovery and service discovery framework within a user's personal or home area network is performed. For example, UPnP may be used to create a dynamic profile of the immediate environment of the handset (i.e., user) service environment. The dynamic device discovery mechanism is used to help create a personalized user area network map, which will serve as input to the switching/delivery logic.
Associated devices may announce their presence by a variety of means such as but not limited to Universal Plug and Play Devices (UPnP), Jini discoverable devices, RFID devices, and Bluetooth enabled devices.
Any method of broadcasting the capability of devices can be used. The sensing logic in the handset receives such broadcast information and assembles it to construct a dynamic profile of the user's immediate context. Since this context changes as the user roams, the dynamic profile changes to reflect the current vicinity of the handset. The dynamic profile is communicated to the serving node 408. For example, this information may be communicated as parameters (e.g., by overloading information elements [IEs] of Session Description Protocol (SDP) messages) in conjunction with a special service request dedicated to communicating potential UE devices.
A personal agent (PA) having PA logic 424 executes in UE (handset) 402 and includes the sensing logic to discover such other potential UEs or associated devices (more below). The dynamic profile of the user's immediate environment is communicated to the ME logic 412. This is done by having the ME server invoked in response to the special service request from the UE for communicating such discovered devices and capabilities. The ME service will construct topologies and maps to identify the potential UEs, other networks, etc., to reflect the new devices and capabilities discovered or sensed in the UE's vicinity that could potentially be used by a given user.
In certain embodiments, the handset's User Agent profile (UAProf) or Composite Capabilities/Preference Profiles (CC/PP) representing device capabilities and user preferences is used to personalize the multimedia service delivery framework. Serving node 408 will gather the UAProf or CC/PP from the endpoint devices to guide control of not only the rendering and trans-coding of content to be delivered to that device, but also the generation of the call agent as well as the decision to execute that service agent within the network or at the endpoint.
The personal agent supports an automated network and service discovery mechanism, such as the industry standard Universal Plug and Play (UpnP) framework, to establish association with and control of those networked devices. The networked devices that the PA can be associated with through the discovery procedure can be connected to the mobile handset via wireless connectivity, such as Bluetooth, Jini, self-identifying label technologies such as RFID, or Wi-Fi, or via wired connectivity, such as USB or IEEE 1394 links.
In certain embodiments, the static user profile downloaded by the HSS into the S-CSCF at registration time is provisioned by the network operator to contain the address of the ME server. Thus, every communication of the dynamic profile originating from the UE and received by the S-CSCF causes a SPT trigger to fire, and control is transferred to the corresponding ME server. In this fashion the serving node 408 and more particularly the ME server 412 becomes aware of the immediate context of the UE (handset).
Once the ME server has the information in the dynamic profile, it consults a database of policies described by the service operator. These policy descriptions may be co-located with the ME logic and even the S-CSCF logic (see, e.g.,
In an alternative embodiment S-CSCF logic 410 is not hosted within a serving node 408 as shown in
The interactions between the CSCF and an AS are summarized in
In preferred embodiments, the call model 602 (
In one scenario, a subscriber wanting to view multimedia content from an Internet server on his handset initiates an IMS request to serving node 408. The request emanates from the UE to the P-CSCF and onwards to the S-CSCF as explained above in connection with
As shown in
The ME function 412 creates or modifies a computational entity called an AVS (Audio Video Session) 1004 to model and control (in part) the actual access network connections for a given user. The call model 602a, discussed previously, is constructed first, based on the resources and policies. The AVS, on the other hand, represents what is actually going on, or intended to take place, or actually takes place (i.e., dynamically modifying to context). That is, the AVS represents the actual connections registered or to be registered in response to a given service request. If each access network connection is considered to be a “session”, then the AVS is a form of meta-session, or a super-session incorporating the access network sessions. Each AVS is uniquely identified by a AVID (Audio Video session ID) that is a function of the underlying TCID and the ICID.
An AVS is a representation of every access network that the UE encounters while roaming. For each new access network this representation creates a new “leg” (called Incoming Call Leg—ICL 1012, 1014). Each ICL has associated with it a TCID and an ICID (generated by other network elements) that together uniquely identify the session corresponding to that access network. Since the AVS 1004 has access to registration information of the UE, it knows that various ICLs (and hence various TCID+ICID combinations) really belong to the same UE, and hence, for each UE, the AVS representation captures all the access networks that the handset encounters. And since some access networks may support circuit-switched (CS) transport mode whereas others may support packet-switched (PS) transport modes, ICLs may be CS or PS supporting ICLs.
Network policies (see
In one example, a class B UE is engaged in a PS session watching Mobile TV. The UE roams into a Wi-Fi zone and a handoff happens, after which the MobileTV feed uses the Wi-Fi network. The previous PS session is idle and could be cleared. However, keeping it around serves a useful purpose. For example, suppose a voice call arrives for this UE. Since the CS stack is not executing in the UE, the call will normally be routed to voice mail without the user being informed of the call. But suppose a serving node 408 is informed of the arrival of this call (as explained below), and then uses the PS session to present a dialog box giving the user a choice to take the voice call. This example shows the usefulness of having more than one session (more than one ICL) active. Policies governing a given service will dictate whether or not to keep a leg active. Moreover, sometimes a leg may be unavoidably dropped, for example via lack of sufficient use, or because of signal issues.
As stated above, the serving node 408 includes one AVS per user. As shown in
CP 1016 is connected to the MS 1102, which in turn establishes a connection to the serving node 408 (using network server specific protocols). The connection between the CP and the MS is internal to the ME 412. The connection between the MS and the serving node 408 is an Outgoing Leg 1010 of the AVS. That is, AVS 1004 models this connection as outgoing leg component 1010. CP 1016 is also connected to MR 1104, which preferable may reside in the UE. The connection between the CP and the MR is an Incoming Leg, e.g., 1012. That is, AVS 1004 models this connection as incoming leg component 1012 or 1014. Thus, in a session having multiple MRs there are multiple Incoming Legs for a single AVS, as shown in
Continuing with the example above, the CP negotiates multimedia content delivery with the MS and instructs the MS to deliver content to an address corresponding to the MR on the UE. The instructions provided during such mediation will conform to the environment, context, and capabilities of the UE. CP 1016 also negotiates media rendering with the MR itself in each Incoming Leg of the AVS. That is, the CP effectively instructs the MR to start expecting content from the MS, and to present such. Again, the instructions provided during such mediation will conform to the environment, context, and capabilities of the UE.
When an access network connection is discovered by the UE sensing logic and communicated to ME server 412, and if the policy database 902 (
Thus, if the UE has sensed three different access networks and policy allows all three, then there are three distinct access network connections between the UE and the S-CSCF. In such a situation, there are signaling and bearer channels in each access network that can be utilized. It is a matter of policy that decides which signaling channel within an access network is to be used and which channels within an access network is to be used for bearer traffic. In the case when coverage of an access network is lost (for example, due to roaming of the UE), the corresponding access network connection and the associated AVS Incoming Leg is “cleared” under S-CSCF serving logic control by the P-CSCF.
As mentioned above, many new kinds of access networks, such as Wi-Fi and WiMax, are being deployed. The proposed IMS specifications allow the UE to connect to an access network. Preferred embodiments of the present invention allow the UE to remain in simultaneous connection (or potential use) with multiple access networks and the choice of which access network to deliver a particular service to the UE is to be made by policies resident in the ME function in the serving node of the network. That is, the AVS facilitates control of multiple access networks (both signaling and bearer) and allows choices to be made (by the system and perhaps the user) as to which network to use in a given context and time.
In conjunction with deployments of various kinds of access networks, handset manufacturers are also producing handsets that support multiple radio access technologies. Examples of such handsets today are those that support Wi-Fi and GSM/CDMA cellular networks. In such handsets, known as Class A handsets, both the circuit switched session of the GSM/CDMA network and the packet switched session of Wi-Fi can co-exist and be active simultaneously. Moreover, there are numerous proposals for voice call handoffs between cellular (GSM/CDMA) and Wi-Fi networks.
Using the described embodiments, a Class A handset can have multiple packet sessions and a circuit switched session simultaneously active in the handset. In ther terminology explained above, the corresponding AVS may have multiple Incoming Legs corresponding to one circuit switched and multiple packet switched sessions. Another type of handset, called a Class B, handset only supports either a circuit switched session or a packet session at any given time. If the handset roams into a Wi-Fi area from a cellular area, the circuit switched session is replaced by a new packet switched session supported by the new Wi-Fi network in a Class B handset; in a Class A handset the circuit switched session can be allowed to persist. This corresponds to removing one Incoming Leg of the AVS (representing the circuit switched cellular connection) and adding another Incoming Leg (representing the Wi-Fi connection) to the underlying AVS for Class B handsets. In the case of Class A handsets in which the circuit switched session is not cleared, the situation corresponds to simply adding another Incoming Leg to the AVS session.
The following scenarios for Class A and B handsets are possible:
Scenarios 1-4 show that by having access to multiple access networks under mobility situations, the described embodiments allow services that use a combination of packet and circuit switched access network technologies.
As explained above, mechanisms to utilize non-IMS, legacy services within an IMS context are provided. To do this, the system logically separates the control and bearer parts of the legacy service. The control component of the service is handled by IMS, and the bearer component may remain independent of IMS. The control point (CP) 1016, referred to earlier, is the mechanism used to allow “out of band” media transport under control of IMS. Under preferred embodiments every AVS 1004 has an associated CP 1016, for example, logically within the AVS. More specifically, each AVS is designated to have an “Outgoing Leg” (OCL) 1010 that contains a CP. The CP has capability to transact with an Application Server (AS) using a standard protocol, such as RTSP, and it has the capability to transact with programs in the UE called Media Renders (MRs), again using standard protocols such as SIP, or SOAP/HTTP. The CP itself may be considered an Application Server (AS) by the S-CSCF (i.e., interacted with as if it were an AS).
Now consider a UE requesting Mobile TV service. This request emanates from the UE (on an ICL) and is forwarded by the S-CSCF to the CP 1016 acting as an AS (in standard IMS fashion). Since the CP acting as an AS has access to IMS charging and authentication mechanisms, the first objective of re-using IMS infrastructure for legacy services is fulfilled. Once the charging and various other bookkeeping functions have been finished, the CP contacts the MobileTV server (e.g., illustrated as Content Server 1018 in
The communication between the CP and the UE for setting up media rendering and for other functions uses valuable spectrum. In order to reduce such spectrum-consuming communications, the relationship between an MR and a media server can be fixed a priori and pre-provisioned. Thus the CP always picks a pre-designated MR for a particular media server.
In a preferred embodiment, wireless spectrum-consuming communications between the CP, media servers and media renderers are reduced by introducing a CP Proxy (CPP) that resides in the UE. This architecture is illustrated in
As indicated above, UPnP architecture includes three functional entities: control point (CP), media server (MS), and media renderer (MR). These may be implemented in different physical devices. In a digital home environment, for example, the MS and MR typically reside in a TV set and the CP in a remote control unit.
It is assumed that the MS and MR entities represent abstractions that capture the essence of media servers and media renderers. The abstractions allow programmers to write general-purpose software that deals with the properties of these entities without having to deal with their inner workings. The handling of these inner workings is left to the implementation of the media server and the media renderer themselves. Thus, by way of example, if a program desires to issue a “suspend” command to a MS, it may use the MS's defined interface to issue that command. It is left to the MS to implement the “suspend” command.
Communications between the CP and an MS and MR use the SOAP/HTTP protocols. Direct communication between a MS and a MR is referred to as “out of band,” since is up to the MS and MR to select the protocol. One such protocol is RTSP/RTP.
In one example, the MS implements a video player, the MR implements an LCD display, and the CP implements a remote control unit. The CP queries the MS for a contents directory and presents that on the display unit, allowing content to be selected for rendering. The commands between the CP and MS, and between the CP and MR use SOAP/HTTP. The communication between MS and MR could use RTSP/RTP.
In a wireless network in which the CP implements a handset, and the MS and MR implement a non-mobile media server and media renderer, the wireless network could be used to carry a control protocol between the these three entities, akin to SOAP/HTTP (but perhaps a more secure version). However, this approach suffers from the disadvantage that the control messages between the CP and the MS, and the CP and the MR use the limited capacity of the wireless network.
In certain embodiments, the UPnP architecture is extended into a wide area network environment. One approach, illustrated in
In this architecture, the CP and the CPPs need a synchronization protocol. Communication between the CP and the CPP could be optimized by using off-peak times to communicate and by making the CPP as independent of the CP as possible.
Moving the control point into the wide area network enables a user to connect to services provided by MSs that are not located in the home, such as foreign television stations. In addition, MSs, whether in the home or not, can now be rendered on MRs outside the home, such as on the handset itself, or on a MR that is in proximity to the handset running the CPP when the handset is outside the home, as described above.
CP 1016 running in the SN can support multiple CPPs. For example, there can be a CPP implemented in a handset, and also in a remote control unit. When the user is inside the home, he may prefer to use the remote control unit as the CPP since it may have a better form factor for VCR-type controls. On the other hand, when the user is outside the home, he invokes the CPP on the handset in order to maintain connection and control with the home network.
The above techniques are illustrated by the following communication sequence. A subscriber requests a media service to be rendered on a home Wi-Fi-enabled display device. CPP 1202 communicates with CP 1016 via internal interface 1204 using the wide area wireless network. Subsequent communication between CP 1016 and MS 1102, or between CPP 1202 and MR 1104 need not use the wireless network. Upon receiving confirmation from CP 1016, CPP 1202 instructs MR 1104 to negotiate an out-of-band service request with MS 1102.
In the case where the UE is in the proximity of both the desired MS and the desired MR and can communicate with them via a PAN, such as Wi-Fi, the CPP in the UE negotiates the association between the MS and MR. In this case there is no need to involve the CP in the SN, since this would involve unnecessary use of wireless bandwidth. Conversely, when the UE is not in the proximity of either the desired MS or the desired MR, the CP handles the negotiation and association of both the MR and MS, using fixed communication links instead of wireless links.
Thus, in a wide area networking extension of UPnP, moving the CP into a network element, such as the serving node of an IMS session, and placing the CPP into the handset optimizes usage of the wireless spectrum usage.
This architecture also allows normal telephony to be integrated with UPnP-based media services. As used herein, normal telephony includes supplementary features such as call diversion, three-way calling, and voicemail.
In an alternative architecture, the CP does not migrate to the core network, but continues to reside in the handset. In this peer-to-peer style architecture, there is no core network element, but the peer-to-peer signaling uses the valuable and limited resources of the wireless spectrum. The network-based architecture, as indicated above, consumes less wireless spectrum.
CPP 1202 has local service logic that decides what MR to pick for a particular media server. In other words, the CP-MR negotiation is transformed into CPP-MR negotiation (which is local to a UE and hence does not use spectrum). Moreover, the CPP policies and logic can be updated periodically from the network-resident CP at opportune times.
In yet another embodiment, the concept of MVNO-customized logic may be applied to so-called hybrid networks. In general a hybrid network is a combination of two or more individual networks. Examples of digital broadcast networks for joint use are DVB-H (Digital Video Broadcast—Handheld), and Media FLO (Forward Link Only). In a hybrid network, the broadcast network provides a high capacity but one-way transport for multimedia (video) traffic, while the UMTS (Universal Mobile Telecommunications System) network (or other network) may provide lower capacity two-way transport for interactive services. In such hybrid networks, the UMTS network is used for control and signaling purposes for the services offered by the broadcast component network. In this fashion, the UMTS network supplements the digital broadcast network by providing a control network or a network for user interactivity functions. Conversely, the broadcast network may supplement a UMTS (or other) network by providing certain broadcast functionality.
Since the PA runs in mobile handset environment, the handset has a direct logical service interface to the Internet Wide Area Network (WAN) via the 2G/3G wireless network. From the UPnP device architecture perspective, the PA serves as an Internet Gateway Device (IGD). An IGD is an “edge” interconnect device between a residential Local Area Network (LAN) and the Wide Area Network (WAN), providing connectivity to the Internet. The IGD typically runs in the local network environment, e.g., on a PC in the WLAN environment.
In the search process described below, the discovery, registration, and use of an associated device corresponds to the setting up of a new incoming leg of the AVS session. The ME server then determines whether there is an advantage to be gained from switching the media rendering from the renderer in the handset to a renderer in a discovered device. The CPP can then offer a choice to the user as to whether to switch to the new renderer, or the switch can be performed automatically.
A UPnP service manager (SM) is provided in the PA to organize the services discovered, as shown in
Two functions enable the discovery process: search module 426 (see
Search module 426 is a UDP-based function in the PA that broadcasts search messages whenever the user wants to search for new devices. It communicates with the user interface of the service manager and updates a list (in the PA logic 424) of discovered devices on the service manager when it finds a new device. It determines whether or not the device is new by matching its Universally Unique Identifier (UUID) against those of the devices already discovered. Each device has a unique UUID.
Search Module 426 consists of the following procedures:
Discovery: The discovery protocol allows control point proxies, such as the PA, to search for devices of interest in the network. A search is carried out by multicasting a search message with a pattern equal to a type or identifier for a device or service. Responses from service providers/devices contain discovery messages that are essentially identical to those advertised by newly connected devices. In other words, the responses to the outgoing discovery messages from the PA are similar to the messages the service providers/devices are themselves unicasting as their own advertising messages, as described below. The former are unicast while the latter are multicast. Below is a format of a Search message:
M-SEARCH*HTTP/1.1
HOST: 239.255.255.250:1900
MAN: ssdp: discover
MX: seconds to delay response
ST: search target
Response: In a response, the discovered device sends a message to the M-SEARCH source IP address and port that sent the discovery request to the multicast channel. This response follows the same pattern as listed for NOTIFY with “ssdp: alive” (see below in the description of the advertising module) except that a search target (ST) header is used instead of the new target (NT) header. The format is as follows:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=seconds until advertisement expires
DATE: when response was generated
EXT:
LOCATION: URL for UPnP description for root device
SERVER: OS/version, UPnP/1.0, product/version
ST: search target
USN: advertisement UUI
Description: After the PA has discovered a device, the PA still knows very little about the device. In order to learn more about the device and its capabilities, or to interact with the device, the PA retrieves the device's description from the URL provided by the device in the discovery message. The PA sends the following request header to the discovered device:
GET path to description HTTP/1.1
HOST: host for description: port for description
ACCEPT-LANGUAGE: language preferred by control point.
By default the ‘Host’ and ‘Accept’ header fields in the request headers are sent, following normal conventions, such as from HTML. Once the socket is created, where the HostName and RemotePort properties are set to the values specified in the URL, the request header block is then sent to the discovered device, which consists of the command (GET) and the other header fields defined above. A sample of a device description in the XML format is shown:
When a device is added to the network, it advertises its services to control points by multicasting discovery messages to a standard address and port at regular time intervals. Serving as an UPnP control point, the PA listens to this port to detect when new capabilities are available on the network. Each advertisement message contains information specific to the embedded device or service as well as information about its enclosing device. Messages should include the duration until the advertisements expire. If the device becomes unavailable, the device will either explicitly cancel its advertisements, or wait for the advertisements to expire on their own.
The advertisement module in the PA listens for advertisement messages. It is also a UDP-based application that listens on port 1900 (as given in the UPnP specifications). It communicates with the user interface of the service manager and updates the list of discovered devices on the service manager when it finds a new device. It determines whether or not the device is new by matching its UUID against those of the devices already discovered.
The service manager is needed because more than one service may be present in the Personal Area Network (PAN) and the manager provides an easy and intuitive way for the user to manage all the discovered services/devices. In addition, the service manager is responsible for communicating the updated PAN neighborhood configuration (i.e., context) of the mobile handset to serving node 408. The discovered device and service will be reported to the serving node 408 in a SIP message which includes an SDP extension header. The service manager enables the mobile handset user to accomplish this.
When a new device is added to the list in the service manager a timer is started whose value depends on the cache-expiry value sent by the device. Once this timer expires, the device/service is removed from the list. However, if an advertisement message is received from that device the timer is restarted.
The format of the multicast message is as follows: values in italics are placeholders for actual values.
NOTIFY*HTTP/1.1
HOST: 239.255.255.250:1900
CACHE-CONTROL: max-age=seconds until advertisement expires
LOCATION: URL for UPnP description for root device
NT: search target
NTS: ssdp: alive
SERVER: OS/version, UPnP/1.0, product/version
USN: advertisement UUID
The following case illustrates by way of example a session that involves the PA client discovering an associated device via UPnP Discovery mechanisms. In this example, the new device to be associated with the PA client is powered on and starts advertising its service and device descriptions. For example, the new device might be a PC with IGD software, whose display will be used as a media renderer.
As depicted by 1401a, 1401b, and 1402 in
Next, as depicted by steps 1403-1406 in
As shown by 1407 in
The following case illustrates a session that involves the PA client discovering an associated device via UPnP Discovery mechanisms, and the serving node triggering a handoff procedure from the PA client to the associated device to initiate a real time streaming protocol (RTSP) streaming session. In this example, an IMS/SIP session has been established between the PA and the Media Server Control AS in the serving node.
As depicted by 1501-1507 in
As depicted by 1509 in
As depicted by 1511a, 1511b, and 1511c in
As depicted by 1512 and 1513 in
As depicted by 1514 and 1515 in
As depicted by 1517 in
As depicted by 1518a, 1158b, and 1518c in
The following case illustrates a session that involves the PA client discovering an associated device via UPnP discovery mechanisms, and the serving node triggering a relay procedure to allow RTSP streaming content to be relayed from the PA client to the associated device. In this case, the media transport takes place over the 2G/3G network to the handset, and from the handset it is relayed to a discovered associated device using a WLAN/PAN.
In this example, the PA acts as a SIP UE and an IMS/SIP session has been established between the PA and the Media Server Control AS in the serving node.
As depicted by 1601 to 1609 in
As depicted by 1610 in
As depicted by 1611a, 1611b, and 1611c in
As depicted by 1612 and 1613 in
As depicted by 1614 and 1615 in
As depicted by 1616 in
As depicted by 1617 in
As depicted by 1618a, 1618b, and 1618c in
This case illustrates a session that involves the PA client discovering an associated device via UPnP Discovery mechanisms, and the serving node triggering a handoff procedure to allow RTSP streaming content to be relayed from the PA client to the associated device. In addition, the serving node also determines that the content to be delivered to the newly associated device via the PA (relay) requires trans-coding and directs a Media Resource Control Function (MRCF) to establish the trans-coding session. Transcoding can involve, for example, changing the spatial or and/or color resolution of a video stream to take advantage of higher resolution viewing capability on a discovered device.
As described in detail below, in this case the MRCF responds to the INVITE request with a 200 OK message indicating the selected media in the SDP. The MRCF will also reserve the requested local resources at that time and return the appropriate resource identifiers in the 200 response.
In one embodiment, the Media Server Control AS controls a trans-coding session and is aware of MRCF capabilities. The MRCF accepts INVITE requests sent from the AS, via the S-CSCF, to dynamically set up the trans-coding configuration. The INVITE sent to the MRCF contains sufficient information to support the RTSP session that requires trans-coding. The MRCF always grants the requests from the AS, unless it has reached its resource limits.
It is assumed that the PA is acting as a SIP UE and that an IMS/SIP session has been established between the PA and the Media Server Control AS in the serving node.
As depicted by 1701 in
After the Handoff Control AS has triggered a PA relay action, an RTSP streaming session is initiated from the mobile handset (1702-1719). The Media Server Control AS is aware of the different codec requirements between the PA client in the mobile handset and the newly associated device by retrieving the ME framework parameters reported by the PA when the newly terminal device is discovered and associated.
The Media Server Control AS serves as a B2BUA and interacts with the originating UE as usual to establish the dialog. The Media Server Control AS interacts with the MRCF using a third party control model, as defined in IETF RFC 3264.
The Media Server Control AS requests trans-coding facilities from the MRCF (1720). The request includes the appropriate trans-coding requirements and resources to be established. A separate dialog is established from the Media Server Control AS to the MRCF for the PA client.
The offer/answer model is used for SDP negotiation between the Media Server Control AS/S-CSCF and the MRCF.
The MRCF should always grant the requests from the AS (unless there is a resource problem). The MRCF responds to the INVITE request (1721, 1722) with a 200 response indicating the selected codec in the SDP (1723, 1724). The MRCF will also reserve the requested local resources at that time.
The media from the PA UE is connected at the trans-coding resource at the Media Resource Function Processor (MRFP).
The selected codec is included by the Media Server Control AS in the 183 response to the UE. (not on FIG.)
The receipt of the ACK at the MRCF (1725, 1726) triggers the start of the trans-coding session (1727-1730).
It will be further appreciated that the scope of the present invention is not limited to the above-described embodiments but rather is defined by the appended claims, and that these claims will encompass modifications and improvements to what has been described.
This application is a continuation of and claims priority to U.S. application Ser. No. 15/210,263, filed Jul. 14, 2016, which is a continuation of and claims priority under 35 U.S.C. 120 of U.S. patent application Ser. No. 13/276,744, filed Oct. 19, 2011, which is a continuation of and claims priority under 35 U.S.C. 120 to U.S. patent application Ser. No. 11/370,594, filed Mar. 8, 2006, entitled Associated Device Discovery in IMS Networks, which is a continuation-in-part of and claims priority under 35 U.S.C. 120 to the following applications, the contents of which are incorporated herein by reference in their entirety: U.S. patent application Ser. No. 11/166,407, filed on Jun. 24, 2005, entitled Method and System For Provisioning IMS Networks With Virtual Service Organizations Having Distinct Service Logic;U.S. patent application Ser. No. 11/282,924, filed Nov. 18, 2005, entitled IMS Networks with AVS Sessions with Multiple Access Networks. This application is related to U.S. patent application entitled “Digital Home Networks Having a Control Point Located on a Wide Area Network” filed on even date herewith.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4736407 | Dumas | Apr 1988 | A |
| 6014706 | Cannon et al. | Jan 2000 | A |
| 6018662 | Perivalwar et al. | Jan 2000 | A |
| 6032053 | Schroeder et al. | Feb 2000 | A |
| 6374112 | Widegren et al. | Apr 2002 | B1 |
| 6574326 | Wong et al. | Jun 2003 | B1 |
| 6608832 | Forslow | Aug 2003 | B2 |
| 6650705 | Vetro et al. | Nov 2003 | B1 |
| 6675196 | Kronz | Jan 2004 | B1 |
| 6694145 | Riikonen et al. | Feb 2004 | B2 |
| 6782412 | Brophy et al. | Aug 2004 | B2 |
| 6857021 | Schuster et al. | Feb 2005 | B1 |
| 6888828 | Partanen et al. | May 2005 | B1 |
| 6950655 | Hunkeler et al. | Sep 2005 | B2 |
| 7039033 | Haller et al. | May 2006 | B2 |
| 7299049 | Jagadeesan | Nov 2007 | B2 |
| 7301938 | Ejzak | Nov 2007 | B2 |
| 7353021 | Ejzak et al. | Apr 2008 | B2 |
| 7463622 | Lu | Dec 2008 | B2 |
| 7689681 | David | Mar 2010 | B1 |
| 7729298 | Velagaleti et al. | Jun 2010 | B2 |
| 7856226 | Wong | Dec 2010 | B2 |
| 20020025780 | Jakobsson | Feb 2002 | A1 |
| 20020044661 | Jakobsson | Apr 2002 | A1 |
| 20020059416 | Tuunanen | May 2002 | A1 |
| 20020064274 | Tuunanen et al. | May 2002 | A1 |
| 20020085511 | Koponen et al. | Jul 2002 | A1 |
| 20020132638 | Plahte et al. | Sep 2002 | A1 |
| 20020140726 | Schwartz et al. | Oct 2002 | A1 |
| 20020146981 | Saint-Hilaire | Oct 2002 | A1 |
| 20020181462 | Surdila et al. | Dec 2002 | A1 |
| 20030026213 | Frank et al. | Feb 2003 | A1 |
| 20030026245 | Ejzak | Feb 2003 | A1 |
| 20030027569 | Ejzak | Feb 2003 | A1 |
| 20030027595 | Ejzak | Feb 2003 | A1 |
| 20030055974 | Brophy et al. | Mar 2003 | A1 |
| 20030078002 | Sanjeev | Apr 2003 | A1 |
| 20030134636 | Sundar et al. | Jul 2003 | A1 |
| 20030192426 | Vidal | Oct 2003 | A1 |
| 20030210683 | Bais et al. | Nov 2003 | A1 |
| 20040008669 | Bos et al. | Jan 2004 | A1 |
| 20040019539 | Raman et al. | Jan 2004 | A1 |
| 20040019901 | Spio | Jan 2004 | A1 |
| 20040028009 | Dorenbosch et al. | Feb 2004 | A1 |
| 20040043766 | Sashihara | Mar 2004 | A1 |
| 20040043776 | Tuomela et al. | Mar 2004 | A1 |
| 20040068571 | Ahmavaara | Apr 2004 | A1 |
| 20040068574 | Costa Requena et al. | Apr 2004 | A1 |
| 20040076145 | Kauhanen et al. | Apr 2004 | A1 |
| 20040083195 | McCord et al. | Apr 2004 | A1 |
| 20040107143 | Niemi | Jun 2004 | A1 |
| 20040127251 | Thakkar et al. | Jul 2004 | A1 |
| 20040139088 | Mandato et al. | Jul 2004 | A1 |
| 20040162892 | Hsu | Aug 2004 | A1 |
| 20040190498 | Kallio et al. | Sep 2004 | A1 |
| 20040193700 | Westman et al. | Sep 2004 | A1 |
| 20040193725 | Costa-Requena et al. | Sep 2004 | A1 |
| 20040196867 | Ejzak et al. | Oct 2004 | A1 |
| 20040204168 | Laurila | Oct 2004 | A1 |
| 20040205212 | Huotari et al. | Oct 2004 | A1 |
| 20040219912 | Johansson et al. | Nov 2004 | A1 |
| 20040240430 | Lin et al. | Dec 2004 | A1 |
| 20040249887 | Garcia-Martin et al. | Dec 2004 | A1 |
| 20040249962 | Lecomte | Dec 2004 | A1 |
| 20040252673 | Ejzak et al. | Dec 2004 | A1 |
| 20040261116 | McKeown et al. | Dec 2004 | A1 |
| 20050021494 | Wilkinson | Jan 2005 | A1 |
| 20050025047 | Bodin et al. | Feb 2005 | A1 |
| 20050025163 | Christie | Feb 2005 | A1 |
| 20050043020 | Lipsanen et al. | Feb 2005 | A1 |
| 20050047399 | Lee et al. | Mar 2005 | A1 |
| 20050050194 | Honeisen et al. | Mar 2005 | A1 |
| 20050058125 | Mutikainen et al. | Mar 2005 | A1 |
| 20050083909 | Kuusinen et al. | Apr 2005 | A1 |
| 20050089020 | Ahlback et al. | Apr 2005 | A1 |
| 20050101245 | Ahmavaara | May 2005 | A1 |
| 20050136926 | Tammi et al. | Jun 2005 | A1 |
| 20050141484 | Rasanen | Jun 2005 | A1 |
| 20050170861 | Niemi et al. | Aug 2005 | A1 |
| 20050190772 | Tsai et al. | Sep 2005 | A1 |
| 20050213606 | Huang et al. | Sep 2005 | A1 |
| 20050215283 | Camp | Sep 2005 | A1 |
| 20050022768 | Li | Oct 2005 | A1 |
| 20050237933 | Marjelund et al. | Oct 2005 | A1 |
| 20050243870 | Balogh et al. | Nov 2005 | A1 |
| 20050245261 | Ejzak | Nov 2005 | A1 |
| 20050271011 | Alemany et al. | Dec 2005 | A1 |
| 20050286531 | Tuohino et al. | Dec 2005 | A1 |
| 20060015812 | Cunningham et al. | Jan 2006 | A1 |
| 20060025149 | Karaoguz | Feb 2006 | A1 |
| 20060025151 | Karaoguz et al. | Feb 2006 | A1 |
| 20060031888 | Sparrell | Feb 2006 | A1 |
| 20060062206 | Krishnaswamy | Mar 2006 | A1 |
| 20060083199 | Yang | Apr 2006 | A1 |
| 20060089143 | Jagadeesan | Apr 2006 | A1 |
| 20060104262 | Kant et al. | May 2006 | A1 |
| 20060114987 | Roman | Jun 2006 | A1 |
| 20060120287 | Foti et al. | Jun 2006 | A1 |
| 20060121902 | Jagadeesan et al. | Jun 2006 | A1 |
| 20060136557 | Schaedler et al. | Jun 2006 | A1 |
| 20060140150 | Olvera-Hernandez et al. | Jun 2006 | A1 |
| 20060155814 | Bennett et al. | Jul 2006 | A1 |
| 20060161512 | Schaedler et al. | Jul 2006 | A1 |
| 20060164550 | Yoshimoto et al. | Jul 2006 | A1 |
| 20060165050 | Erhart et al. | Jul 2006 | A1 |
| 20060183478 | Jagadeesan et al. | Jul 2006 | A1 |
| 20060209768 | Yan et al. | Sep 2006 | A1 |
| 20060221903 | Kauranen et al. | Oct 2006 | A1 |
| 20060246903 | Kong et al. | Nov 2006 | A1 |
| 20060256751 | Jagadeesan et al. | Nov 2006 | A1 |
| 20060258394 | Dhillon et al. | Nov 2006 | A1 |
| 20060262806 | Bouazizi | Nov 2006 | A1 |
| 20060276179 | Ghaffari et al. | Dec 2006 | A1 |
| 20060291412 | Naqvi et al. | Dec 2006 | A1 |
| 20060291419 | McConnell et al. | Dec 2006 | A1 |
| 20060291433 | Do et al. | Dec 2006 | A1 |
| 20060291437 | Naqvi et al. | Dec 2006 | A1 |
| 20060291455 | Katz et al. | Dec 2006 | A1 |
| 20060291484 | Naqvi et al. | Dec 2006 | A1 |
| 20060291487 | Naqvi et al. | Dec 2006 | A1 |
| 20060291488 | Naqvi et al. | Dec 2006 | A1 |
| 20060291489 | Naqvi et al. | Dec 2006 | A1 |
| 20060294244 | Naqvi et al. | Dec 2006 | A1 |
| 20070008913 | Naqvi et al. | Jan 2007 | A1 |
| 20070008951 | Naqvi et al. | Jan 2007 | A1 |
| 20070014281 | Kant | Jan 2007 | A1 |
| 20070033286 | Min | Feb 2007 | A1 |
| 20070053343 | Suotula et al. | Mar 2007 | A1 |
| 20070066347 | Silverbrook et al. | Mar 2007 | A1 |
| 20070067807 | O'Neil | Mar 2007 | A1 |
| 20070091855 | Karaoguz et al. | Apr 2007 | A1 |
| 20070110043 | Girard | May 2007 | A1 |
| 20070111752 | Pazhyannur | May 2007 | A1 |
| 20070155310 | Borcic et al. | Jul 2007 | A1 |
| 20070165572 | Lenzarini | Jul 2007 | A1 |
| 20070165599 | Skog et al. | Jul 2007 | A1 |
| 20070174471 | Van Rossum | Jul 2007 | A1 |
| 20070197227 | Naqvi et al. | Aug 2007 | A1 |
| 20070207782 | Tran | Sep 2007 | A1 |
| 20070207802 | Palmer et al. | Sep 2007 | A1 |
| 20070207804 | Sharma et al. | Sep 2007 | A1 |
| 20070217349 | Fodor et al. | Sep 2007 | A1 |
| 20070217366 | Sagi et al. | Sep 2007 | A1 |
| 20070226344 | Sparrell et al. | Sep 2007 | A1 |
| 20080043717 | Bellora et al. | Feb 2008 | A1 |
| 20080092178 | McNamara et al. | Apr 2008 | A1 |
| 20080130637 | Kant et al. | Jun 2008 | A1 |
| 20080162637 | Adamczyk et al. | Jul 2008 | A1 |
| 20080205317 | Piipponen et al. | Aug 2008 | A1 |
| 20080291905 | Chakravadhanula et al. | Nov 2008 | A1 |
| 20080316998 | Procopio et al. | Dec 2008 | A1 |
| 20090258596 | Naik | Oct 2009 | A1 |
| 20100265863 | Cordeiro | Oct 2010 | A1 |
| Number | Date | Country |
|---|---|---|
| 1435748 | Jul 2004 | EP |
| 1545129 | Jun 2005 | EP |
| 2007010070 | Jan 2007 | WO |
| 2007117730 | Oct 2007 | WO |
| Entry |
|---|
| Definition of ‘proxy’ from dictionary.com, http://dictionary.reference.com/browse/proxy, printed Mar. 14, 2009 (5 pages). |
| European Search Report for European Patent Application No. 07751603.7 dated Apr. 5, 2011. 6 pages. |
| European Search Report for European Patent Application No. EP08746133 dated Jun. 25, 2010. 8 pages. |
| GSM Association: “Video Share Service Definition 2.0.” Mar. 27, 2007. XP002585831. http://www.asmworld.com/documents/se41.pdf>. Retrieved on Jun. 2, 2010. 28 pages. |
| International Search Report and Written Opinion, International Application No. PCT/US08/60656, Aylus Networks, Inc., dated Jul. 2, 2008, 8 pages. |
| International Search Report for Application No. PCT/US08/57367, Aylus Networks, Inc., dated Aug. 8, 2008, 7 pages. |
| International Search Report for International Application No. PCT/US07/04854, Aylus Networks, Inc., dated Jan. 31, 2008 (3 pages). |
| International Search Report for International Patent Application No. PCT/US08/60644, dated Jun. 27, 2008 (9 pages). |
| International Search Report, International Application No. PCT/US 06/24619, dated Feb. 14, 2007, 2 pages. |
| International Search Report, International Application No. PCT/US 06/24624, dated Apr. 3, 2007, 1 page. |
| Nokia Corporation: “Video Sharing, Enrich Your Voice Call with Video.” Nov. 1, 2004. XP002336424. 12 pages. |
| OSGi Service Platform. Mar. 2003, The Open Services Gateway Initiative, Release 3. pp. 345-346, 505, 513-526 (602 pages). |
| Number | Date | Country | |
|---|---|---|---|
| 20170367140 A1 | Dec 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15210263 | Jul 2016 | US |
| Child | 15674634 | US | |
| Parent | 13276744 | Oct 2011 | US |
| Child | 15210263 | US | |
| Parent | 11370594 | Mar 2006 | US |
| Child | 13276744 | US | |
| Parent | 11282924 | Nov 2005 | US |
| Child | 11370594 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11166407 | Jun 2005 | US |
| Child | 11282924 | US |
