US20040047339A1 - Architecture and method for controlling features and services in packet-based networks - Google Patents
Architecture and method for controlling features and services in packet-based networks Download PDFInfo
- Publication number
- US20040047339A1 US20040047339A1 US10/243,642 US24364202A US2004047339A1 US 20040047339 A1 US20040047339 A1 US 20040047339A1 US 24364202 A US24364202 A US 24364202A US 2004047339 A1 US2004047339 A1 US 2004047339A1
- Authority
- US
- United States
- Prior art keywords
- message
- profile
- end device
- features
- services
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42136—Administration or customisation of services
- H04M3/42144—Administration or customisation of services by service provider
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
- H04L41/5048—Automatic or semi-automatic definitions, e.g. definition templates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5058—Service discovery by the service manager
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M7/00—Arrangements for interconnection between switching centres
- H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
- H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
Definitions
- the present application relates to an architecture and method for controlling multimedia features and supplementary services in packet-based networks.
- the present application relates to an architecture and method for controlling the multimedia features and supplementary services, such as call waiting, call forwarding, and caller identification (ID), that are implemented within Internet Protocol (IP)-based telephony technology, such as a packet-based network using Session Initiation Protocol (SEP) for its communications.
- IP Internet Protocol
- SEP Session Initiation Protocol
- PSTN public switched telephone network
- IP IP-based circuit switches
- IP-based telephony technology such as SIP
- many end devices may be able to provide the multimedia features and supplementary services without permission from the network-centric devices of the service providers.
- the capability of controlling the feature/service delivery from these network-centric devices may also be deteriorated.
- service providers will likely be able to only enable uniform multimedia features and supplementary services for all of its customer's end devices or rely on static provisioning for each such end device to enable/disable certain unwanted features/services.
- Uniform feature delivery is neither desirable to service providers nor flexible to the customers.
- the customer e.g., business user
- static provisioning of each phone separately requires high management and maintenance efforts, and also does not meet the requirement of delivering the features on a per user account basis (i.e., such provisioning is delivered on a per end device basis).
- the present invention defines an architecture and mechanism for network core devices (e.g., SIP servers) to control end devices (e.g., SIP phones) to deliver the multimedia features and supplementary services dynamically and based on per user account profiles.
- network core devices e.g., SIP servers
- end devices e.g., SIP phones
- service providers can selectively provide these services to proper groups of users by indicating such feature/service information in the communication packets (e.g., SIP messages).
- the end devices used with the present invention will also provide multimedia features and supplementary services only as directed in such communication packets. Consequently, service providers will regain network-concentric control over the multimedia features and supplementary services that they provide in an IP or hybrid PSTN/IP telephony system.
- the present application provides a method for controlling features and services in packet-based networks comprising the step of identifying a profile, specifying which features and services may or may not be implemented by an end device, from user account information stored on a network core device.
- the method also comprises the steps of adding the profile to at least one message, and sending the at least one message from the network core device to the end device.
- the present application provides another method for controlling features and services in packet-based networks that comprises the steps of sending a first message to a network core device, and identifying a profile, specifying which features and services may or may not be implemented by an end device, from user account information stored on the network core device.
- the method further comprises the steps of adding the profile to a second message, and sending the second message from the network core device to the end device.
- the present application also provides yet another method for controlling features and services in packet-based networks using the session initiation protocol that comprises the steps of sending a first message to a session initiation protocol server, and identifying a profile, specifying which features and services may or may not be implemented by a session initiation protocol phone, from user account information stored on the session initiation protocol server.
- the method further comprises the steps of adding the profile to a second message, and sending the second message from the session initiation protocol server to the session initiation protocol phone.
- the present application provides a system for controlling features and services in packet-based networks communications.
- the system comprises an end device in communication with a network core device, and a profile identified from user account information stored on the network core device.
- the profile specifies which features and services may or may not be implemented by the end device.
- the system further comprises at least one message including the profile, wherein the at least one message is sent from the network core device to the end device, and the end device implements only the features and services allowed to be implemented by the profile of the at least one message.
- the present application provides another system for controlling features and services in packet-based networks communications.
- the system comprises a first end device in communication with a network core device, and a second end device in communication with the network core device.
- the second end device is also in communication with the first end device via the network core device.
- the system also comprises a profile identified from user account information stored on the network core device, with the profile specifying which features and services may or may not be implemented by an end device.
- the system further comprises a first message and a second message, with the second message including the profile.
- the first message is sent from an end device to the network core device
- the second message is sent from the network core device to an end device
- the end device receiving the second message implements only the features and services allowed to be implemented by the profile of the second message.
- FIG. 1 is a block diagram illustrating an exemplary system and method of the present invention for controlling features and services used by packet-based network devices.
- FIG. 2 is a block diagram illustrating an exemplary system and method of the present invention for controlling features and services used by SIP devices.
- FIG. 3 is a flow diagram illustrating control via a register message of features and services used by an end device.
- FIG. 4 is a flow diagram illustrating control via a register message of features and services used by an SIP phone.
- FIG. 5 is a flow diagram illustrating control via an invite message of features and services used by an end device.
- FIG. 6 is a flow diagram illustrating control via an invite message of features and services used by an SIP phone.
- FIG. 7 is a flow diagram illustrating control via a response message of features and services used by an end device.
- FIG. 8 is a flow diagram illustrating control via a response message of features and services used by an SIP phone.
- FIG. 1 shows an exemplary embodiment of a system 10 and method for controlling multimedia features and supplementary services used by packet-based network devices.
- the system 10 comprises a first end device 12 , a first network 14 , a network core device 16 , a second network 18 , and a second end device 20 .
- the first and second end devices 12 , 20 are in communication with the first and second networks 14 , 18 , respectively, and the first and second networks 14 , 18 are both in communication with the network core device 16 .
- the network core device 16 bridges communications between the first and second end devices 12 , 20 across their respective networks (i.e., the first and second networks 14 , 18 ).
- first and second networks 14 , 18 may be one in the same, thereby resulting in both the first and second end devices 12 , 20 being in communication with, and residing on, the same single network. It should also, be understood the communication between the devices and networks may be physically established via wireline, wireless, or a combination of wireline and wireless links.
- the first and second end devices 12 , 20 are preferably packet-enabled network devices, such as personal computers, handheld computer devices (e.g., Personal Digital Assistants (PDAs)), cellular phones, SIP phones, and other “intelligent” or “smart” phones, that are located on the premises and under the control of the end user or customer.
- the first and second networks 14 , 18 are preferably packet-based networks.
- the network core device 16 is also preferably a centrally located and controlled server device, such as an SIP server, that is located on the service provider's premises and controlled by the service provider.
- the network core device 16 contains account information for each of the end users or customers subscribing to the service provided by the service provider.
- the account information may include such information as the customer's billing address, an identification of the customer's devices, and a list of the features and services to which the customer has subscribed.
- FIG. 2 illustrates an exemplary system 30 and method implementation of the system 10 and method of FIG. 1 using SIP.
- the system 30 comprises a first SIP phone 32 , a first packet based network 34 , an SIP server 36 , a second packet based network 38 , and a second SIP phone 40 .
- the first and second SIP phones 32 , 40 correspond to the first and second end devices 12 , 20 , and may be any suitable phone that uses SIP for its communications. It should be understood that while SEP phones are used as end devices in FIG. 2, any other network device using SIP for its communications may be used as the end devices.
- the first and second packet based networks 34 , 38 correspond to the first and second networks 14 , 18 .
- the SIP server 36 corresponds to the network core device 16 .
- the SIP phones, the packet based networks, and the SIP server are all in the same communication as their corresponding devices and networks in the system 10 .
- the first and second packet based networks 34 , 38 may be one in the same, thereby resulting in both the first and second SIP phones 32 , 40 being in communication with, and residing on, the same single packet based network.
- the communication between the SIP phones, the packet based networks, and the SIP server may be physically established via wireline, wireless, or a combination of wireline and wireless links.
- the systems 10 , 30 of FIGS. 1 - 2 both operate in the same manner.
- One of the end devices/phones sends a message (e.g., a REGISTER or INVITE message) to the network core device/server or to the other end device/phone via the network core device/server.
- the network core device/server looks up account information for the user of end device/phone that sent the message (and/or the end device/phone that is receiving the message) and identifies a profile of the features and services that the user subscribes to or has canceled.
- These features and services may include any number of different multimedia features and supplementary services, such as call waiting, call forwarding, caller ID, call transfer, call conferencing, call hold, speed calling, and the like.
- the network core device/server adds the profile to the header of a response message or to the header of the original message (thereby creating a new message consisting of the original message plus the profile information).
- the network core device/server may add the profile to the header of any other message that is being sent from the network core device/server to an end device, regardless and/or independent of any previous message being sent from an end device. Any number of different formats may be used to add the profile information to the message header, depending on what communication protocol is being used by the end devices/phones and the network core device/server.
- the profile information may be added to the message header by inserting “X-multimedia-service-enabled:” into the header, followed by a list of the features and services that are subscribed to (e.g., “yes”) and/or canceled (e.g., “no”).
- the profile information may be added to more than one message being sent from the network core device/server to an end device.
- the profile information may be broken up and added in pieces to multiple messages being sent from the network core device/server to an end device. For example, some profile information may be sent from the network core device/server to an end device as part of a response message, while other profile information may be sent from the network core device/server to an end device as part of a new message that includes the original message.
- the network core device/server After adding the profile information to the message, the network core device/server then sends the new message back to the end device/phone that sent the original message (or the other end device/phone designated to receive the original message).
- the end device/phone Upon receiving the new message containing the profile, the end device/phone preferably implements only features and services as specified and set forth in the profile. Such implementation preferably occurs regardless of the individual capabilities of the end device/phone. As a result, control of the features and services utilized by a user or subscriber is restored to and maintained centrally by the service provider.
- FIGS. 3 - 8 and the below description provide further details about the exemplary methods of the present invention and the operation of the systems 10 , 30 of FIGS. 1 - 2 .
- a general description of SIP will be provided.
- SIP defines a protocol for establishing, modifying and terminating sessions over packet data networks, such as IP networks.
- SIP can be used to establish real-time data sessions and Internet telephony sessions, such as VoIP sessions.
- VoIP sessions Internet telephony sessions
- SIP can be used to establish many other types of sessions.
- SIP also supports name-mapping and redirection services, which allows a user to initiate a session from different locations and allows the user to be identified at the various different locations.
- SIP users and thus their devices, are identified using SIP identifiers, which are typically telephone numbers or web host names.
- SIP identifiers could be of the form “SIP:name@domain.com.”
- SIP supports other types of identifiers.
- An SIP user can register with a SIP server, such as by sending a registration message that identifies the user and the user's current location. Once registered with the SIP server, the SIP server can be used to facilitate establishing a session between two devices.
- the SIP server can receive a request from a first device (e.g., a first SIP phone) that wants to use SIP to establish a session with a second device (e.g., a second SIP phone).
- the first device and/or the second device could previously have registered with the SIP server via a REGISTER message.
- the SIP server could send a response message called “200 OK,” wherein the “200” represents that the message is a response to a register request and the “OK” represents that the registration request has been accepted.
- the first device could send the SIP server a request to establish a session with the second device in the form of an SIP INVITE message.
- the SIP server could then forward the request directly to the second device.
- the first device could send the SIP INVITE message directly to the second device.
- the second device would send a response message (e.g., “200 OK”) to first device via the SIP server.
- SIP generally runs at the application layer of the Open Systems Interconnection (“OSI”) model.
- SIP messages can then be carried by protocols running at lower layers of the OSI model, but SIP is not confined to using specific lower level protocols. Consequently, SIP messages, such as an SIP REGISTER message that can be used to register a device with an SIP server, or an SIP INVITE message that can be used to establish a session, can be sent using any transport protocol.
- SIP messages can be transmitted using the Transmission Control Protocol (“TCP”) or the Universal Datagram Protocol (“UDP”).
- TCP and UDP typically run at the transport layer of the OSI reference model.
- these protocols can be used in conjunction with protocols running at even lower levels of the Open Systems Interconnection (“OSI”) reference model.
- OSI Open Systems Interconnection
- UDP or TCP could be used in conjunction with IP, which typically runs at the network layer of the OSI reference model.
- SIP Session Initiation Protocol
- Step 102 the method 100 for controlling the features/services implemented by an end device begins with Step 102 , wherein an end device (e.g., first end device 12 ) sends a REGSITER message to the network core device 16 .
- the network core device receives the REGISTER message from the end device, and looks up the account information that is stored on the network core device and corresponds to the user of the end device.
- This account information may include details regarding the user, his or her billing information, his or her end devices, and the features/services that he or she has subscribed to and/or canceled.
- such features/services may include call waiting, call forwarding, caller ID, call transfer, call conferencing, call hold, speed calling, and the like.
- the network core device examines the account information and identifies a profile for the end device from the account information corresponding to the user of the end device.
- the profile includes information describing what features/services the user has subscribed to and/or canceled.
- the profile information may indicate that a user or customer has subscribed to call forwarding and caller ID, but has canceled call waiting.
- the profile may indicate only those features/services that the user has subscribed to, and by default, all other features that have not been subscribed to are treated as canceled by the user.
- the profile information is the same for every end device identified in the user's account information as being associated with the user. In other words, a single profile of subscribed/canceled features and services may be used for each of a user's end devices.
- Step 108 the network core device registers the end device, and sends a response message to the end device indicating such registration and containing the profile information for the user of the end device.
- the network core device may add the profile information to a single message, or alternatively, multiple messages being sent from the network core device to the end device.
- the profile information may be broken up and added in pieces to multiple messages being sent from the network core device to the end device.
- a single message is described in detail as containing the profile information in the exemplary embodiments of the present application. It should be understood, however, that any number of different messages and message formats may be used to contain and convey the profile information from the network core device to the end device.
- the end device After receiving the response message from the network core device, the end device implements the features/services specified in the profile contained within the response message in step 110 . Preferably, the end device implements only those features/services specified in the profile. For example, if the profile information specifies that the user has subscribed to call forwarding and caller ID, but has canceled call waiting, the end device will be enabled with call forwarding and caller ID capabilities, but not call waiting. In addition, or alternatively, the end device may enable only those features/services indicated in the profile as being subscribed to by the user, and may disable all other features/services not indicated in the profile as being subscribed to by the user (regardless of whether such features/services are indicated in the profile as canceled by the user). The end device then proceeds to communicate with other end devices based on its profile, and the method 100 ends.
- the network core device may decide to reject a registration request and any subsequent call signaling from any end devices that are not capable of reading messages containing profile information or that are not capable of implementing only features/services specified in the profile information.
- end devices that are not restricted and bound by message profile information from registering with the network core deyice (and thus preventing them from communicating with other end devices via a service provider's network)
- service/network providers retain control over what features/services are implemented by its end devices.
- the network core device may send the profile information corresponding to a user's account information in a message other than a response to a registration request.
- the network core device may simply send an end device a message that contains the profile information that controls which features/services the end device may or may not implement, and the message need not be a response message sent after a register message.
- profile information may be conveyed to an end device by adding the profile information to any message (or messages) sent from the network core device to the end device at any time.
- Step 202 the method 200 for controlling the features/services implemented by an SIP device begins with Step 202 , wherein an SIP device (e.g., first SIP phone 32 ) sends a REGSITER message to the SIP server (e.g., SIP server 36 ).
- SIP server e.g., SIP server 36 .
- Table 1 illustrates an exemplary format for this REGISTER message. TABLE 1 REGISTER sip:whatever.net SIP/2.0 To: sm@whatever.net From: sm@whatever.net CSeq: 1 REGISTER Contact: sip:sm@149.112.90.46 Expires: 3600
- the SIP phone is identified by its e-mail address, which in this example is sm@whatever.net. It should be understood that the REGSITER message format shown in Table 1 is merely exemplary, and other formats may be used for the REGISTER message of the present invention.
- the SIP server receives the REGISTER message from the SIP phone, and looks up the account information that is stored on the SIP server (or another server or storage device in communication with the SIP server) and corresponds to the user of the SIP phone.
- This account information may include details regarding the user, his or her billing information, his or her end devices, and the features/services that he or she has subscribed to and/or canceled. As previously mentioned, such features/services may include call waiting, call forwarding, caller ID, call transfer, call conferencing, call hold, speed calling, and the like.
- the SIP server examines the account information and identifies a profile for the SIP phone from the account information corresponding to the user of the SIP phone.
- the profile includes information describing what features/services the user has subscribed to and/or canceled.
- the profile information may indicate that a user or customer has subscribed to call forwarding and caller ID, but has canceled call waiting.
- the profile may indicate only those features/services that the user has subscribed to, and by default, all other features that have not been subscribed to are treated as canceled by the user.
- the profile information is the same for every SIP phone identified in the user's account information as being associated with the user. In other words, a single profile of subscribed/canceled features and services may be used for each of a user's SIP phones.
- Step 208 the SIP server registers the SIP phone, and sends a response message to the SIP phone indicating such registration and containing the profile information for the user of the SIP phone.
- the response message is a 200 OK response message containing a header line setting forth the identified profile for the user.
- Table 2 illustrates an exemplary format for this 200 OK response message.
- the profile is contained within the “X-multimedia-service-enabled” field, with enabled or subscribed features/services being indicated with a “yes” and disabled or canceled features/services being indicated with a “no.”
- call waiting CW
- cancel call waiting CCW
- caller number delivery CND
- the 200 OK response message format shown in Table 2 is merely exemplary, and other formats may be used for the response message of the present invention.
- the profile line following the “X-multimedia-service-enabled” field may simply list only the features/services that are enabled for (i.e., subscribed to by) the user, as opposed to listing both the features/services that are enabled and disabled. With this response message format, every feature/service not listed in the profile may be treated as disabled.
- the SIP server may add the profile information to a single message, or alternatively, multiple messages being sent from the SIP server to the SIP phone.
- the profile information may be broken up and added in pieces to multiple messages being sent from the SIP server to the SIP phone.
- only a single message is described in detail as containing the profile information in the exemplary embodiments of the present application. It should be understood, however, that any number of different messages and message formats may be used to contain and convey the profile information from the SIP server to the SIP phone.
- the SIP phone After receiving the response message from the SIP server, the SIP phone implements the features/services specified in the profile contained within the response message in step 210 . Preferably, the SIP phone implements only those features/services specified in the profile. Using the above example illustrated in Table 2, if the profile information specifies that the user has subscribed to the call waiting and cancel call waiting services, but has not subscribed (or has canceled) the caller name delivery service, the SIP phone will be enabled with call waiting and cancel call waiting capabilities, but not call name delivery.
- the SIP phone may enable only those features/services indicated in the profile as being subscribed to by the user, and may disable all other features/services not indicated in the profile as being subscribed to by the user (regardless of whether such features/services are indicated in the profile as disabled or canceled by the user).
- the SIP phone then proceeds to communicate with other SIP phones based on its profile, and the method 200 ends.
- the SIP server may decide to reject a registration request and any subsequent call signaling from any SIP phones that are not capable of reading messages containing profile information or that are not capable of implementing only features/services specified in the profile information.
- SIP phones that are not restricted and bound by message profile information from registering with the SIP server (and thus preventing them from communicating with other SIP phones via a service provider's network)
- service/network providers retain control over what features/services are implemented by its SIP phones.
- the SIP server may send the profile information corresponding to a user's account information in a message other than a response to a registration request.
- the SIP server may simply send an SIP phone a message that contains the profile information that controls which features/services the SIP phone may or may not implement, and the message need not be a 200 OK response message sent after a REGISTER message.
- profile information may be conveyed to an SIP phone by adding the profile information to any message sent from the SIP server to the SIP phone at any time.
- Step 302 the method 300 for controlling the features/services implemented by an end device begins with Step 302 , wherein an end device (e.g., first end device 12 ) sends a first INVITE message to another end device (e.g., second end device 20 ) via the network core device 16 .
- the network core device receives the first INVITE message from the first end device, and looks up the account information that is stored on the network core device and corresponds to the user of the first end device.
- the network core device may look up, in Step 304 , the account information that is stored on the network core device and corresponds to the user of the second end device.
- the network core device examines the account information and identifies a profile for the second end device from the account information corresponding to the user of the first end device.
- the profile includes information describing what features/services the user of the first end device has subscribed to and/or canceled, and that may need to be implemented by the second end device.
- the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the second end device (in addition to the first end device) to provide a call that is not disturbed by call waiting on either end.
- the network core device may also identify, in Step 306 , a profile for the second end device from the account information corresponding to the user of the second end device.
- the profile includes information describing what features/services the user of the second end device has subscribed to and/or canceled.
- This profile information corresponding to the user of the second end device may be combined with, or substituted for, the profile information corresponding to the user of the first end device.
- the method 300 continues with Step 308 , wherein the network core device adds the profile information for the user of the first end device to the first INVITE message, thereby forming a second INVITE message, and sends the second INVITE message with the profile information to the second end device.
- the profile information contained within the second INVITE message may also include profile information for the user of the second end device, or alternatively, may only include profile information for the user of the second end device.
- the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information.
- the second end device After receiving the second INVITE message from the network core device, the second end device implements the features/services specified in the profile contained within the second INVITE message in step 310 .
- the second end device implements only those features/services specified in the profile. More preferably, the second end device only implements those features/services that are specified in the portion of the profile which pertains to the user of the first end device for the duration of the communication between the first and second end devices.
- the second end device then proceeds to communicate with the first end device based on the profile, and the method 300 ends.
- Step 402 an SIP device (e.g., first SIP phone 32 ) sends a first INVITE message to another SIP device (e.g., the second SIP phone 40 ) via the SIP server (e.g., SIP server 36 ).
- SIP server e.g., SIP server 36
- Table 3 illustrates an exemplary format for this first INVITE message.
- INVITE sip wherever.net SIP/2.0 To: br@wherever.net From: sm@whatever.net CSeq: 1 INVITE Subject: initiating call
- the first SIP phone i.e., the caller
- the second SIP phone i.e., the callee
- the first INVITE message format shown in Table 3 is merely exemplary, and other formats may be used for the first INVITE message of the present invention.
- Step 404 the SIP server receives the first INVITE message from the first SIP phone, and looks up the account information that is stored on the SIP server and corresponds to the user of the first SIP phone.
- the SIP server may look up, in Step 304 , the account information that is stored on the SIP server and corresponds to the user of the second SIP phone.
- the SIP server examines the account information and identifies a profile for the second SIP phone from the account information corresponding to the user of the first SIP phone.
- the profile includes information describing what features/services the user of the first SIP phone has subscribed to and/or canceled, and that may need to be implemented by the second SIP phone.
- the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the second SIP phone (in addition to the first SIP phone) to provide a call that is not disturbed by call waiting on either end.
- the SIP server may also identify, in Step 406 , a profile for the second SIP phone from the account information corresponding to the user of the second SIP phone.
- the profile includes information describing what features/services the user of the second SIP phone has subscribed to and/or canceled.
- This profile information corresponding to the user of the second SIP phone may be combined with, or substituted for, the profile information corresponding to the user of the first SIP phone.
- Step 408 the SIP server adds the profile information for the user of the first SIP phone to the first INVITE message, thereby forming a second INVITE message, and sends the second INVITE message with the profile information to the second SIP phone.
- the profile information contained within the second INVITE message may also include profile information for the user of the second SIP phone, or alternatively, may only include profile information for the user of the second SIP phone.
- the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information.
- Table 4 illustrates an exemplary format for this second INVITE message containing the profile information.
- the profile is contained within the “X-multimedia-service-enabled” field, with enabled or subscribed features/services being indicated with a “yes” and disabled or canceled features/services being indicated with a “no.”
- call waiting CW
- cancel call waiting CCW
- caller number delivery CND
- the second INVITE message format shown in Table 4 is merely exemplary, and other formats may be used for the second INVITE message of the present invention.
- the second SIP phone After receiving the second INVITE message from the SIP server, the second SIP phone implements the features/services specified in the profile contained within the second INVITE message in step 410 .
- the second SIP phone implements only those features/services specified in the profile. More preferably, the second SIP phone only implements those features/services that are specified in the portion of the profile which pertains to the user of the first SIP phone for the duration of the communication between the first and second SIP phones.
- the second SIP phone then proceeds to communicate with the first SIP phone based on the profile, and the method 400 ends.
- Step 502 the method 500 for controlling the features/services implemented by an end device begins with Step 502 , wherein an end device (e.g., first end device 12 ) sends an INVITE message to another end device (e.g., second end device 20 ) via the network core device 16 .
- the second end device sends a response message to the first end device via the network core device.
- the network core device intercepts the response message sent from the second device, and looks up the account information that is stored on the network core device and corresponds to the user of the second end device.
- the network core device may look up, in Step 506 , the account information that is stored on the network core device and corresponds to the user of the first end device.
- the network core device examines the account information and identifies a profile for the first end device from the account information corresponding to the user of the second end device.
- the profile includes information describing what features/services the user of the second end device has subscribed to and/or canceled, and that may need to be implemented by the first end device.
- the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the first end device (in addition to the second end device) to provide a call that is not disturbed by call waiting on either end.
- the network core device may also examine the account information and identify, in Step 508 , a profile for the first end device from the account information corresponding to the user of the first end device.
- the profile includes information describing what features/services the user of the first end device has subscribed to and/or canceled.
- This profile information corresponding to the user of the first end device may be combined with, or substituted for, the profile information corresponding to the user of the second end device.
- the method 500 continues with Step 510 , wherein the network core device adds the profile information for the user of the second end device to the response message, and sends the response message with the profile information to the first end device.
- the profile information contained within the response message may also include profile information for the user of the first end device, or alternatively, may only include profile information for the user of the first end device.
- the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information.
- the first end device After receiving the response message from the network core device, the first end device implements the features/services specified in the profile contained within the response message in step 512 . Preferably, the first end device implements only those features/services specified in the profile. More preferably, the first end device only implements those features/services that are specified in the portion of the profile which pertains to the user of the second end device for the duration of the communication between the first and second end devices. Referring back to FIG. 7 , the first end device then proceeds to communicate with the second end device based on the profile, and the method 500 ends.
- Step 602 the method 600 for controlling the features/services implemented by an SIP device begins with Step 602 , wherein an SIP device (e.g., first SIP phone 32 ) sends a INVITE message to another SIP device (e.g., the second SIP phone 40 ) via the SIP server (e.g., SIP server 36 ).
- SIP server e.g., SIP server 36
- Table 5 illustrates an exemplary format for this INVITE message.
- the first SIP phone i.e., the caller
- the second SIP phone i.e., the callee
- the INVITE message format shown in Table 5 is merely exemplary, and other formats may be used for the INVITE message of the present invention.
- Step 604 after receiving the INVITE message, the second SIP phone sends a response message to the first SIP phone via the SIP server.
- the SIP server intercepts the response message sent from the second SIP phone, and looks up the account information that is stored on the SIP server and corresponds to the user of the second SIP phone.
- the SIP server may look up, in Step 606 , the account information that is stored on the SIP server and corresponds to the user of the first SIP phone.
- the SIP server examines the account information and identifies a profile for the first SIP phone from the account information corresponding to the user of the second SIP phone.
- the profile includes information describing what features/services the user of the second SIP phone has subscribed to and/or canceled, and that may need to be implemented by the first SIP phone.
- the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the first SIP phone (in addition to the second SIP phone) to provide a call that is not disturbed by call waiting on either end.
- the SIP server may also examine the account information and identify, in Step 608 , a profile for the first SIP phone from the account information corresponding to the user of the first SIP phone.
- the profile includes information describing what features/services the user of the first SIP phone has subscribed to and/or canceled.
- This profile information corresponding to the user of the first SIP phone may be combined with, or substituted for, the profile information corresponding to the user of the second SIP phone.
- the method 600 continues with Step 610 , wherein the SIP server adds the profile information for the user of the second SIP phone to the response message, and sends the response message with the profile information to the first SIP phone.
- the profile information contained within the response message may also include profile information for the user of the first SIP phone, or alternatively, may only include profile information for the user of the first SIP phone.
- the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information.
- Table 6 illustrates an exemplary format for this response message containing the profile information.
- the profile is contained within the “X-multimedia-service-enabled” field, with enabled or subscribed features/services being indicated with a “yes” and disabled or canceled features/services being indicated with a “no.”
- call waiting CW
- cancel call waiting CCW
- caller number delivery CND
- the response message format shown in Table 6 is merely exemplary, and other formats may be used for the response message of the present invention.
- the first SIP phone After receiving the response message from the SIP server, the first SIP phone implements the features/services specified in the profile contained within the response message in step 612 .
- the first SIP phone implements only those features/services specified in the profile. More preferably, the first SIP phone only implements those features/services that are specified in the portion of the profile which pertains to the user of the second SIP phone for the duration of the communication between the first and second SIP phones.
- the first SIP phone then proceeds to communicate with the second SIP phone based on the profile, and the method 600 ends.
- the exemplary systems and methods of the present invention provide many advantages that are readily apparent from the above detailed description. For example, these systems and methods allow a service/network provider to centrally control the implementation of features and services by a user irrespective of the capabilities of his or her end device/phone. As a result, with the present invention, the service/network provider is able to preserve a revenue stream for its value added features/services, even though an end device may be otherwise capable of performing such features/services on its own. Since only a simple modification of a message's packet header is necessary, the systems and methods of the present invention also provide the further advantage of being fully integrated into existing communication protocols and infrastructure.
- the present invention when sending profile information in an invite or invite response message, has the further advantage of being able to send profile information corresponding to the user of a first end device/phone (or profile information corresponding to the users of both the first end device/phone and a second end device/phone) to the second end device/phone for implementation.
- any communication message e.g., any SIP message
- a network core device e.g., an SIP server
- adding a user's profile information may be added to the header of the message or messages (as illustrated above with respect to the register, invite, and response messages).
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
- The present application relates to an architecture and method for controlling multimedia features and supplementary services in packet-based networks. In particular, the present application relates to an architecture and method for controlling the multimedia features and supplementary services, such as call waiting, call forwarding, and caller identification (ID), that are implemented within Internet Protocol (IP)-based telephony technology, such as a packet-based network using Session Initiation Protocol (SEP) for its communications.
- Changes in the telecommunications market since the 1996 Telecommunications Act passed have pushed carriers far beyond their original core business of providing basic connectivity. Technological advancements and customer demands have compelled telephone companies and Internet service providers to provide communication “solutions” rather than just a dial tone. As such, service providers are always on the lookout for that next “killer” suite or creative service that will increase customer loyalty and create new revenue streams.
- But carriers are faced with a problem. Today's legacy public switched telephone network (PSTN), while reliable and robust, is built on hardware-based circuit switches that leave little room for innovation and service differentiation. Many carriers are solving this problem by migrating networks to IP-based technology, but they may still have huge investments in the PSTN hardware that are not fully depreciated. This means that as network migration continues, a hybrid PSTN/IP environment will emerge, with traffic being directed across both the PSTN and IP systems.
- One issue that will need to be addressed in both the IP and hybrid PSTN/IP telephony environments is how customers will be provided with multimedia features and supplementary services, such as call waiting, call forwarding, caller ID, call transfer, call conferencing, call hold, speed calling, and the like. In the traditional PSTN environment, service providers (i.e., the carriers) rely on network-centric devices to provide such multimedia features and supplementary services to the users. Customers can obtain these services by either subscribing or paying per usage. Because it is the network-centric devices, not the end device (e.g., the phone in the customer premises), that provide these features and services, service providers can easily control whether they should be provided per user basis based on the subscription status. This capability of screening the service delivery makes the service charging possible.
- When IP-based telephony technology, such as SIP, emerges, many end devices may be able to provide the multimedia features and supplementary services without permission from the network-centric devices of the service providers. As a result, the capability of controlling the feature/service delivery from these network-centric devices may also be deteriorated. Under this scenario, service providers will likely be able to only enable uniform multimedia features and supplementary services for all of its customer's end devices or rely on static provisioning for each such end device to enable/disable certain unwanted features/services.
- Uniform feature delivery is neither desirable to service providers nor flexible to the customers. For example, in the Centrex environment, the customer (e.g., business user) may not want those Centrex phones dedicated to guest usage to have the same sets of capability as those used by its employees. On the other hand, static provisioning of each phone separately requires high management and maintenance efforts, and also does not meet the requirement of delivering the features on a per user account basis (i.e., such provisioning is delivered on a per end device basis).
- Accordingly, service providers want a mechanism of better controlling the multimedia features and supplementary services delivery from the network core, even though these multimedia features and supplementary services are actually provided by the end devices that reside in the end user premises. The present invention defines an architecture and mechanism for network core devices (e.g., SIP servers) to control end devices (e.g., SIP phones) to deliver the multimedia features and supplementary services dynamically and based on per user account profiles. With the architecture and mechanism of the present invention, service providers can selectively provide these services to proper groups of users by indicating such feature/service information in the communication packets (e.g., SIP messages). The end devices used with the present invention will also provide multimedia features and supplementary services only as directed in such communication packets. Consequently, service providers will regain network-concentric control over the multimedia features and supplementary services that they provide in an IP or hybrid PSTN/IP telephony system.
- The present application provides a method for controlling features and services in packet-based networks comprising the step of identifying a profile, specifying which features and services may or may not be implemented by an end device, from user account information stored on a network core device. The method also comprises the steps of adding the profile to at least one message, and sending the at least one message from the network core device to the end device.
- Moreover, the present application provides another method for controlling features and services in packet-based networks that comprises the steps of sending a first message to a network core device, and identifying a profile, specifying which features and services may or may not be implemented by an end device, from user account information stored on the network core device. The method further comprises the steps of adding the profile to a second message, and sending the second message from the network core device to the end device.
- The present application also provides yet another method for controlling features and services in packet-based networks using the session initiation protocol that comprises the steps of sending a first message to a session initiation protocol server, and identifying a profile, specifying which features and services may or may not be implemented by a session initiation protocol phone, from user account information stored on the session initiation protocol server. The method further comprises the steps of adding the profile to a second message, and sending the second message from the session initiation protocol server to the session initiation protocol phone.
- In addition, the present application provides a system for controlling features and services in packet-based networks communications. The system comprises an end device in communication with a network core device, and a profile identified from user account information stored on the network core device. The profile specifies which features and services may or may not be implemented by the end device. The system further comprises at least one message including the profile, wherein the at least one message is sent from the network core device to the end device, and the end device implements only the features and services allowed to be implemented by the profile of the at least one message.
- Furthermore, the present application provides another system for controlling features and services in packet-based networks communications. The system comprises a first end device in communication with a network core device, and a second end device in communication with the network core device. The second end device is also in communication with the first end device via the network core device. The system also comprises a profile identified from user account information stored on the network core device, with the profile specifying which features and services may or may not be implemented by an end device. The system further comprises a first message and a second message, with the second message including the profile. In this system of the present application, the first message is sent from an end device to the network core device, the second message is sent from the network core device to an end device, and the end device receiving the second message implements only the features and services allowed to be implemented by the profile of the second message.
- FIG. 1 is a block diagram illustrating an exemplary system and method of the present invention for controlling features and services used by packet-based network devices.
- FIG. 2 is a block diagram illustrating an exemplary system and method of the present invention for controlling features and services used by SIP devices.
- FIG. 3 is a flow diagram illustrating control via a register message of features and services used by an end device.
- FIG. 4 is a flow diagram illustrating control via a register message of features and services used by an SIP phone.
- FIG. 5 is a flow diagram illustrating control via an invite message of features and services used by an end device.
- FIG. 6 is a flow diagram illustrating control via an invite message of features and services used by an SIP phone.
- FIG. 7 is a flow diagram illustrating control via a response message of features and services used by an end device.
- FIG. 8 is a flow diagram illustrating control via a response message of features and services used by an SIP phone.
- FIG. 1 shows an exemplary embodiment of a
system 10 and method for controlling multimedia features and supplementary services used by packet-based network devices. Thesystem 10 comprises afirst end device 12, afirst network 14, anetwork core device 16, asecond network 18, and asecond end device 20. As shown in FIG. 1, the first andsecond end devices second networks second networks network core device 16. As a result, thenetwork core device 16 bridges communications between the first andsecond end devices second networks 14, 18). It should be understood, however, that although a first and a second network are shown in FIG. 1 and described herein, the first andsecond networks second end devices - In the
system 10, the first andsecond end devices second networks - The
network core device 16 is also preferably a centrally located and controlled server device, such as an SIP server, that is located on the service provider's premises and controlled by the service provider. Preferably, thenetwork core device 16 contains account information for each of the end users or customers subscribing to the service provided by the service provider. The account information may include such information as the customer's billing address, an identification of the customer's devices, and a list of the features and services to which the customer has subscribed. - FIG. 2 illustrates an
exemplary system 30 and method implementation of thesystem 10 and method of FIG. 1 using SIP. As shown in FIG. 2, thesystem 30 comprises afirst SIP phone 32, a first packet basednetwork 34, anSIP server 36, a second packet basednetwork 38, and asecond SIP phone 40. The first andsecond SIP phones second end devices - The first and second packet based
networks second networks SIP server 36 corresponds to thenetwork core device 16. In thesystem 30, the SIP phones, the packet based networks, and the SIP server are all in the same communication as their corresponding devices and networks in thesystem 10. As with thesystem 10 of FIG. 1, it should also be understood that although a first and a second packet based network are shown in FIG. 2 and described herein, the first and second packet basednetworks second SIP phones - The
systems - Once the profile for the user has been identified, the network core device/server adds the profile to the header of a response message or to the header of the original message (thereby creating a new message consisting of the original message plus the profile information). Alternatively, the network core device/server may add the profile to the header of any other message that is being sent from the network core device/server to an end device, regardless and/or independent of any previous message being sent from an end device. Any number of different formats may be used to add the profile information to the message header, depending on what communication protocol is being used by the end devices/phones and the network core device/server. As one example, if SIP is used as the communication protocol, then the profile information may be added to the message header by inserting “X-multimedia-service-enabled:” into the header, followed by a list of the features and services that are subscribed to (e.g., “yes”) and/or canceled (e.g., “no”).
- It should be understood that the profile information may be added to more than one message being sent from the network core device/server to an end device. In addition, the profile information may be broken up and added in pieces to multiple messages being sent from the network core device/server to an end device. For example, some profile information may be sent from the network core device/server to an end device as part of a response message, while other profile information may be sent from the network core device/server to an end device as part of a new message that includes the original message.
- After adding the profile information to the message, the network core device/server then sends the new message back to the end device/phone that sent the original message (or the other end device/phone designated to receive the original message). Upon receiving the new message containing the profile, the end device/phone preferably implements only features and services as specified and set forth in the profile. Such implementation preferably occurs regardless of the individual capabilities of the end device/phone. As a result, control of the features and services utilized by a user or subscriber is restored to and maintained centrally by the service provider.
- FIGS.3-8 and the below description provide further details about the exemplary methods of the present invention and the operation of the
systems - As is known in the art, SIP defines a protocol for establishing, modifying and terminating sessions over packet data networks, such as IP networks. For example, SIP can be used to establish real-time data sessions and Internet telephony sessions, such as VoIP sessions. Of course, SIP can be used to establish many other types of sessions. SIP also supports name-mapping and redirection services, which allows a user to initiate a session from different locations and allows the user to be identified at the various different locations.
- SIP users, and thus their devices, are identified using SIP identifiers, which are typically telephone numbers or web host names. For example, an SIP identifier could be of the form “SIP:name@domain.com.” Of course, SIP supports other types of identifiers. An SIP user can register with a SIP server, such as by sending a registration message that identifies the user and the user's current location. Once registered with the SIP server, the SIP server can be used to facilitate establishing a session between two devices.
- For example, the SIP server can receive a request from a first device (e.g., a first SIP phone) that wants to use SIP to establish a session with a second device (e.g., a second SIP phone). The first device and/or the second device could previously have registered with the SIP server via a REGISTER message. In response to the REGSITER message from the first and/or second devices, the SIP server could send a response message called “200 OK,” wherein the “200” represents that the message is a response to a register request and the “OK” represents that the registration request has been accepted. The first device could send the SIP server a request to establish a session with the second device in the form of an SIP INVITE message. The SIP server could then forward the request directly to the second device. Alternatively, the first device could send the SIP INVITE message directly to the second device. In either scenario, the second device would send a response message (e.g., “200 OK”) to first device via the SIP server.
- SIP generally runs at the application layer of the Open Systems Interconnection (“OSI”) model. SIP messages can then be carried by protocols running at lower layers of the OSI model, but SIP is not confined to using specific lower level protocols. Consequently, SIP messages, such as an SIP REGISTER message that can be used to register a device with an SIP server, or an SIP INVITE message that can be used to establish a session, can be sent using any transport protocol. For example, SIP messages can be transmitted using the Transmission Control Protocol (“TCP”) or the Universal Datagram Protocol (“UDP”). TCP and UDP typically run at the transport layer of the OSI reference model. Of course, these protocols can be used in conjunction with protocols running at even lower levels of the Open Systems Interconnection (“OSI”) reference model. For example, UDP or TCP could be used in conjunction with IP, which typically runs at the network layer of the OSI reference model.
- SIP is described in more detail in Internet Engineering Task Force (“IETF”) Request for Comment (“RFC”) 2543, “SIP: Session Initiation Protocol,” Handley et al., March 1999, which is specifically incorporated herein by reference in its entirety.
- Turning now to FIG. 3, the
method 100 for controlling the features/services implemented by an end device begins withStep 102, wherein an end device (e.g., first end device 12) sends a REGSITER message to thenetwork core device 16. InStep 104, the network core device receives the REGISTER message from the end device, and looks up the account information that is stored on the network core device and corresponds to the user of the end device. This account information may include details regarding the user, his or her billing information, his or her end devices, and the features/services that he or she has subscribed to and/or canceled. As previously mentioned, such features/services may include call waiting, call forwarding, caller ID, call transfer, call conferencing, call hold, speed calling, and the like. - Next, in
Step 106, the network core device examines the account information and identifies a profile for the end device from the account information corresponding to the user of the end device. Preferably, the profile includes information describing what features/services the user has subscribed to and/or canceled. For example, the profile information may indicate that a user or customer has subscribed to call forwarding and caller ID, but has canceled call waiting. Alternatively, the profile may indicate only those features/services that the user has subscribed to, and by default, all other features that have not been subscribed to are treated as canceled by the user. Preferably, but not necessarily, the profile information is the same for every end device identified in the user's account information as being associated with the user. In other words, a single profile of subscribed/canceled features and services may be used for each of a user's end devices. - As shown in FIG. 3, the
method 100 continues withStep 108, wherein the network core device registers the end device, and sends a response message to the end device indicating such registration and containing the profile information for the user of the end device. The network core device may add the profile information to a single message, or alternatively, multiple messages being sent from the network core device to the end device. In addition, the profile information may be broken up and added in pieces to multiple messages being sent from the network core device to the end device. For ease of reference and illustration purposes, only a single message is described in detail as containing the profile information in the exemplary embodiments of the present application. It should be understood, however, that any number of different messages and message formats may be used to contain and convey the profile information from the network core device to the end device. - After receiving the response message from the network core device, the end device implements the features/services specified in the profile contained within the response message in
step 110. Preferably, the end device implements only those features/services specified in the profile. For example, if the profile information specifies that the user has subscribed to call forwarding and caller ID, but has canceled call waiting, the end device will be enabled with call forwarding and caller ID capabilities, but not call waiting. In addition, or alternatively, the end device may enable only those features/services indicated in the profile as being subscribed to by the user, and may disable all other features/services not indicated in the profile as being subscribed to by the user (regardless of whether such features/services are indicated in the profile as canceled by the user). The end device then proceeds to communicate with other end devices based on its profile, and themethod 100 ends. - Although not shown, it should be understood that the network core device may decide to reject a registration request and any subsequent call signaling from any end devices that are not capable of reading messages containing profile information or that are not capable of implementing only features/services specified in the profile information. By preventing end devices that are not restricted and bound by message profile information from registering with the network core deyice (and thus preventing them from communicating with other end devices via a service provider's network), service/network providers retain control over what features/services are implemented by its end devices.
- It should also be understood that the network core device may send the profile information corresponding to a user's account information in a message other than a response to a registration request. In other words, the network core device may simply send an end device a message that contains the profile information that controls which features/services the end device may or may not implement, and the message need not be a response message sent after a register message. Indeed, profile information may be conveyed to an end device by adding the profile information to any message (or messages) sent from the network core device to the end device at any time.
- Turning now to FIG. 4, the
method 200 for controlling the features/services implemented by an SIP device begins withStep 202, wherein an SIP device (e.g., first SIP phone 32) sends a REGSITER message to the SIP server (e.g., SIP server 36). Table 1 illustrates an exemplary format for this REGISTER message.TABLE 1 REGISTER sip:whatever.net SIP/2.0 To: sm@whatever.net From: sm@whatever.net CSeq: 1 REGISTER Contact: sip:sm@149.112.90.46 Expires: 3600 - As shown in Table 1, the SIP phone is identified by its e-mail address, which in this example is sm@whatever.net. It should be understood that the REGSITER message format shown in Table 1 is merely exemplary, and other formats may be used for the REGISTER message of the present invention.
- In
Step 204, the SIP server receives the REGISTER message from the SIP phone, and looks up the account information that is stored on the SIP server (or another server or storage device in communication with the SIP server) and corresponds to the user of the SIP phone. This account information may include details regarding the user, his or her billing information, his or her end devices, and the features/services that he or she has subscribed to and/or canceled. As previously mentioned, such features/services may include call waiting, call forwarding, caller ID, call transfer, call conferencing, call hold, speed calling, and the like. - Next, in
Step 206, the SIP server examines the account information and identifies a profile for the SIP phone from the account information corresponding to the user of the SIP phone. Preferably, the profile includes information describing what features/services the user has subscribed to and/or canceled. For example, the profile information may indicate that a user or customer has subscribed to call forwarding and caller ID, but has canceled call waiting. Alternatively, the profile may indicate only those features/services that the user has subscribed to, and by default, all other features that have not been subscribed to are treated as canceled by the user. Preferably, but not necessarily, the profile information is the same for every SIP phone identified in the user's account information as being associated with the user. In other words, a single profile of subscribed/canceled features and services may be used for each of a user's SIP phones. - As shown in FIG. 4, the
method 200 continues withStep 208, wherein the SIP server registers the SIP phone, and sends a response message to the SIP phone indicating such registration and containing the profile information for the user of the SIP phone. Preferably, the response message is a 200 OK response message containing a header line setting forth the identified profile for the user. Table 2 illustrates an exemplary format for this 200 OK response message.TABLE 2 SIP/2.0 200 OK To: sm@whatever.net From: sm@whatever.net CSeq: 1 REGISTER Contact: sip:sm@149.112.90.46 X-multimedia-service-enabled: CW=yes, CCW=yes, CND=no Expires: 3600 - As shown in Table 2, the profile is contained within the “X-multimedia-service-enabled” field, with enabled or subscribed features/services being indicated with a “yes” and disabled or canceled features/services being indicated with a “no.” In this example, call waiting (CW) is enabled, cancel call waiting (CCW) is enabled, and caller number delivery (CND) is disabled (i.e., not subscribed to by the user).
- It should be understood that the 200 OK response message format shown in Table 2 is merely exemplary, and other formats may be used for the response message of the present invention. As one example, the profile line following the “X-multimedia-service-enabled” field may simply list only the features/services that are enabled for (i.e., subscribed to by) the user, as opposed to listing both the features/services that are enabled and disabled. With this response message format, every feature/service not listed in the profile may be treated as disabled.
- It should also be understood that the SIP server may add the profile information to a single message, or alternatively, multiple messages being sent from the SIP server to the SIP phone. In addition, the profile information may be broken up and added in pieces to multiple messages being sent from the SIP server to the SIP phone. For ease of reference and illustration purposes, only a single message is described in detail as containing the profile information in the exemplary embodiments of the present application. It should be understood, however, that any number of different messages and message formats may be used to contain and convey the profile information from the SIP server to the SIP phone.
- After receiving the response message from the SIP server, the SIP phone implements the features/services specified in the profile contained within the response message in
step 210. Preferably, the SIP phone implements only those features/services specified in the profile. Using the above example illustrated in Table 2, if the profile information specifies that the user has subscribed to the call waiting and cancel call waiting services, but has not subscribed (or has canceled) the caller name delivery service, the SIP phone will be enabled with call waiting and cancel call waiting capabilities, but not call name delivery. In addition, or alternatively, the SIP phone may enable only those features/services indicated in the profile as being subscribed to by the user, and may disable all other features/services not indicated in the profile as being subscribed to by the user (regardless of whether such features/services are indicated in the profile as disabled or canceled by the user). The SIP phone then proceeds to communicate with other SIP phones based on its profile, and themethod 200 ends. - Although not shown, it should be understood that the SIP server may decide to reject a registration request and any subsequent call signaling from any SIP phones that are not capable of reading messages containing profile information or that are not capable of implementing only features/services specified in the profile information. By preventing SIP phones that are not restricted and bound by message profile information from registering with the SIP server (and thus preventing them from communicating with other SIP phones via a service provider's network), service/network providers retain control over what features/services are implemented by its SIP phones.
- It should also be understood that the SIP server may send the profile information corresponding to a user's account information in a message other than a response to a registration request. In other words, the SIP server may simply send an SIP phone a message that contains the profile information that controls which features/services the SIP phone may or may not implement, and the message need not be a 200 OK response message sent after a REGISTER message. Indeed, profile information may be conveyed to an SIP phone by adding the profile information to any message sent from the SIP server to the SIP phone at any time.
- Turning now to FIG. 5, the
method 300 for controlling the features/services implemented by an end device begins withStep 302, wherein an end device (e.g., first end device 12) sends a first INVITE message to another end device (e.g., second end device 20) via thenetwork core device 16. InStep 304, the network core device receives the first INVITE message from the first end device, and looks up the account information that is stored on the network core device and corresponds to the user of the first end device. In addition, or alternatively, the network core device may look up, inStep 304, the account information that is stored on the network core device and corresponds to the user of the second end device. - Next, in
Step 306, the network core device examines the account information and identifies a profile for the second end device from the account information corresponding to the user of the first end device. Preferably, the profile includes information describing what features/services the user of the first end device has subscribed to and/or canceled, and that may need to be implemented by the second end device. For example, the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the second end device (in addition to the first end device) to provide a call that is not disturbed by call waiting on either end. - The network core device may also identify, in
Step 306, a profile for the second end device from the account information corresponding to the user of the second end device. Preferably, the profile includes information describing what features/services the user of the second end device has subscribed to and/or canceled. This profile information corresponding to the user of the second end device may be combined with, or substituted for, the profile information corresponding to the user of the first end device. - As shown in FIG. 5, the
method 300 continues withStep 308, wherein the network core device adds the profile information for the user of the first end device to the first INVITE message, thereby forming a second INVITE message, and sends the second INVITE message with the profile information to the second end device. As mentioned above, the profile information contained within the second INVITE message may also include profile information for the user of the second end device, or alternatively, may only include profile information for the user of the second end device. As also mentioned above, the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information. - After receiving the second INVITE message from the network core device, the second end device implements the features/services specified in the profile contained within the second INVITE message in
step 310. Preferably, the second end device implements only those features/services specified in the profile. More preferably, the second end device only implements those features/services that are specified in the portion of the profile which pertains to the user of the first end device for the duration of the communication between the first and second end devices. Referring back to FIG. 5, the second end device then proceeds to communicate with the first end device based on the profile, and themethod 300 ends. - Turning now to FIG. 6, the
method 400 for controlling the features/services implemented by an SIP device begins withStep 402, wherein an SIP device (e.g., first SIP phone 32) sends a first INVITE message to another SIP device (e.g., the second SIP phone 40) via the SIP server (e.g., SIP server 36). Table 3 illustrates an exemplary format for this first INVITE message.TABLE 3 INVITE sip:wherever.net SIP/2.0 To: br@wherever.net From: sm@whatever.net CSeq: 1 INVITE Subject: initiating call - As shown in Table 3, the first SIP phone (i.e., the caller) is identified by its e-mail address, which in this example is sm@whatever.net, and the second SIP phone (i.e., the callee) is identified by its e-mail address, which in this example is br@wherever.net. It should be understood that the first INVITE message format shown in Table 3 is merely exemplary, and other formats may be used for the first INVITE message of the present invention.
- In
Step 404, the SIP server receives the first INVITE message from the first SIP phone, and looks up the account information that is stored on the SIP server and corresponds to the user of the first SIP phone. In addition, or alternatively, the SIP server may look up, inStep 304, the account information that is stored on the SIP server and corresponds to the user of the second SIP phone. - Next, in
Step 406, the SIP server examines the account information and identifies a profile for the second SIP phone from the account information corresponding to the user of the first SIP phone. Preferably, the profile includes information describing what features/services the user of the first SIP phone has subscribed to and/or canceled, and that may need to be implemented by the second SIP phone. For example, the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the second SIP phone (in addition to the first SIP phone) to provide a call that is not disturbed by call waiting on either end. - The SIP server may also identify, in
Step 406, a profile for the second SIP phone from the account information corresponding to the user of the second SIP phone. Preferably, the profile includes information describing what features/services the user of the second SIP phone has subscribed to and/or canceled. This profile information corresponding to the user of the second SIP phone may be combined with, or substituted for, the profile information corresponding to the user of the first SIP phone. - As shown in FIG. 6, the
method 400 continues withStep 408, wherein the SIP server adds the profile information for the user of the first SIP phone to the first INVITE message, thereby forming a second INVITE message, and sends the second INVITE message with the profile information to the second SIP phone. As mentioned above, the profile information contained within the second INVITE message may also include profile information for the user of the second SIP phone, or alternatively, may only include profile information for the user of the second SIP phone. As also mentioned above, the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information. - Table 4 illustrates an exemplary format for this second INVITE message containing the profile information.
TABLE 4 INVITE sip:wherever.net SIP/2.0 To: br@wherever.net From: sm@whatever.net CSeq: 1 INVITE Subject: initiating call X-multimedia-service-enabled: CW=yes, CCW=yes, CND=no - As shown in Table 4, the profile is contained within the “X-multimedia-service-enabled” field, with enabled or subscribed features/services being indicated with a “yes” and disabled or canceled features/services being indicated with a “no.” In this example, call waiting (CW) is enabled, cancel call waiting (CCW) is enabled, and caller number delivery (CND) is disabled (i.e., not subscribed to by the user). Again, it should be understood that the second INVITE message format shown in Table 4 is merely exemplary, and other formats may be used for the second INVITE message of the present invention.
- After receiving the second INVITE message from the SIP server, the second SIP phone implements the features/services specified in the profile contained within the second INVITE message in
step 410. Preferably, the second SIP phone implements only those features/services specified in the profile. More preferably, the second SIP phone only implements those features/services that are specified in the portion of the profile which pertains to the user of the first SIP phone for the duration of the communication between the first and second SIP phones. Referring back to FIG. 6, the second SIP phone then proceeds to communicate with the first SIP phone based on the profile, and themethod 400 ends. - Turning now to FIG. 7, the
method 500 for controlling the features/services implemented by an end device begins withStep 502, wherein an end device (e.g., first end device 12) sends an INVITE message to another end device (e.g., second end device 20) via thenetwork core device 16. In Step 504, after receiving the INVITE message, the second end device sends a response message to the first end device via the network core device. InStep 506, the network core device intercepts the response message sent from the second device, and looks up the account information that is stored on the network core device and corresponds to the user of the second end device. In addition, or alternatively, the network core device may look up, inStep 506, the account information that is stored on the network core device and corresponds to the user of the first end device. - Next, in
Step 508, the network core device examines the account information and identifies a profile for the first end device from the account information corresponding to the user of the second end device. Preferably, the profile includes information describing what features/services the user of the second end device has subscribed to and/or canceled, and that may need to be implemented by the first end device. For example, the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the first end device (in addition to the second end device) to provide a call that is not disturbed by call waiting on either end. - The network core device may also examine the account information and identify, in
Step 508, a profile for the first end device from the account information corresponding to the user of the first end device. Preferably, the profile includes information describing what features/services the user of the first end device has subscribed to and/or canceled. This profile information corresponding to the user of the first end device may be combined with, or substituted for, the profile information corresponding to the user of the second end device. - As shown in FIG. 7, the
method 500 continues withStep 510, wherein the network core device adds the profile information for the user of the second end device to the response message, and sends the response message with the profile information to the first end device. As mentioned above, the profile information contained within the response message may also include profile information for the user of the first end device, or alternatively, may only include profile information for the user of the first end device. As also mentioned above, the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information. - After receiving the response message from the network core device, the first end device implements the features/services specified in the profile contained within the response message in
step 512. Preferably, the first end device implements only those features/services specified in the profile. More preferably, the first end device only implements those features/services that are specified in the portion of the profile which pertains to the user of the second end device for the duration of the communication between the first and second end devices. Referring back to FIG. 7, the first end device then proceeds to communicate with the second end device based on the profile, and themethod 500 ends. - Turning now to FIG. 8, the
method 600 for controlling the features/services implemented by an SIP device begins withStep 602, wherein an SIP device (e.g., first SIP phone 32) sends a INVITE message to another SIP device (e.g., the second SIP phone 40) via the SIP server (e.g., SIP server 36). Table 5 illustrates an exemplary format for this INVITE message.TABLE 5 INVITE sip:wherever.net SIP/2.0 To: br@wherever.net From: sm@whatever.net CSeq: 1 INVITE Subject: initiating call - As shown in Table 5, the first SIP phone (i.e., the caller) is identified by its e-mail address, which in this example is sm@whatever.net, and the second SIP phone (i.e., the callee) is identified by its e-mail address, which in this example is br@wherever.net. It should be understood that the INVITE message format shown in Table 5 is merely exemplary, and other formats may be used for the INVITE message of the present invention.
- In
Step 604, after receiving the INVITE message, the second SIP phone sends a response message to the first SIP phone via the SIP server. InStep 606, the SIP server intercepts the response message sent from the second SIP phone, and looks up the account information that is stored on the SIP server and corresponds to the user of the second SIP phone. In addition, or alternatively, the SIP server may look up, inStep 606, the account information that is stored on the SIP server and corresponds to the user of the first SIP phone. - Next, in
Step 608, the SIP server examines the account information and identifies a profile for the first SIP phone from the account information corresponding to the user of the second SIP phone. Preferably, the profile includes information describing what features/services the user of the second SIP phone has subscribed to and/or canceled, and that may need to be implemented by the first SIP phone. For example, the profile information may indicate that a user or customer has subscribed to cancel call waiting, which may be implemented by the first SIP phone (in addition to the second SIP phone) to provide a call that is not disturbed by call waiting on either end. - The SIP server may also examine the account information and identify, in
Step 608, a profile for the first SIP phone from the account information corresponding to the user of the first SIP phone. Preferably, the profile includes information describing what features/services the user of the first SIP phone has subscribed to and/or canceled. This profile information corresponding to the user of the first SIP phone may be combined with, or substituted for, the profile information corresponding to the user of the second SIP phone. - As shown in FIG. 8, the
method 600 continues withStep 610, wherein the SIP server adds the profile information for the user of the second SIP phone to the response message, and sends the response message with the profile information to the first SIP phone. As mentioned above, the profile information contained within the response message may also include profile information for the user of the first SIP phone, or alternatively, may only include profile information for the user of the first SIP phone. As also mentioned above, the profile information may be added to a single message, a plurality of messages with each message including all of the profile information, or a plurality of messages with each message including only a portion (preferably a different portion) of the profile information. - Table 6 illustrates an exemplary format for this response message containing the profile information.
TABLE 6 SIP/2.0 200 OK To: sm@wherever.net From: br@whatever.net CSeq: 1 INVITE X-multimedia-service-enabled: CW=yes, CCW=yes, CND=no - As shown in Table 6, the profile is contained within the “X-multimedia-service-enabled” field, with enabled or subscribed features/services being indicated with a “yes” and disabled or canceled features/services being indicated with a “no.” In this example, call waiting (CW) is enabled, cancel call waiting (CCW) is enabled, and caller number delivery (CND) is disabled (i.e., not subscribed to by the user). Again, it should be understood that the response message format shown in Table 6 is merely exemplary, and other formats may be used for the response message of the present invention.
- After receiving the response message from the SIP server, the first SIP phone implements the features/services specified in the profile contained within the response message in
step 612. Preferably, the first SIP phone implements only those features/services specified in the profile. More preferably, the first SIP phone only implements those features/services that are specified in the portion of the profile which pertains to the user of the second SIP phone for the duration of the communication between the first and second SIP phones. Referring back to FIG. 8, the first SIP phone then proceeds to communicate with the second SIP phone based on the profile, and themethod 600 ends. - The exemplary systems and methods of the present invention provide many advantages that are readily apparent from the above detailed description. For example, these systems and methods allow a service/network provider to centrally control the implementation of features and services by a user irrespective of the capabilities of his or her end device/phone. As a result, with the present invention, the service/network provider is able to preserve a revenue stream for its value added features/services, even though an end device may be otherwise capable of performing such features/services on its own. Since only a simple modification of a message's packet header is necessary, the systems and methods of the present invention also provide the further advantage of being fully integrated into existing communication protocols and infrastructure.
- In addition, when register response messages are used to pass along the user's feature/service profile from the network core device/server to the end device/phone, control of the user's features/services is established at the beginning on registration, and communication between two end devices/phones can therefore proceed directly between the two without going through the network core device/server. On the other hand, if such profile information is not passed along to the end device/phone during the registration process, the profile may still be sent to the end device/phone in an invite message, or alternatively, in a response to an invite message. Also, when sending profile information in an invite or invite response message, the present invention has the further advantage of being able to send profile information corresponding to the user of a first end device/phone (or profile information corresponding to the users of both the first end device/phone and a second end device/phone) to the second end device/phone for implementation.
- In view of the wide variety of embodiments to which the principles of the present invention can be applied, it should be understood that the illustrated embodiments are exemplary only, and should not be taken as limiting the scope of the present invention. For example, the steps of the flow diagrams may be taken in sequences other than those described, and more or fewer steps and/or elements may be used in the flow/block diagrams. While various elements of the exemplary embodiments described herein may be implemented in software, hardware or firmware implementations may alternatively be used in other embodiments, and vice-versa.
- In addition, although only registration and invite messages, as well as their respective response messages, are specifically discussed herein, the systems and methods of the present invention may be applied to, and work equally well with, other types of messages, such as an SIP NOTIFY message. Indeed, any communication message (e.g., any SIP message) or group of messages sent from a network core device (e.g., an SIP server) may be used with the systems and methods of the present invention by adding a user's profile information to the header of the message or messages (as illustrated above with respect to the register, invite, and response messages).
- The claims should not be read as limited to the described order or elements unless stated to that effect. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention.
Claims (35)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/243,642 US7463620B2 (en) | 2002-09-10 | 2002-09-10 | Architecture and method for controlling features and services in packet-based networks |
PCT/US2003/028490 WO2004025915A1 (en) | 2002-09-10 | 2003-09-10 | Controlling features and services in packet network |
AU2003270543A AU2003270543A1 (en) | 2002-09-10 | 2003-09-10 | Controlling features and services in packet network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/243,642 US7463620B2 (en) | 2002-09-10 | 2002-09-10 | Architecture and method for controlling features and services in packet-based networks |
Publications (2)
Publication Number | Publication Date |
---|---|
US20040047339A1 true US20040047339A1 (en) | 2004-03-11 |
US7463620B2 US7463620B2 (en) | 2008-12-09 |
Family
ID=31991703
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/243,642 Active 2025-11-28 US7463620B2 (en) | 2002-09-10 | 2002-09-10 | Architecture and method for controlling features and services in packet-based networks |
Country Status (3)
Country | Link |
---|---|
US (1) | US7463620B2 (en) |
AU (1) | AU2003270543A1 (en) |
WO (1) | WO2004025915A1 (en) |
Cited By (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040057464A1 (en) * | 2002-09-23 | 2004-03-25 | Michael Sanders | Generic Transport layer |
US20050041648A1 (en) * | 2003-08-18 | 2005-02-24 | Nortel Networks Limited | Method and system for service denial and termination on a wireless network |
US20050107072A1 (en) * | 2003-11-13 | 2005-05-19 | Lucent Technologies Inc. | System and method for mult-directional message delivery for call waiting |
US20050238002A1 (en) * | 2003-02-10 | 2005-10-27 | Rasanen Juha A | Mobile network having IP multimedia subsystem (IMS) entities and solutions for providing simplification of operations and compatibility between different IMS entities |
US20050281274A1 (en) * | 2004-06-16 | 2005-12-22 | Nec Corporation | VoIP network, media proxy server, and method of providing additional services used in them |
US20060067308A1 (en) * | 2004-09-24 | 2006-03-30 | Seong-Kwan Cho | Providing subscriber information in voice over IP (VoIP) system |
US20060094415A1 (en) * | 2004-11-04 | 2006-05-04 | Veron Christian H | Selective disablement of mobile communication equipment capabilities |
US20060218268A1 (en) * | 2005-03-28 | 2006-09-28 | Andre Beck | Method and apparatus for extending service mediation to intelligent voice-over-IP endpoint terminals |
US20060274678A1 (en) * | 2005-06-07 | 2006-12-07 | Siemens Communications, Inc. | SIP telehpone feature control |
US20060294248A1 (en) * | 2005-06-28 | 2006-12-28 | Microsoft Corporation | Automatic server configuration based on user agent |
US20070206515A1 (en) * | 2006-03-06 | 2007-09-06 | Andreasen Flemming S | System and method for generating a unified accounting record for a communication session |
US20080043726A1 (en) * | 2006-08-21 | 2008-02-21 | Telefonaktiebolaget L M Ericsson (Publ) | Selective Control of User Equipment Capabilities |
US20080175225A1 (en) * | 2007-01-18 | 2008-07-24 | Lon-Chan Chu | Just-in-time call registration for mobile call to voip device |
WO2008127819A1 (en) | 2007-04-11 | 2008-10-23 | Cellco Partnership D/B/A Verizon Wireless | Network node for providing remote client deactivation |
US20090052442A1 (en) * | 2007-08-20 | 2009-02-26 | International Business Machines Corporation | Automatically routing session initiation protocol (sip) communications from a consumer device |
US20100195493A1 (en) * | 2009-02-02 | 2010-08-05 | Peter Hedman | Controlling a packet flow from a user equipment |
US20100266110A1 (en) * | 2009-04-15 | 2010-10-21 | Armstrong Soo | Method and apparatus for providing a customer premise based communication system |
US20120214480A1 (en) * | 2011-02-23 | 2012-08-23 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (ims) services registration status |
US20120284335A1 (en) * | 2008-03-14 | 2012-11-08 | Industrial Technology Research Institute | Methods and Systems For Associating Users Through Network Societies |
US8619636B1 (en) * | 2006-05-03 | 2013-12-31 | At&T Mobility Ii Llc | Methods and systems for creating optimized transmission paths for VoIP conference calls |
US20140079054A1 (en) * | 2005-06-29 | 2014-03-20 | Qualcomm Connected Experiences, Inc. | Caller-callee association of a plurality of networked devices |
US9351203B2 (en) | 2013-09-13 | 2016-05-24 | Microsoft Technology Licensing, Llc | Voice call continuity in hybrid networks |
US9363711B2 (en) | 2014-04-07 | 2016-06-07 | Microsoft Technology Licensing, Llc | User experiences during call handovers on a hybrid telecommunications network |
US9456333B2 (en) | 2014-07-09 | 2016-09-27 | Microsoft Technology Licensing, Llc | Centralized routing in hybrid networks |
US9479604B2 (en) | 2006-01-30 | 2016-10-25 | Qualcomm Incorporated | System and method for dynamic phone book and network content links in a mobile device |
US9510251B2 (en) | 2013-12-31 | 2016-11-29 | Microsoft Technology Licensing, Llc | Call handoff initiation in hybrid networks |
US9560185B2 (en) | 2014-03-19 | 2017-01-31 | Microsoft Technology Licensing, Llc | Hybrid telecommunications network connection indicator |
US9935787B2 (en) | 2013-12-26 | 2018-04-03 | Microsoft Technology Licensing, Llc | Tunneling VoIP call control on cellular networks |
US20180103151A1 (en) * | 2016-10-07 | 2018-04-12 | Microsoft Technology Licensing, Llc | Communication System |
US10470232B2 (en) | 2016-09-26 | 2019-11-05 | Microsoft Technology Licensing, Llc | Communication system |
US11711459B2 (en) | 2003-12-08 | 2023-07-25 | Ipventure, Inc. | Adaptable communication techniques for electronic devices |
US11800329B2 (en) * | 2003-12-08 | 2023-10-24 | Ingenioshare, Llc | Method and apparatus to manage communication |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8055778B2 (en) * | 2004-09-30 | 2011-11-08 | Siemens Enterprise Communications, Inc. | SIP user agent with simultaneous multiple registrations |
EP1847105A1 (en) * | 2005-02-01 | 2007-10-24 | Nokia Siemens Networks Gmbh & Co. Kg | Method and system to use feature profiles call-by-call in telecommunication call handling |
US8554931B1 (en) * | 2007-08-13 | 2013-10-08 | Sprint Spectrum L.P. | Method and system for coordinating network resources for blended services |
US8279848B1 (en) * | 2007-09-27 | 2012-10-02 | Sprint Communications Company L.P. | Determining characteristics of a mobile user of a network |
US8554718B2 (en) * | 2008-02-12 | 2013-10-08 | Rockstar Consortium Us Lp | Method and system for client context dissemination for web-based applications |
Citations (37)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5541986A (en) * | 1993-07-27 | 1996-07-30 | Bell Communications Research, Inc. | Method and system for automated telecommunications service script consolidation and downloading |
US5629978A (en) * | 1994-02-28 | 1997-05-13 | Us West Technologies, Inc. | Service delivery using broadband |
US5696824A (en) * | 1995-06-07 | 1997-12-09 | E-Comm Incorporated | System for detecting unauthorized account access |
US5937347A (en) * | 1996-11-06 | 1999-08-10 | Nortel Networks Corporation | Interactive subscriber telephone terminal with automatic management software download feature |
US6185288B1 (en) * | 1997-12-18 | 2001-02-06 | Nortel Networks Limited | Multimedia call signalling system and method |
US20010012777A1 (en) * | 2000-02-09 | 2001-08-09 | Yoichiro Igarashi | Mobile communications system and method thereof |
US20020004736A1 (en) * | 2000-02-14 | 2002-01-10 | Roundtree Brian C. | Assembling personal information of a target person based upon third-party |
US20020013905A1 (en) * | 2000-05-02 | 2002-01-31 | Masashi Hamada | Information processing apparatus |
US20020034166A1 (en) * | 2000-07-24 | 2002-03-21 | Barany Peter A. | Packet-based calls in a wireless network |
US6366577B1 (en) * | 1999-11-05 | 2002-04-02 | Mci Worldcom, Inc. | Method for providing IP telephony with QoS using end-to-end RSVP signaling |
US20020052754A1 (en) * | 1998-09-15 | 2002-05-02 | Joyce Simon James | Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment |
US6393120B1 (en) * | 1998-02-06 | 2002-05-21 | Telefonaktiebolaget Lm Ericsson | Arrangement in a network structure |
US6396914B1 (en) * | 1998-11-20 | 2002-05-28 | At&T Corp. | Method and system for transmitting activation codes to a communication device |
US6446127B1 (en) * | 1998-10-30 | 2002-09-03 | 3Com Corporation | System and method for providing user mobility services on a telephony network |
US20020126654A1 (en) * | 2001-03-08 | 2002-09-12 | Preston Andrew C. | Homing and controlling IP telephones |
US20020136206A1 (en) * | 2001-03-20 | 2002-09-26 | Worldcom, Inc. | Recursive query for communications network data |
US20020138563A1 (en) * | 2001-03-20 | 2002-09-26 | Trivedi Prakash A. | Systems and methods for communicating from an integration platform to a profile management server |
US20020138603A1 (en) * | 2001-03-20 | 2002-09-26 | Robohm Kurt W. | Systems and methods for updating IP communication service attributes |
US20020176404A1 (en) * | 2001-04-13 | 2002-11-28 | Girard Gregory D. | Distributed edge switching system for voice-over-packet multiservice network |
US6519242B1 (en) * | 1998-12-09 | 2003-02-11 | Nortel Networks Limited | Apparatus and method of PSTN based network roaming and SCP based subscriber management for internet telephony systems |
US6522876B1 (en) * | 1999-10-04 | 2003-02-18 | Sprint Spectrum L.P. | System for managing telecommunications services through use of customized profile management codes |
US20030050896A1 (en) * | 2001-09-12 | 2003-03-13 | Shawn Wiederin | Systems and methods for monetary transactions between wired and wireless devices |
US6584490B1 (en) * | 1998-10-30 | 2003-06-24 | 3Com Corporation | System and method for providing call-handling services on a data network telephone system |
US6622016B1 (en) * | 1999-10-04 | 2003-09-16 | Sprint Spectrum L.P. | System for controlled provisioning of telecommunications services |
US6622017B1 (en) * | 2000-02-25 | 2003-09-16 | Cellco Parntership | Over-the-air programming of wireless terminal features |
US20030177099A1 (en) * | 2002-03-12 | 2003-09-18 | Worldcom, Inc. | Policy control and billing support for call transfer in a session initiation protocol (SIP) network |
US6714987B1 (en) * | 1999-11-05 | 2004-03-30 | Nortel Networks Limited | Architecture for an IP centric distributed network |
US20040068533A1 (en) * | 2000-11-08 | 2004-04-08 | Jouko Tenhunen | Transmission of service data |
US20040073566A1 (en) * | 2001-03-20 | 2004-04-15 | Trivedi Prakash A. | Systems and methods for communicating from an integration platform to a provisioning server |
US6741695B1 (en) * | 2002-04-03 | 2004-05-25 | Sprint Spectrum, L.P. | Method and system for interfacing a legacy circuit-switched network with a packet-switched network |
US6744867B1 (en) * | 1999-09-23 | 2004-06-01 | Nortel Networks Limited | Remote control of CPE-based service logic |
US6801604B2 (en) * | 2001-06-25 | 2004-10-05 | International Business Machines Corporation | Universal IP-based and scalable architectures across conversational applications using web services for speech and audio processing resources |
US6839420B1 (en) * | 1998-01-23 | 2005-01-04 | Nokia Corporation | Method for transferring the service profile of a digital subscription to a digital terminal device |
US6856676B1 (en) * | 1998-10-15 | 2005-02-15 | Alcatel | System and method of controlling and managing voice and data services in a telecommunications network |
US20050233741A1 (en) * | 2002-03-29 | 2005-10-20 | Zamani Moussavi M | System for setting up a connection between two users of a telecommunication network |
US20060080404A1 (en) * | 2002-06-19 | 2006-04-13 | Knut Haber-Land-Schlosser | Method and device for generating a mobile homepage in accordance with context related information |
US7173925B1 (en) * | 2001-07-18 | 2007-02-06 | Cisco Technology, Inc. | Method and system of control signaling for a wireless access network |
-
2002
- 2002-09-10 US US10/243,642 patent/US7463620B2/en active Active
-
2003
- 2003-09-10 WO PCT/US2003/028490 patent/WO2004025915A1/en not_active Application Discontinuation
- 2003-09-10 AU AU2003270543A patent/AU2003270543A1/en not_active Abandoned
Patent Citations (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5541986A (en) * | 1993-07-27 | 1996-07-30 | Bell Communications Research, Inc. | Method and system for automated telecommunications service script consolidation and downloading |
US5629978A (en) * | 1994-02-28 | 1997-05-13 | Us West Technologies, Inc. | Service delivery using broadband |
US5696824A (en) * | 1995-06-07 | 1997-12-09 | E-Comm Incorporated | System for detecting unauthorized account access |
US5937347A (en) * | 1996-11-06 | 1999-08-10 | Nortel Networks Corporation | Interactive subscriber telephone terminal with automatic management software download feature |
US6157708A (en) * | 1996-11-06 | 2000-12-05 | Nortel Networks Limited | Interactive subscriber telephone terminal with automatic management software download feature |
US6185288B1 (en) * | 1997-12-18 | 2001-02-06 | Nortel Networks Limited | Multimedia call signalling system and method |
US6839420B1 (en) * | 1998-01-23 | 2005-01-04 | Nokia Corporation | Method for transferring the service profile of a digital subscription to a digital terminal device |
US6393120B1 (en) * | 1998-02-06 | 2002-05-21 | Telefonaktiebolaget Lm Ericsson | Arrangement in a network structure |
US20020052754A1 (en) * | 1998-09-15 | 2002-05-02 | Joyce Simon James | Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment |
US6856676B1 (en) * | 1998-10-15 | 2005-02-15 | Alcatel | System and method of controlling and managing voice and data services in a telecommunications network |
US6446127B1 (en) * | 1998-10-30 | 2002-09-03 | 3Com Corporation | System and method for providing user mobility services on a telephony network |
US6584490B1 (en) * | 1998-10-30 | 2003-06-24 | 3Com Corporation | System and method for providing call-handling services on a data network telephone system |
US6396914B1 (en) * | 1998-11-20 | 2002-05-28 | At&T Corp. | Method and system for transmitting activation codes to a communication device |
US6519242B1 (en) * | 1998-12-09 | 2003-02-11 | Nortel Networks Limited | Apparatus and method of PSTN based network roaming and SCP based subscriber management for internet telephony systems |
US6744867B1 (en) * | 1999-09-23 | 2004-06-01 | Nortel Networks Limited | Remote control of CPE-based service logic |
US6622016B1 (en) * | 1999-10-04 | 2003-09-16 | Sprint Spectrum L.P. | System for controlled provisioning of telecommunications services |
US6522876B1 (en) * | 1999-10-04 | 2003-02-18 | Sprint Spectrum L.P. | System for managing telecommunications services through use of customized profile management codes |
US6366577B1 (en) * | 1999-11-05 | 2002-04-02 | Mci Worldcom, Inc. | Method for providing IP telephony with QoS using end-to-end RSVP signaling |
US6714987B1 (en) * | 1999-11-05 | 2004-03-30 | Nortel Networks Limited | Architecture for an IP centric distributed network |
US20010012777A1 (en) * | 2000-02-09 | 2001-08-09 | Yoichiro Igarashi | Mobile communications system and method thereof |
US20020004736A1 (en) * | 2000-02-14 | 2002-01-10 | Roundtree Brian C. | Assembling personal information of a target person based upon third-party |
US6622017B1 (en) * | 2000-02-25 | 2003-09-16 | Cellco Parntership | Over-the-air programming of wireless terminal features |
US20020013905A1 (en) * | 2000-05-02 | 2002-01-31 | Masashi Hamada | Information processing apparatus |
US20020034166A1 (en) * | 2000-07-24 | 2002-03-21 | Barany Peter A. | Packet-based calls in a wireless network |
US20040068533A1 (en) * | 2000-11-08 | 2004-04-08 | Jouko Tenhunen | Transmission of service data |
US20020126654A1 (en) * | 2001-03-08 | 2002-09-12 | Preston Andrew C. | Homing and controlling IP telephones |
US20020138603A1 (en) * | 2001-03-20 | 2002-09-26 | Robohm Kurt W. | Systems and methods for updating IP communication service attributes |
US20020188712A1 (en) * | 2001-03-20 | 2002-12-12 | Worldcom, Inc. | Communications system with fraud monitoring |
US20040073566A1 (en) * | 2001-03-20 | 2004-04-15 | Trivedi Prakash A. | Systems and methods for communicating from an integration platform to a provisioning server |
US20020138563A1 (en) * | 2001-03-20 | 2002-09-26 | Trivedi Prakash A. | Systems and methods for communicating from an integration platform to a profile management server |
US20020136206A1 (en) * | 2001-03-20 | 2002-09-26 | Worldcom, Inc. | Recursive query for communications network data |
US20020176404A1 (en) * | 2001-04-13 | 2002-11-28 | Girard Gregory D. | Distributed edge switching system for voice-over-packet multiservice network |
US6801604B2 (en) * | 2001-06-25 | 2004-10-05 | International Business Machines Corporation | Universal IP-based and scalable architectures across conversational applications using web services for speech and audio processing resources |
US7173925B1 (en) * | 2001-07-18 | 2007-02-06 | Cisco Technology, Inc. | Method and system of control signaling for a wireless access network |
US20030050896A1 (en) * | 2001-09-12 | 2003-03-13 | Shawn Wiederin | Systems and methods for monetary transactions between wired and wireless devices |
US20030177099A1 (en) * | 2002-03-12 | 2003-09-18 | Worldcom, Inc. | Policy control and billing support for call transfer in a session initiation protocol (SIP) network |
US20050233741A1 (en) * | 2002-03-29 | 2005-10-20 | Zamani Moussavi M | System for setting up a connection between two users of a telecommunication network |
US6741695B1 (en) * | 2002-04-03 | 2004-05-25 | Sprint Spectrum, L.P. | Method and system for interfacing a legacy circuit-switched network with a packet-switched network |
US20060080404A1 (en) * | 2002-06-19 | 2006-04-13 | Knut Haber-Land-Schlosser | Method and device for generating a mobile homepage in accordance with context related information |
Cited By (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20040057464A1 (en) * | 2002-09-23 | 2004-03-25 | Michael Sanders | Generic Transport layer |
US20050238002A1 (en) * | 2003-02-10 | 2005-10-27 | Rasanen Juha A | Mobile network having IP multimedia subsystem (IMS) entities and solutions for providing simplification of operations and compatibility between different IMS entities |
US9084233B2 (en) * | 2003-02-10 | 2015-07-14 | Nokia Corporation | Mobile network having IP multimedia subsystem (IMS) entities and solutions for providing simplification of operations and compatibility between different IMS entities |
US8161098B2 (en) * | 2003-08-18 | 2012-04-17 | Rockstar Bidco, LP | Method and system for service denial and termination on a wireless network |
US8880708B2 (en) | 2003-08-18 | 2014-11-04 | Microsoft Corporation | Service denial and termination on a wireless network |
US8346927B2 (en) | 2003-08-18 | 2013-01-01 | Microsoft Corporation | Method and system for service denial and termination on a wireless network |
US9560083B2 (en) | 2003-08-18 | 2017-01-31 | Microsoft Technology Licensing, Llc | Service denial and termination on a wireless network |
US20050041648A1 (en) * | 2003-08-18 | 2005-02-24 | Nortel Networks Limited | Method and system for service denial and termination on a wireless network |
US20050107072A1 (en) * | 2003-11-13 | 2005-05-19 | Lucent Technologies Inc. | System and method for mult-directional message delivery for call waiting |
US11792316B2 (en) | 2003-12-08 | 2023-10-17 | Ipventure, Inc. | Adaptable communication techniques for electronic devices |
US11711459B2 (en) | 2003-12-08 | 2023-07-25 | Ipventure, Inc. | Adaptable communication techniques for electronic devices |
US11800329B2 (en) * | 2003-12-08 | 2023-10-24 | Ingenioshare, Llc | Method and apparatus to manage communication |
US20050281274A1 (en) * | 2004-06-16 | 2005-12-22 | Nec Corporation | VoIP network, media proxy server, and method of providing additional services used in them |
US20060067308A1 (en) * | 2004-09-24 | 2006-03-30 | Seong-Kwan Cho | Providing subscriber information in voice over IP (VoIP) system |
US8233596B2 (en) * | 2004-09-24 | 2012-07-31 | Samsung Electronics Co., Ltd. | Providing subscriber information in voice over IP (VoIP) system |
WO2006048301A1 (en) * | 2004-11-04 | 2006-05-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Selective disablement of mobile communication equipment capabilities |
US7873357B2 (en) | 2004-11-04 | 2011-01-18 | Telefonaktiebolaget L M Ericsson (Publ) | Selective disablement of mobile communication equipment capabilities |
US20060094415A1 (en) * | 2004-11-04 | 2006-05-04 | Veron Christian H | Selective disablement of mobile communication equipment capabilities |
US20060218268A1 (en) * | 2005-03-28 | 2006-09-28 | Andre Beck | Method and apparatus for extending service mediation to intelligent voice-over-IP endpoint terminals |
US7830823B2 (en) * | 2005-06-07 | 2010-11-09 | Siemens Enterprise Communications, Inc. | SIP telephone feature control |
US20060274678A1 (en) * | 2005-06-07 | 2006-12-07 | Siemens Communications, Inc. | SIP telehpone feature control |
US20060294248A1 (en) * | 2005-06-28 | 2006-12-28 | Microsoft Corporation | Automatic server configuration based on user agent |
US20160165057A1 (en) * | 2005-06-29 | 2016-06-09 | Qualcomm Incorporated | Caller-callee association of a plurality of networked devices |
US9294514B2 (en) * | 2005-06-29 | 2016-03-22 | Qualcomm Incorporated | Caller-callee association of a plurality of networked devices |
US9544439B2 (en) * | 2005-06-29 | 2017-01-10 | Qualcomm Incorporated | Caller-callee association of a plurality of networked devices |
US20140079054A1 (en) * | 2005-06-29 | 2014-03-20 | Qualcomm Connected Experiences, Inc. | Caller-callee association of a plurality of networked devices |
US9479604B2 (en) | 2006-01-30 | 2016-10-25 | Qualcomm Incorporated | System and method for dynamic phone book and network content links in a mobile device |
US7995990B1 (en) | 2006-03-06 | 2011-08-09 | Cisco Technology, Inc. | System and method for consolidating accounting data for a communication session |
US8050391B1 (en) * | 2006-03-06 | 2011-11-01 | Cisco Technology, Inc. | System and method for capturing accounting data for a communication session |
US20070206515A1 (en) * | 2006-03-06 | 2007-09-06 | Andreasen Flemming S | System and method for generating a unified accounting record for a communication session |
US7805127B2 (en) | 2006-03-06 | 2010-09-28 | Cisco Technology, Inc. | System and method for generating a unified accounting record for a communication session |
US8619636B1 (en) * | 2006-05-03 | 2013-12-31 | At&T Mobility Ii Llc | Methods and systems for creating optimized transmission paths for VoIP conference calls |
US20080043726A1 (en) * | 2006-08-21 | 2008-02-21 | Telefonaktiebolaget L M Ericsson (Publ) | Selective Control of User Equipment Capabilities |
US20080175225A1 (en) * | 2007-01-18 | 2008-07-24 | Lon-Chan Chu | Just-in-time call registration for mobile call to voip device |
EP2145461A1 (en) * | 2007-04-11 | 2010-01-20 | Cellco Partnership D/B/A Verizon Wireless | Network node for providing remote client deactivation |
EP2145461A4 (en) * | 2007-04-11 | 2011-08-03 | Cellco Partnership Dba Verizon | Network node for providing remote client deactivation |
WO2008127819A1 (en) | 2007-04-11 | 2008-10-23 | Cellco Partnership D/B/A Verizon Wireless | Network node for providing remote client deactivation |
US20090052442A1 (en) * | 2007-08-20 | 2009-02-26 | International Business Machines Corporation | Automatically routing session initiation protocol (sip) communications from a consumer device |
US9230286B2 (en) * | 2008-03-14 | 2016-01-05 | Industrial Technology Research Institute | Methods and systems for associating users through network societies |
US20120284335A1 (en) * | 2008-03-14 | 2012-11-08 | Industrial Technology Research Institute | Methods and Systems For Associating Users Through Network Societies |
US8289848B2 (en) * | 2009-02-02 | 2012-10-16 | Telefonaktiebolaget Lm Ericsson (Publ) | Controlling a packet flow from a user equipment |
US9467391B2 (en) | 2009-02-02 | 2016-10-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Controlling a packet flow from a user equipment |
US9974110B2 (en) | 2009-02-02 | 2018-05-15 | Telefonaktiebolaget Lm Ericsson (Publ) | Controlling a packet flow from a user equipment |
US20100195493A1 (en) * | 2009-02-02 | 2010-08-05 | Peter Hedman | Controlling a packet flow from a user equipment |
US8358757B2 (en) * | 2009-04-15 | 2013-01-22 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a customer premise based communication system |
US9614957B2 (en) | 2009-04-15 | 2017-04-04 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a customer premise based communication system |
US20100266110A1 (en) * | 2009-04-15 | 2010-10-21 | Armstrong Soo | Method and apparatus for providing a customer premise based communication system |
US8971505B2 (en) * | 2009-04-15 | 2015-03-03 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a customer premise based communication system |
US20130083913A1 (en) * | 2009-04-15 | 2013-04-04 | At&T Intellectual Property I, L.P. | Method and apparatus for providing a customer premise based communication system |
US20140181316A1 (en) * | 2011-02-23 | 2014-06-26 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (ims) services registration status |
US20120214480A1 (en) * | 2011-02-23 | 2012-08-23 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (ims) services registration status |
US8611890B2 (en) * | 2011-02-23 | 2013-12-17 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (IMS) services registration status |
US9538492B2 (en) | 2011-02-23 | 2017-01-03 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (IMS) services registration status |
US20150220382A1 (en) * | 2011-02-23 | 2015-08-06 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (ims) services registration status |
US9008650B2 (en) * | 2011-02-23 | 2015-04-14 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (IMS) services registration status |
US20170111406A1 (en) * | 2011-02-23 | 2017-04-20 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (ims) services registration status |
US9705938B2 (en) * | 2011-02-23 | 2017-07-11 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (IMS) services registration status |
US9280408B2 (en) * | 2011-02-23 | 2016-03-08 | T-Mobile Usa, Inc. | System and method for subscribing for internet protocol multimedia subsystems (IMS) services registration status |
US9351203B2 (en) | 2013-09-13 | 2016-05-24 | Microsoft Technology Licensing, Llc | Voice call continuity in hybrid networks |
US9935787B2 (en) | 2013-12-26 | 2018-04-03 | Microsoft Technology Licensing, Llc | Tunneling VoIP call control on cellular networks |
US9510251B2 (en) | 2013-12-31 | 2016-11-29 | Microsoft Technology Licensing, Llc | Call handoff initiation in hybrid networks |
US9877250B2 (en) | 2013-12-31 | 2018-01-23 | Microsoft Technology Licensing, Llc | Call handoff initiation in hybrid networks |
US9560185B2 (en) | 2014-03-19 | 2017-01-31 | Microsoft Technology Licensing, Llc | Hybrid telecommunications network connection indicator |
US9363711B2 (en) | 2014-04-07 | 2016-06-07 | Microsoft Technology Licensing, Llc | User experiences during call handovers on a hybrid telecommunications network |
US9456333B2 (en) | 2014-07-09 | 2016-09-27 | Microsoft Technology Licensing, Llc | Centralized routing in hybrid networks |
US10470232B2 (en) | 2016-09-26 | 2019-11-05 | Microsoft Technology Licensing, Llc | Communication system |
US20180103151A1 (en) * | 2016-10-07 | 2018-04-12 | Microsoft Technology Licensing, Llc | Communication System |
US10097691B2 (en) * | 2016-10-07 | 2018-10-09 | Microsoft Technology Licensing, Llc | Communication system |
Also Published As
Publication number | Publication date |
---|---|
AU2003270543A1 (en) | 2004-04-30 |
US7463620B2 (en) | 2008-12-09 |
WO2004025915A1 (en) | 2004-03-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7463620B2 (en) | Architecture and method for controlling features and services in packet-based networks | |
US8363648B2 (en) | Session initiation protocol (SIP) message incorporating a multi-purpose internet mail extension (MIME) media type for describing the content and format of information included in the SIP message | |
US6937699B1 (en) | System and method for advertising using data network telephone connections | |
WO2005010712A2 (en) | Method and system for suppressing early media in a communications network | |
US20040008837A1 (en) | Combining multimedia services with traditional telephony services in a public branch exchange | |
JP2005512397A (en) | Method for forming usable features for alternate connections of primary connections | |
US8023623B2 (en) | Call control element constructing a session initiation protocol (SIP) message including provisions for incorporating address related information of public switched telephone network (PSTN) based devices | |
EP1677504A1 (en) | Method and apparatus for registering multiple phone numbers associated with a frequently called party | |
KR100602638B1 (en) | The method for VoIP-UMS system access | |
CA2469213C (en) | System and method for integrating multimedia services with traditional telephony via different networks | |
US7016675B1 (en) | System and method for controlling telephone service using a wireless personal information device | |
US7751536B1 (en) | Line appearance reservation for SIP endpoints | |
EP1989634B1 (en) | System and method for providing a compatibility feature in a session initiation protocol (sip) environment | |
KR20070097523A (en) | Personalized calling name identification in telecommunication networks | |
JP2006174477A (en) | Method and apparatus for providing many simultaneous voip call session with respect to single directory number | |
JP2004235778A (en) | Response processing control method | |
WO2002073911B1 (en) | Sharing remote terminals | |
WO2004032471A1 (en) | Multimedia pickup service | |
KR20060028128A (en) | Apparatus and method of providing caller identification in voip service system | |
US7852991B1 (en) | Method and apparatus for updating a speed dialing list | |
US7778274B2 (en) | System and method for providing a compatibility feature in a session initiation protocol (SIP) environment | |
Nie | Dynamic Session Control System for Multi-Devices (DSCSM) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: 3COM CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WANG, GUANGLU;HOMEIER, MICHAEL;TRIPATHI, ANOOP;REEL/FRAME:013297/0696 Effective date: 20020903 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD COMPANY, CALIFORNIA Free format text: MERGER;ASSIGNOR:3COM CORPORATION;REEL/FRAME:024630/0820 Effective date: 20100428 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD COMPANY, CALIFORNIA Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE SEE ATTACHED;ASSIGNOR:3COM CORPORATION;REEL/FRAME:025039/0844 Effective date: 20100428 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:027329/0044 Effective date: 20030131 |
|
AS | Assignment |
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS Free format text: CORRECTIVE ASSIGNMENT PREVIUOSLY RECORDED ON REEL 027329 FRAME 0001 AND 0044;ASSIGNOR:HEWLETT-PACKARD COMPANY;REEL/FRAME:028911/0846 Effective date: 20111010 |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
AS | Assignment |
Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P.;REEL/FRAME:037079/0001 Effective date: 20151027 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 12 |
|
AS | Assignment |
Owner name: OT PATENT ESCROW, LLC, ILLINOIS Free format text: PATENT ASSIGNMENT, SECURITY INTEREST, AND LIEN AGREEMENT;ASSIGNORS:HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP;HEWLETT PACKARD ENTERPRISE COMPANY;REEL/FRAME:055269/0001 Effective date: 20210115 |
|
AS | Assignment |
Owner name: VALTRUS INNOVATIONS LIMITED, IRELAND Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OT PATENT ESCROW, LLC;REEL/FRAME:056157/0492 Effective date: 20210503 |