KR20080084954A - Method and network for providing service blending to a subscriber - Google Patents

Abstract

A method (200) and communication network (350) for providing blending of services to a subscriber of one or more services of the communication network and one or more services of a TV delivery system (300, 305, 310) in communication with the network utilizing a server broker function (125, 355). Upon receipt of a message from the calling party, the service broker function may be configured to execute service package information (352) associated with services of the TV delivery system subscription to include obtaining and delivering caller ID information of the calling party. The service broker function may be configured to alter information in the message request to generate a modified message request that is sent to a phone (304, 354) of the subscriber to modify alerting of the subscriber's phone, while sending the caller ID information of the calling party to an application (305, 325) of the TV delivery system for display.

Description

METHOD AND NETWORK FOR PROVIDING SERVICE BLENDING TO A SUBSCRIBER}

The present invention relates generally to a communication network and method for providing blending of services to subscribers of a network and TV delivery system.

IP Multi-Media Subsystem (IMS) is a telephony core network and IP multimedia defined by 3GPP and 3GPP2 standards and organization based on the IETF Internet Protocol. 3GPP / IMS networks are access independent because they support IP over wireline IP, 802.11, 802.15, CDMA, packet data with GSM / EDGE / UMTS, and other packet data applications for IP sessions.

The 3GPP / IMS service architecture is an integrated architecture that supports a wide range of services made possible by the flexibility of the Session Initiation Protocol (SIP). SIP is a signaling protocol for Internet conferencing, telephony, event notification and instant messaging. SIP was developed within the Internet Engineering Task Force (IETF) Multiparty Multimedia Session Control working group. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which support personal mobility-users can see a single externally visible identifier regardless of their network location. ) Can be maintained.

By providing "blended" services to subscribers of services on different platforms, such as subscribers to telecommunications networks and TV delivery systems, impacts investments in the IMS service infrastructure and new service offerings. There is a need to provide. For example, a service provider may be a blended service (e.g., telephone, multicast, television / video, etc.) to subscribers of a service infrastructure, such as 3GPP / IMS networks and other platforms or Internet Protocol Television (IPTV). I want to be able to provide IPTV services typically include the ability of a user / viewer to display caller ID information, instant messages, e-mail, and Short Message Service (SMS) on the TV.

An exemplary embodiment of the present invention is a communication network for providing blending of services to subscribers of one or more services of a TV delivery system that communicate with one or more services of the communication network using a service broker function. And to a method. When receiving a message from the caller's side, the service broker function is associated with the service of the TV delivery system subscription to include obtaining and delivering the caller's ID information at the caller's side. It may be configured to perform related service package information. The service broker function generates a modified message request, which is sent to the subscriber's phone to correct the subscriber's telephone call while sending the caller ID information of the caller's side to the application of the TV delivery system for display. Can be configured to change the information of the message request.

Exemplary embodiments of the present invention will be more fully understood from the detailed description given below and the accompanying drawings in which like elements are designated by like reference numerals, which are given by way of illustration only and thus exemplary embodiments of the present invention. It does not limit form.

1 is a block diagram of an IMS service architecture in accordance with an exemplary embodiment of the present invention.

2 is a flowchart illustrating a method of providing a blending of services to a subscriber in accordance with an exemplary embodiment of the present invention.

3A and 3B show a relationship between a TV delivery system and a service structure of a communication network.

According to an exemplary embodiment of the present invention, another platform service structure, such as a service delivery structure such as an IMS service structure of a communication network and a content streaming structure of a TV delivery system such as an IPTV system, provides a blended service to a subscriber. It can be used to.

1 is a block diagram of an IMS service structure, in accordance with one exemplary embodiment of the present invention. An example IMS service structure for an IMS communication network is described below to provide a context for a system and exemplary methodology for blending of services.

As shown in FIG. 1, the IMS service architecture 100 of a communication network, such as a 3GPP / IMS core network, includes traditional telephony services and instant messaging, push-to-talk, video. It can support multiple application servers that provide non-telephony services such as streaming, multimedia messaging, and the like. The service structure 100 is a collection of logical functions, which can be divided into three layers: a Transport and Endpoint Layer 110 and a Session Control Layer. 120 and an Application Server Layer 130.

Transport and endpoint layer

The transport and endpoint layer 110 establishes a session and bearers such as converting voice into IP packets using Realtime Transport Protocol (RTP) in analog or digital format. Initiate and terminate SIP signaling to provide a service. This layer provides a media gateway for converting the Voice of Internet Protocol (VoIP) bearer stream into the PSTN TDM format. The media server provides a number of media related services, including conferencing, announcements, in-band signaling tones, speech recognition, speech synthesis, and the like.

Media server resources are shared across all applications. As a result, each application, for example, each application that requires notification or collection of digits, can use a common server. The application includes, among others, voicemail, advanced 800, and interactive VoiceXML (VXML) services. The media server can also support non-telephony features such as copying media for push-to-talk (PTT) services. By using a common pool of media servers across multiple services, service providers do not have to predict and engineer media resources for each application.

Session control layer

Session control layer 120 includes a Call Session Control Function (CSCF) 127, which provides registration of endpoints and routing of SIP signaling messages to the appropriate application server. . CSCF 127 is thus a proxy server that provides session control for subscribers to access services within the IMS. CSCF 127 may also be referred to as a SIP server.

The CSCF 127 interworks with the transport and endpoint layer 110 to ensure Quality of Service (QoS) across all services. Session control layer 120 may communicate with a user database, such as a Home Subscriber Server (HSS) database 126, which maintains a unique service profile for each end user. HSS 126 may be accessed by session control layer 120 and may also be accessed by application server layer 130 (dashed line), for example, for subscribing to user profile data and / or services. The end user's service profile stores all user service information and preferences in a central location. This includes the end user's current registration information (i.e. IP address), roaming information, telephony information (i.e. call forwarding information), instant messaging service information (i.e. buddies list), Voice mail box options (i.e. greetings) and the like. By centralizing this information, applications can share information to create integrated personal directories, multi-client type presence information, and blended services. This centrally arranged arrangement also ensures a continuous view of active subscribers across all services and greatly simplifies the management of user data.

Session control layer 120 also includes a Media Gateway Control Function (MGCF) 128, which allows SIP signaling to interwork with the signaling (i.e., H.248) used by the media gateway. interwork). MGCF 128 manages the distribution of sessions across multiple media gateways. Media Server Function Control (MSFC) 129 provides similar functionality for the media server.

Application server layer

Application server layer 130 includes an application server, which provides end-user service logic. The application server layer 130 also communicates with the HSS 126 to access user profile data. Example servers include parlays and SIP application servers. IMS architecture and SIP signaling are flexible to support multiple telephony and non-telephony application servers. For example, the SIP standard was developed for telephony services and instant messenger (IM) services.

Service broker

An extension to the IMS architecture is required to support a rich set of services. There are many VoIP endpoints that do not currently support SIP signaling. For example, IP-PBX typically uses H.323. Integrated Access Devices (IADs) that support VoIP for DSL often use MGCP. As a result, to support this famous endpoint in the IMS network, it is required to interwork non-SIP signaling with SIP. A new border signaling gateway is proposed to provide this interworking. Consumers require real-time communication services to work together in a consistent way. This allows service providers to bundle and interwork services to provide new blended capabilities. For example, end users of long IM sessions may wish to spawn voice sessions without the effort of looking up phone numbers and restoring separate voice sessions. When the end user is engaged in a PTT session, the incoming voice call should call the call waiting service.

Although a standard IMS service structure can support many different real time communication applications at the same time, additional service interworking or service brokering may be required to provide this blended service. To allow for wider feature interaction management, the IMS standard adds functions to the service layer between call / access control and sub-layers of the service layer suitable for feature interaction management. Regulate. This function is called "Service Coordination and Interaction Manager" (SCIM). The precise operation and functionality of SCIM is not defined by standard or means that can be configured.

As a result, in accordance with an exemplary embodiment of the present invention, the example IMS service structure 100 may include a service capability interaction manager (SCIM), in which state information between applications and Referred to as a service broker 125 (or service broker function), which can share application state. The service broker 125 resides in the session control layer 120 and has a corresponding interface to the interworking application. Service broker 125 thus integrates multiple applications into meaningful service offerings, allows participating applications to be unaware of each other, and programmability with an application programming interface (API) for a combination of services. It provides important functionality such as providing programmability.

For a more detailed description of the functionality and internal configuration of the service broker 125, the "providing a blending of services, filed September 20, 2005, by Kocan et al., Co-pending and generally assigned. US Patent Application No. 11 / 231,166 entitled "ENHANCED SYSTEM FOR CONTROLLING SERVICE INTERACTION AND FOR PROVIDING BLENDING OF SERVICES," which is hereby incorporated by reference in its entirety. Cited by reference.

Since the IMS structure is equally suitable for wireless, wired and converged networks, the service broker 125 is completely consistent with this aspect of the IMS structure because it is essentially end point / access neutral. The service broker 125 handles the matching and matching of services to control service interactions and / or to provide rich end user experiences. In addition, service broker 125 can span different endpoints, such as analogs, softphones, or cordless phones, and can be used for end-user functions such as voice only, voice / data or voice / data / multimedia. To facilitate the user's convenience of customizing based service presentations. The service broker 125 may store and use changing user data and session context data to achieve multi-session awareness and to handle concurrent and sequential context-sensitive interactions.

Thus, in addition to the "service blending" function, by intercepting their commands and adapting them to the selected media server command interface, the services may be provided by other components of the IMS architecture, even though The broker 125 may be used to share network services such as media servers across multiple applications. In addition, the service broker 125 cooperates with other systems in the maintenance infrastructure to bring together the information about billing, and the operation is an abstracted viwe extracted to other components of the communication network. And system support.

2 is a flow chart illustrating a method of providing blending of services to a subscriber in accordance with an exemplary embodiment of the present invention. In general and with reference to FIG. 2, subscribers of a service may use the service architecture of these two platforms to take advantage of the blending of the services to subscribers of the service provided by a TV delivery system such as IPTV and a communication network such as 3GPP / IMS. Can be. Thus, in FIG. 2, in the exemplary method 200, the subscriber's communication network receives a message request 210 from the sender side. In the example, the network is a 3GPP / IMS network and the message request is a SIP INVITE message from the sender side.

SIP is based on an HTTP-like request / response transaction model. Each transaction consists of a request that invokes a particular method or function on the server and at least one response. In the example, the transition is an "Alice's" softphone (a softphone is a multi-media application that works in conjunction with VoIP technology that allows a user to make a call directly from their PC or laptop). You can begin with sending a message request (SIP-INVITE) that is sent to this "Bob's" unique resource identifier (URI). The INVITE request message (SIP-INVITE) is an example of a SIP method for specifying an operation that the requester Alice wants to receive from the server Bob.

SIP-INVITE contains a number of header fields, which are named attributes that provide additional information about the message. The header field is in SIP-INVITE and contains at least information about the type of session Alice wants to establish with Bob, Alice's address, destination address, and a unique identifier for the call.

Thus, the message request can be received directly by the service broker function in the communication network. In an example, service broker 125 of session control layer 120 may receive a message request. In another example, the server of the communication network may receive a message request from the sender side and send the message request to a service broker function of the 3GPP / IMS network. For example, this may be a SIP proxy server, such as CSCF 127 of FIG.

Since the subscriber has subscribed to a blended service that includes a display of the caller ID service on the TV delivery system, the service broker function is in addition to performing service package information based on the message request to provide the caller ID information to the TV delivery system. The modified message on the subscriber's phone such that the alerting of the subscriber's phone is modified while the caller ID information of the calling party is displayed on the subscriber's TV delivery system. Send the request 230 (either directly or through a proxy server). If the message request is embodied in SIP-INVITE, the Service Broker function may change the "alert" of the SIP-INVITE header to alter the alerting (ringing, tone, visual indication or otherwise) of the subscriber's phone. Has the ability to change the "Alert Info" header field. In the example where the service broker function has set the alert information header field to "0", the alerting on the subscriber's phone ensures that the caller ID information is placed on the subscriber's TV delivery system so as not to interfere with the sound of the program shown by the subscriber. It can be suppressed while displayed.

Thus, service broker functions, such as service broker 125, serve as SCIM in a communication network and provide the ability to blend services using other service delivery structures, such as those of a TV delivery system. Since service broker 125 is a programmable element and has an API, the two example scenarios differ in order to convey the scope of functionality of service broker 125 and its potential for enriching the end user experience. It is described in relation to the corresponding relationship between the structures.

 3A and 3B show the relationship between the service structure of a communication network and a TV delivery system. In this example, the wireless communication network may be a 3GPP / IMS core network, the TV delivery system may be an IPTV system, and it is understood that the example methodology may be applied to other platforms besides IPTV for blending of services. 3A and 3B, the session control layer of the streaming structure 300 of the IPTV delivery system and the IMS 350 of the communication network is shown.

As described above in FIG. 1, the session control layer 350 of the IMS includes a service broker 355 in communication with the server 357, for example, a SIP server (CSCF 127) or other proxy server. Can be. The service broker 355 is configured to perform the IPTV service package 352 based on the service subscribed to by the subscriber, as reflected in the subscriber database 356. Subscriber database 356 may be a Home Subscriber Server (HSS), which may be several physical databases. This depends on the number of subscribers and the range of services needed to be supported. The HSS holds the identities and variables for the support, establishment and maintenance of sessions and calls made by the subscriber. The server 357 and / or service broker 355 may be a subscriber's handset 304, which may be a WiFi / GSM handset registered with the IMS, and an endpoint such as the subscriber's mobile phone 354. It may be provided. The content streaming structure 300 on the IPTV side may process TV stream data for display on the IPTV 310 and communicate with a subscriber input device (not shown), such as a remote control or browser interface, to process the TV control data. IPTV server 305 that can be. The IPTV system may or may not support an interface between the IPTV server 305 and the service broker 355 to receive receiver ID data for display on the IPTV 310.

Thus, an overview of the relationship between the structures has been described, and two scenarios have been described to illustrate the scope of the service broker's functionality and its possibilities for enriching the end user experience. This scenario includes two subscribers, Alice and Bob. Alice has signed up for an offer that provides caller ID to her IPTV service with the optional "Silent Alerting". Bob has subscribed to VoIP, but has an independent IPTV delivery system using a Set Top Box that can support a window-like environment. Bob has subscribed to an offer that provides the caller ID with optional "Silent Alerting" and the ability to control call disposition from a TV remote control device.

IPTV And caller ID  And modified Alerting  Scenario 1

In this scenario, Alice's IPTV delivery system supports an interface that receives a caller ID from a communication system or network (eg, IMS 350) and displays it on a user's (Alice's) TV. In addition, an IPTV set top box (not shown in FIG. 3A) supports applications such as a browser function (see browser window 315), whereby a user can click on a link as desired. IMS 350 includes a service broker 355, which may provide for initiating and terminating service brokering. To Alice's WiFi / GSM handset (mobile phone) 354 (i.e., mobile phone), when it is registered with IMS 350, when the call is terminated and Alice's home phone 304 (which supports SIP) And terminating the call (also referred to as a SIP telephone), the service broker 355 provides caller ID information to the IPTV application to the IPTV server 305. The service broker 355 may modify or suppress normal alerting (eg, ringing) of this phone by modifying the Alert Info header field of the SIP INVITE to be sent to the terminating device. The scenario is described in more detail below with reference to FIG. 3A. As an alternative to completely suppressing alerting, the alert information header may be set to result in a "ping" or other less-intrusive alert.

Alice is resting and watching TV. The call comes, but Alice has subscribed to the Caller ID service so she can see who the call is from the TV set. She can also activate the modified alerting feature, which in this example is called "Silent Alerting", which prevents her phone from alerting. She can even see who is trying to reach her, on her GSM / WiFi cell phone 354 because she is at home and it is registered with IMS 350.

Alice turns on her TV 310 and selects a program from the IPTV program guide provided through the STB (not shown in FIG. 3A). The call enters IMS for Alice's home phone 304. Since Alice has subscribed to the blended service, server 357 sends a SIP INVITE message to service broker 355.

If not cached, service broker 355 retrieves Alice's terminating service package information from subscriber database 356 (such as HSS) and begins to perform IPTV service package 352. do. If the calling name is not encapsulated in the SIP INVITE message (since it may be for a call coming from the PSTN), the service broker 355 may call the calling name web server (not shown). You can ask questions to obtain this information.

The service broker 355 sends a SIP INVITE message to Alice's home telephone 304 via the server 357 and proscribes its calling name information (caller ID information 320). Send to IPTV application to IPTV server 305 on the interface.

Alternatively, if server 357 does not exist, service broker 355 may be configured to receive this SIP INVITE message directly. In the example, assuming that the interface allows for additional text, the service broker 355 may include an invitation to silent alerting.

The phone 304 rings and Alice sees the caller ID on the TV 310 with an invitation to activate quiet alerting at the same time. Since the program is very entertaining and the call is not urgent, Alice allows the phone 304 to ring until it is switched to voice mail. Since the ringing missed, she pulled out her on-screan browser window 315 and clicked on her favorite link to activate quiet alerting. Note that when silent alerting was set before the start of the program or could be set to default options, no recommendation is required.

Clicking on the link causes an HTTP request to be sent to service broker 355, which sends a web page that allows Alice to select an inactivity time or leave a default inactivity (such as two hours) in effect. Alice chooses her desired inactivity time. A send click on window 315 sends an HTTP request to service broker 355 with this information. The service broker 355 enters the appropriate information into Alice's user data on the subscriber database 356 for use in future calls.

Another call enters IMS for Alice's home phone 304 and server 357 sends a SIP INVITE message to service broker 355.

The service broker 355 retrieves Alice's terminating service package information from the subscriber database 356, which now indicates that quiet alerting is active and begins to perform the service package 352. If the calling name is not encapsulated in the SIP INVITE message, the service broker 355 queries the calling name web server to obtain this information.

Since quiet alerting is active, service broker 355 sets the alert-information of the SIP INVITE message to "0" to change the field. The service broker 355 then sends a modified SIP INVITE message to Alice's home phone via the server 357 (or directly if the server 357 does not exist) and sends the caller ID information 320 to it. To the IPTV application to the server 305 on the forbidden interface.

Alice sees the caller ID on TV 310 but interprets Alice's phone 304 as receiving a modified SIP INVITE and indicates that there is no alerting of alert-information set to "0". ) Does not ring. As the call is urgent, Alice picks up phone 304 and answers the call.

Another call enters IMS 350 for Alice, but this time to her mobile (GSM / WiFi) phone 354. The call comes to IMS 350 because Alice is at home with her cell phone 354 and it has been registered with IMS. Server 357 sends a SIP INVITE message to service broker 355. Alternatively, if there is no server 357, service broker 355 may be configured to receive this SIP INVITE message directly.

As discussed above, the service broker 355 retrieves Alice's terminating service package information from the subscriber database 356, which now indicates that quiet alerting is active and begins to perform the service package 352. . As mentioned above, if the calling name is not encapsulated in the SIP INVITE, the service broker 355 may query the calling name web server to obtain this information. Since the quiet alert is active, the service broker 355 sets the alert information in the header field of the SIP INVITE to "0". The service broker 355 then sends the modified SIP INVITE to Alice's mobile phone 354 via the server 357 and sends the caller ID information 320 to the IPTV of the server 305 on its forbidden interface. Send to the application. Assuming the interface allows for additional text, the service broker 355 includes an indication that Alice's mobile phone 354 is being called.

Alice sees the caller ID on TV 310 with an indication that Alice's mobile phone 354 is being called, but freezes alert-information where phone 354 received a modified SIP INVITE and was set to "0". The phone 354 does not ring because it interprets that there is no casting. Since the call is urgent, Alice picks up the mobile phone 354 to answer the call. For some GSM / WiFi roaming structures, and in other examples, home phone 304 may also receive a modified SIP-INVITE message when mobile 354 is registered with IMS 350 and is present at home.

Scenario 1 thus describes a blended service of TV caller ID with modified alerting (quiet alerting) using the SIP Alert-Info header. In this example scenario, SIP VoIP is designed to correctly interpret and support alert-information settings, and service broker 355 changes the alert-information header based on the information it obtains from the user for its HTTP interface. do. Another feature of this blended service is to provide mobile phone 354 with caller ID and quiet alerting for the call. This is possible by the GSM / WiFi roaming and service broker 355 sending an indication that the call is to a mobile phone 354.

As described above with respect to FIG. 3A, both the IMS structure and the IPTV content streaming structure for the communication / session service participate in this blended service. IP addresses (using DSL) are shared by all structures. The service broker 355 acts as a SCIM and serves to melt the two service structures by sending event data from the IMS 350 to the IPTV system 300. The service broker 355 is thus configured to receive a specific activation request from the user and to modify the SIP message based on the specific application blending logic (including activation information).

IPTV And caller ID  And modified Alerting  Scenario 2

Referring to FIG. 3B, in this case the TV delivery system 300 does not support an interface to the communication system (IMS 350) for the caller ID. However, set top box 320 is used, which is an application (client software that can set a focus window to receive events from a TV remote control (eg, events can be mapped to keystroke events). And a window-like environment in which 325 can be driven. Depending on the TV remote control event, the service broker 355 of the IMS 350 of the network can communicate with the client software of the STB 318 and can handle incoming SIP INVITE messages. The scenario is described in more detail below with reference to FIG. 3B.

Bob is watching TV while resting. Although the call comes, Bob can see who the call is from on the TV set 310. He can also activate the modified alerting feature, which in this example is called "Silent Alerting", which prevents his phone from being alerted, sending a call in voicemail or sending his TV remote May stop from adjustment (not shown in FIG. 3B).

Bob turns on his TV 310 and selects a program from the IPTV program guide provided through STB 318. The call enters IMS 350 for Bob's home phone 304. Since Bob has subscribed to the blended service, server 357 sends a SIP INVITE message to service broker 355. Alternatively, service broker 355 may be configured to receive this SIP INVITE message directly. The service broker 355 retrieves Bob's terminating service package information from the subscriber database 356 (if not cached) and begins to perform the service package 352. If the calling name is not encapsulated in the SIP INVITE message (since it may be for a call coming from the PSTN), the service broker 355 may call the calling name web server (not shown). You can ask questions to obtain this information.

The service broker 355 sends a SIP INVITE message to Bob's home phone 304 via the server 357 and sends the caller ID information 320 'to the client software application 325 on Bob's STB 318. do. The phone 304 rings and Bob simultaneously sees the caller ID on the TV, rejects the call, and voices the call, with a clickable link (via TV remote control) to activate quiet alerting for a given period of time. Send by email.

Since the program is so fun and the call is not urgent, Bob clicks on the link to send the call to voicemail. Since the echo missed, he clicks to activate quiet alerting. Clicking on the link causes an HTTP request to be sent to service broker 355. The service broker 355 sends a SIP INVITE message to the voice messaging system and then puts the appropriate information into Bob's user data on the subscriber database 356 for use in future calls.

Another call enters IMS for Bob's home phone 304 and server 357 sends a SIP INVITE message to service broker 355. Alternatively, service broker 355 may be configured to receive SIP INVITE messages directly. The service broker 355 retrieves Bob's terminating service package information from the subscriber database 356, which now indicates that quiet alerting is active and begins to perform the service package 352. If the calling name is not encapsulated in the SIP INVITE message, the service broker 355 queries the calling name web server to obtain this information.

Since quiet alerting is active, service broker 355 sets the alert-information of the SIP INVITE message to " 0 ". The service broker 355 then sends the modified SIP INVITE message to Bob's home phone via the server 357 (or directly if the server 357 does not exist) and sends the caller ID information 320 '. Send to Bob's client software application 325 on STB 318.

Bob sees the caller ID on the TV, but the phone 304 does not ring because Bob's phone 304 receives a modified SIP INVITE and interprets the alert-information set to "0" to indicate no alerting. Do not. The call is urgent and Bob picks up the phone 304 and answers the call.

In scenario 2, that is, as long as the IPTV client software application 325 can operate in a window-type environment and the STB 318 can support a window-type environment, the TV caller ID service allows independence of the IPTV delivery service. do. The functionality added to this version may be based on the client software 325, holding a TV remote event and sending an HTTP message to the service broker 355 to affect the call handling. Further, more complex functionality may be possible if the client software 325 on the STB 318 provides an SPI such that the software client interacting with the service broker 355 has more complete information. An example may indicate which program is being viewed. In this case, the parent's alert and control functions (as described for the incoming and outgoing calls) may be implemented for a particular program.

Exemplary embodiments of the invention have been described accordingly, and it will be apparent that equivalents may be varied in many ways. Such changes are not to be regarded as a departure from the spirit and scope of the exemplary embodiments of the invention, and all such modifications are apparent to those skilled in the art and are construed as being included in the scope of the following claims.

Claims (10)

A method of providing blending of services to subscribers of one or more services of a communication network (350) and one or more services of a TV delivery system (300, 305, 310) in communication with the network, Receiving a message request from a calling party (210), Changing (220) information in the message request to generate a modified message request; Sending 230 the modified message request to the subscriber's phone such that the alerting of the subscriber's phone 304, 353 is modified while the caller's side information is displayed on the TV delivery system. doing How to provide blending of services. The method of claim 1, When receiving the message request, performing service package information related to a TV delivery system. How to provide blending of services. The method of claim 2, The step of performing, Obtaining caller ID information of the caller side; Transmitting caller ID information to applications 305 and 325 of a TV delivery system to display name and number information of the caller side; How to provide blending of services. The method of claim 1, The message request is a SIP INVITE message, The changing may further include changing a header field of the SIP INVITE message. How to provide blending of services. The method of claim 4, wherein The header field includes alert information specifying an alerting or ringing tone for the subscriber's telephone, The modifying further comprises setting the alert information header field of the SIP INVITE to a given value to modify the currently selected ring tone or to suppress the ring tone on a subscriber's phone. How to provide blending of services. The method of claim 4, wherein The header field includes alert information specifying an alerting or ringing tone for the subscriber's telephone, The changing may further include setting the alert information header field of the SIP INVITE to '0' to suppress alerting of the subscriber's telephone. How to provide blending of services. A communication network (350) that provides blending of services to subscribers of one or more services of a network and one or more services of a TV delivery system (300, 305, 310) in communication with the network, A server 357 which receives a message request from a calling party and sends the message request, A service broker function 355 in communication with the server to share information between a TV delivery service and an application on the network, The server sends the message request to the service broker function, The service broker function When receiving the message request, perform service package information related to the service of the TV delivery system subscription to include obtaining and delivering caller ID information of the caller side, Change the information of the message request, generate a modified message request sent through the server to the subscriber's telephones 305 and 354, change the alerting of the subscriber's telephone, Sending the caller ID information of the caller side to an application 305, 325 of the TV delivery system for display. Communication network. The method of claim 7, wherein The message request is a SIP INVITE message, The service broker function is adapted to modify the currently selected ring tone on the subscriber's phone or to change the alert information header field of the SIP INVITE message to a given value to suppress the ring tone. Communication network. The method of claim 8, The header field includes alert information specifying a ringing tone or alerting for the subscriber's phone; The service broker is adapted to set the alert information header field of the SIP INVITE message to '0' to suppress alerting of the subscriber's phone. Communication network. In a service broker 125, 355 in a communication network 350 that shares information between a TV delivery system and an application of the communication network to facilitate blending of services to be provided to subscribers of the network and TV delivery system. Upon receiving a message request from a caller side, perform service package information 352 associated with the service of the TV delivery system subscription to include obtaining caller ID information of the caller side, Change the information of the message request to generate a modified message request, While transmitting the caller ID information of the caller side to the application 305, 325 of the TV delivery system for display, the subscriber's phone 304, 354 to modify the alerting of the subscriber's phone. Sending the sending of a modified message request Service broker.

Images