CN101433035A - Software platform for data-voice applications operating on an internet protocol (IP) phone - Google Patents

Abstract

A software platform in an Internet Protocol (IP) phone having the ability to be used with different communication infrastructures such as broadband, wireless communication and Plain Old Telephone System (POTS) service. Further, the software platform in the IP phone is used in conjunction with a communication architecture, referred to herein as the Transaction Applications Delivery Services (TADS) communications architecture, that provides the ability to develop, deliver and manage data-voice applications operating on the IP phone.

Description

Software platform for operating voice-over-data applications over Internet Protocol (IP) telephony

technical field

The present invention relates to the field of Internet telephony systems, and more particularly to a software platform for the development, delivery and management of voice-over-data applications operating over Internet Protocol ("IP").

Background technique

Recently, multimedia communications in which voice, video, and data information are transmitted and received using Internet Protocol (IP) are transmitted over IP networks. The phones mentioned here as "IP phones", or more generally "converged communication terminals", can be directly connected to an IP network on which a multimedia telephone switching system can be built. An IP phone is a phone, either over the plain old telephone system (POTS) or over an IP network, that can operate and perform voice communications in the same way as a traditional phone. In addition, IP phones can use IP networks for data applications. For example, an IP phone can be connected to an IP network such as a local area network, thus using the network as a private telephone network circuit in an office environment, and as a data exchange network. In another example, an IP phone may use a wide area network, such as the Internet, to communicate with other suitably configured IP phones for data-to-voice exchange. In another example, IP telephony can use data networks for transactional data applications and POTS networks for voice.

Currently, IP telephony has the same functions as those found in traditional Public Switched Telephone Networks (PSTN), such as call forwarding, call waiting, conference calling, and the like. As market leaders in the field of "Voice over IP" (VoIP) calling have been looking for ways to increase their product sales, especially because of the lack of computing power available in VoIP platforms, enhancements to these feature sets In progress slowly. Currently, in order to ensure the best user experience and cost-performance, VoIP platforms have to be specially designed for target market segments and software applications (eg, data-voice applications) operating on IP phones. By having to design and implement a separate VoIP platform for each application operating on the IP phone, the cost of operating different applications on the IP phone can be prevented.

In addition, current service providers (referring to providers of communication services for IP phones to operate) and content providers (referring to providers of data-voice applications operating on IP phones) Data-to-voice applications operating on top of it do not have the ability to successfully develop, configure, monitor, debug, and update.

Thus, there is a need in the prior art for an IP phone configured with a VoIP platform that can support different applications operating on the IP phone. Furthermore, there is a need in the art for the ability to develop, deliver and manage data-to-voice applications operating on IP telephony.

Contents of the invention

In some embodiments, the problems outlined above may be at least partially addressed by a software platform in IP telephony capable of working with different communication infrastructures, such as broadband, wireless communication, POTS services. In addition, the software platform is used in conjunction with a communications framework, referred to herein as a transactional application delivery service (TADS) communications framework, which provides development, delivery and management capabilities for data-to-voice applications operating on IP phones.

In one embodiment of the present invention, a method for identifying a telephone number dialed by an Internet Protocol (IP) telephone user that did not reach the intended recipient includes the steps of: sending, via a server, to the IP telephone An error message indicating the phone number dialed by the IP phone user that failed to connect. The method may further include receiving a warning message from the IP phone, the warning message indicating that the intended recipient's phone number cannot be reached. The method may further include incrementing a failure count for phone numbers that did not reach the intended recipient. The method may further include flagging phone numbers that did not reach the intended recipient if the failure count exceeds a threshold.

In another embodiment of the present invention, a method of identifying a failed contact directory search performed by a user of an Internet Protocol (IP) phone may include the step of: sending an error message, via the server, to the IP phone, the error The message indicates that a directory search performed by the IP phone user failed to identify a contact with the phone number. The method may further include receiving a warning message from the IP phone, the warning message indicating an incorrect graphic. The method may further include incrementing a failure count for the searched contact. The method may further include flagging the directory search if the failure count exceeds a threshold.

In another embodiment of the present invention, a computer program embodied on a machine-readable medium for identifying telephone numbers dialed by Internet Protocol (IP) telephony users that did not reach the intended recipient The product may include the programming step of sending an error message via the server to the IP phone indicating that a phone number dialed by the IP phone user failed to connect. The computer program product may further comprise the programming step of receiving a warning message from the IP phone indicating that the intended recipient's phone number was not reached. The computer program product may further comprise the programmed step of incrementing a failure count for a telephone number that did not reach the intended recipient. The computer program product may further comprise the programmed step of flagging a telephone number that did not reach the intended recipient if the failure count exceeds a threshold.

In another embodiment of the present invention, a computer program product embodied on a machine-readable medium for identifying failed contact directory searches performed by Internet Protocol (IP) telephony users may include the programmed steps of: The server sends an error message to the IP phone indicating that a directory search performed by the user of the IP phone failed to identify a contact with the phone number. The computer program product may further comprise the programming step of: receiving a warning message from the IP phone, the warning message indicating an incorrect graphic. The computer program product may further comprise the programmed step of incrementing a failure count for the searched contact. The computer program product may further include the programmed step of flagging the directory search if the failure count exceeds a threshold.

In another embodiment of the invention, the system may comprise a memory unit adapted to store a computer program adapted to respond to calls made by Internet Protocol (IP) telephony users who did not reach the intended recipient. number for identification. The system may further include a processor coupled to the memory unit, wherein responsive to the computer program, the processor includes circuitry for sending an error message to the IP phone through the server, the error message indicating a failed connection dialed by the IP phone user. phone number. The processor may further include circuitry for receiving an alert message from the IP phone indicating that the intended recipient's phone number could not be reached. The processor may further include circuitry for incrementing a failure count for the phone number that did not reach the intended recipient. The processor may further include circuitry for flagging a phone number that did not reach the intended recipient if the failure count exceeds a threshold.

In another embodiment of the invention, the system may comprise a memory unit adapted to store a computer program adapted to identify failed contacted directory searches performed by Internet Protocol (IP) telephony users. The system may further include a processor coupled to the memory unit, wherein in response to the computer program, the processor includes: a circuit for sending an error message to the IP phone through the server, the error message indicating that a failure to perform by the user of the IP phone A directory search that identifies contacts with phone numbers. The processor may further include circuitry for receiving a warning message from the IP phone, the warning message indicating an incorrect graphic. The processor may further include circuitry for incrementing a failure count for the searched contact. The processor may further include circuitry for flagging the directory search if the failure count exceeds a threshold.

In another embodiment of the invention, the method may include the step of receiving a first wake-up call to an Internet Protocol (IP) phone from a server. The method may further include receiving from the server one or more of reminders, alerts, newspaper material, and information category listings if the first wake-up call is acknowledged by the user of the IP phone. The method may further include receiving the second wake-up call after a certain period of time specified in the user's profile if the first wake-up call is not acknowledged by the user of the IP phone.

In another embodiment of the present invention, a method for contacting an advertiser displayed on an Internet Protocol (IP) phone may include the step of receiving an advertisement displayed on a web page displayed on the IP phone, wherein the advertisement on the web page includes an advertisement based on A Uniform Resource Identifier (URI) for the Session Initiation Protocol (SIP). The method may further include selecting an advertisement. The method may further include passing, via the IP phone's web browser, the URI associated with the selected advertisement to the IP phone's application. The method may further include the application of the IP phone generating a call to a merchant associated with the selected advertisement based on the URI associated with the selected advertisement.

In another embodiment of the present invention, a method for generating a conference call from an Internet Protocol (IP) phone may include the step of creating a conference call conference profile containing contact information for all conference participants in response to scheduling a conference. The method may further include sending the conference call conference configuration file to a first telephony application of the IP phone, wherein the first telephony application is configured to maintain a calendar of the first user of the IP phone. The method may further include executing the conference call conference profile. The method may further include instructing the IP phone to place a conference call to the conference participants indicated in the configuration file.

In another embodiment of the present invention, a method for establishing a conference call with an Internet Protocol (IP) phone may include the step of storing a conference call conference configuration file containing contact information for all conference participants, wherein the conference call A conference profile includes a set of instructions that is followed upon activation of a conference call conference profile. The method may further include receiving an indication to start a conference call associated with the conference call conference profile. The method may further include activating the conference call conference profile. The method may further include inviting each of the conference participants to establish communication with the IP phone.

In another embodiment of the present invention, a method for controlling distribution of content to and from an Internet Protocol (IP) phone may include the step of storing profile preferences for profiles in a database, wherein the profile preferences for profiles Options include rules about which phone calls and content a user of the IP phone is allowed to receive and which phone calls and content a user of the IP phone is prohibited from receiving. The method may further include associating the profile with a schedule that enables and disables different phone calls and content at different times of the day. The method may further include receiving a request to send the content to the IP phone user. The method may further include determining, based on profile preferences of the profile, whether the user of the IP phone is permitted to receive the content.

In another embodiment of the present invention, a method for controlling distribution of content to and from an Internet Protocol (IP) phone may include the step of storing profile preferences for profiles in a database, wherein the profile preferences for profiles The options include rules about which phone calls and content the first user of the IP phone is allowed to receive and which phone calls and content the first user of the IP phone is prohibited from receiving. The method may further include associating the profile with a schedule that enables and disables different phone calls and content at different times of the day. The method may further include receiving, by the second user, a request to telephonically connect to the first user of the IP phone. The method may further include determining whether to allow the first user of the IP phone to telephonically connect to the second user based on the profile preferences of the profile.

In another embodiment of the present invention, a method for a user to access content on an Internet Protocol (IP) phone from a restaurant may include the step of: generating a content package to be displayed on the IP phone, wherein the content package includes customized content , where the content pack includes one or more of the following: in/out assistance and information, billing information, room service order, and concierge information. The method may further include: sending the content package to the IP phone. The method may further include providing control to a user of the IP phone to access content of the generated content package.

In another embodiment of the present invention, a method for supporting management of directory updates may include the steps of: in response to a vendor performing one or more of updating, correcting, and setting contact information associated with a phone line of interest A confirmation code is generated. The method may further include sending the confirmation code to the seller's email address along with the phone number called. The method may further include generating one or more of email and facsimile. The method may further include sending one or more of an email and a fax to the vendor indicating that the phone line contact information has been successfully updated.

In another embodiment of the present invention, a method for distributing content to Internet Protocol (IP) phones may include the step of storing content created by an administrator on a database repository. The method may further include assigning the profile to the phone group. The method may further include: reading the content identification from the database and assigning the read content identification to the phone group. The method may further include: returning content corresponding to the requested identifier.

The foregoing has outlined, rather broadly, the features and technical advantages of one or more embodiments of the invention so that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.

Description of drawings

A better understanding of the invention may be gained when considering the following detailed description when taken in conjunction with the following drawings, in which:

Figure 1 shows an embodiment of the invention implementing a multi-tier fixed telephone system interacting with different communication infrastructures;

Figure 2 shows a typical hardware configuration of a TADS server and applications according to one embodiment of the present invention;

Figure 3 shows an embodiment of the invention of the external configuration of an IP phone;

Figure 4 shows a typical hardware configuration of an IP phone according to an embodiment of the present invention;

Fig. 5 shows the software platform of the IP telephone according to an embodiment of the present invention;

Fig. 6 shows an embodiment of the present invention of the communication infrastructure service layer of the IP telephony software platform;

Fig. 7 shows an embodiment of the present invention of the general aggregated communication infrastructure service layer of the IP telephony software platform;

Figure 8 shows the relationship between open-standard protocols and TADS protocol suites and services according to one embodiment of the present invention;

Figure 9 shows an embodiment of the invention of the Domain Specific Application Layer of the IP telephony software platform;

Figure 10 illustrates an embodiment of the present invention using the Application Host Service ("AHS") architecture of the software platform in IP telephony;

Figure 11 illustrates an embodiment of the present invention of a client-server Transactional Application Delivery System (TADS) communication architecture;

Figure 12 shows an embodiment of the present invention of the server side unit of the transaction application delivery system;

Fig. 13 shows an embodiment of the present invention of the client-side unit of the transaction application delivery system;

Figure 14 shows an embodiment of the invention on the server side of the transactional application delivery system;

Figure 15 shows an embodiment of the invention on the client side of the transactional application delivery system;

16 is a flowchart of a method of creating and storing personal preferences or configuration files via a configuration portal to a wake-up server, according to one embodiment of the invention;

FIG. 17 is a high-level state machine diagram of a wake-up service according to an embodiment of the present invention;

Figure 18 shows a sequence of events associated with an IP phone automatically answering a wake-up call according to one embodiment of the invention;

Figure 19 shows a sequence of events associated with a user answering a wake-up call, according to one embodiment of the invention;

Figure 20 shows how a wake-up service can remind the user of a special date in the calendar according to one embodiment of the present invention;

Figure 21 shows how a wake-up service can alert the user to a special entertainment event according to one embodiment of the present invention;

Figure 22 shows how a wake-up service according to one embodiment of the invention can send an urgent unread email or voicemail to the user, where the email or voicemail arrives during the night and needs immediate attention during the early morning;

Fig. 23 shows how the wake-up service according to one embodiment of the present invention sends information that may be of interest to the user when waking up;

Figure 24 shows a sequence of events associated with an optional failure threshold for the manual scheme of the enhanced data integrity method, according to one embodiment of the invention;

Figure 25 shows a sequence of events associated with an optional failure threshold for an automated scheme of the enhanced data integrity method, according to one embodiment of the present invention;

Figure 26 shows a detailed sequence of events applicable to both manual and automated methods, associated with selectable failure thresholds, according to one embodiment of the invention;

Figure 27 is a flowchart of a method for facilitating catalog update management via vendor self-fulfillment according to one embodiment of the invention;

Figure 28 illustrates a sequence of events associated with a "click-to-dial" enhanced merchant-consumer interaction method in accordance with one embodiment of the present invention;

Figure 29 illustrates the sequence of events associated with the "more information" enhanced merchant-consumer interaction method in accordance with one embodiment of the present invention;

Figure 30 shows a sequence of events associated with an auto-conference call phone synchronization scheme according to one embodiment of the present invention;

Figure 31 shows a sequence of events associated with an auto-conference call phone subscription scheme according to one embodiment of the invention;

Figure 32 shows the sequence of events associated with an auto-conference call phone subscription scheme according to one embodiment of the invention;

FIG. 33 shows a sequence of events associated with a usage control method related to a content distribution scheme according to one embodiment of the present invention;

FIG. 34 shows a sequence of events associated with a usage control method related to a call control scheme according to one embodiment of the present invention;

Figure 35 illustrates a sequence of events associated with a method for facilitating the control and distribution of content for a service call, according to one embodiment of the invention;

Figure 36 shows a sequence of events associated with distributing content to a phone according to one embodiment of the invention;

Figure 37 shows a sequence of events associated with updating existing content, according to one embodiment of the invention;

Figure 38 illustrates a sequence of events associated with processing a local content request, according to one embodiment of the invention;

Figure 39 illustrates a sequence of events associated with processing an external content request, according to one embodiment of the invention;

Figure 40 shows a sequence of events associated with handling PMS interactions in a service setup according to one embodiment of the invention;

Figure 41 shows another sequence of events associated with handling PMS interactions in service settings when the PMS initiates a request to update PMS information on the phone according to one embodiment of the present invention;

Figure 42 illustrates the exchange of messages between the TADS server and the IP phone during software use and update operations according to one embodiment of the present invention;

Figure 43 illustrates the exchange of messages between a TADS server and an IP phone during a software configuration operation according to one embodiment of the invention;

Detailed ways

Although the present invention has been described in relation to Internet Protocol (IP) telephony, it should be appreciated that the principles of the present invention are applicable to any Internet-connected device, such as an Internet appliance. Furthermore, it should be noted that implementations applying the principles of the present invention to such Internet-connected devices would fall within the scope of the present invention.

In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known circuits and software modules have been shown in block diagram form in order not to obscure the present invention in unnecessary detail. For the most part, details involving synchronization considerations, etc. have been omitted since such details are unnecessary to gain a complete understanding of the invention and are within the skill of one of ordinary skill in the relevant art.

Figure 1 shows a high-level diagram of one embodiment of the invention of a system 100 implementing a multi-tier fixed telephone system 101 interacting with different communication infrastructures. Referring to FIG. 1 , system 100 allows a multi-tier fixed telephone system 101 (referred to herein as "IP Phone A" and more generally as "IP Phone") to interact with other entities, such as data network 102, respectively, via different communication infrastructures. , a voice network 103, a mobile network 114 and a public switched telephone network (PSTN) 105 to provide calling functions and run applications. A detailed description of the external configuration of the IP phone 101 is described below with reference to FIG. 3 . In addition, a detailed description of the hardware configuration of the IP telephone 101 will be described later with reference to FIG. 4 . In one implementation, IP phone 101 may be coupled to computer system 112 , data network 102 and public switched telephone network (PSTN) 105 . IP phone 101 can communicate via data network 102 with third party Voice over IP (VoIP) terminals 116 and 117 (IP phones B and C, respectively). IP phone 101 can additionally communicate with analog phone 113 via PSTN 105. IP phone 101 may additionally communicate with analog phone 113 via voice network 103 via data network 102 . Additionally, IP phone 101 may communicate with mobile phone 115 via mobile network 114 via data network 102 .

System 100 may further include a public switched telephone network (PSTN) gateway 104 coupled to data network 102 . PSTN gateway 104 may be configured to translate signaling and media between data network 102 coupled to IP phone 101 and PSTN 105. PSTN 105 may be coupled to conventional telephone 113. PSTN gateway 104 may allow IP phone 101 to communicate with standard analog phone 113 in PSTN 105.

System 100 may further include mobile gateway 106 coupled between data network 102 and mobile network 114 . Mobile gateway 106 may be configured to translate signaling and media between data network 102 and mobile wireless network 114 . Mobile network 114 may be coupled to mobile telephone 115 . Mobile gateway 106 may allow IP phone 101 to communicate with mobile phone 115 in wireless network 114 . IP phone 101 may signal mobile gateway 106 to enable calls intended for mobile phone 115 to terminate on IP phone 101 .

System 100 may further include an Internet Protocol private branch exchange (IP-PBX) 107 coupled to data network 102 , voice network 103 , analog telephone 113 , or VoIP telephone 116 . IP-PBX 107 can be configured to interconnect voice network 103 and data network 102 respectively in an enterprise environment and provide centralized call control functionality.

System 100 may further include a call service server 109 coupled to data network 102 . The call service server 109 can be configured to provide services that allow the IP phone 101 to communicate with other analog terminals and VoIP terminals and extend the range of call features available to it.

System 100 may further include a converged messaging and directory server 110 coupled to data network 102 . Converged messaging and directory server 110 may be configured to contain all necessary components to provide users with a unified converged platform to send and receive electronic and voicemail messages. Additionally, server 110 may provide IP phone 101 with access to personal and public contact directories.

System 100 may further include a vendor server 118 coupled to data network 102 . Vendor server 118 may be configured to allow end users to access and purchase goods and services via IP phone 101 .

System 100 may further include a content and media server 119 coupled to data network 102 . The content media server 119 may be configured to allow end users to access media content via the IP phone 101 .

System 100 may further include a TADS proxy server 120 coupled to data network 102 . A TADS proxy server 120 may be placed in front of two or more TADS servers for load balancing and redundancy.

System 100 may further include a database repository 111 coupled to data network 102 . Database repository 111 may be configured to provide IP phones 101 and servers 107, 108, 109, 110, 119, and 120 with the data needed to perform their tasks.

System 100 may further include an application server 108 coupled to data network 102 . Application server 108 may be configured to contain server-side components of client/server applications accessed through IP phone 101 (discussed further below), such as components of a transactional application distribution system (TADS) (discussed further below).

It is noted that FIG. 1 is exemplary and does not depict all components of system 100 (eg, provisioning and configuration servers) for the sake of brevity. It is further noted that system 100 is not limited in scope to the disclosed systems.

FIG. 2 shows a typical hardware configuration of server 108 (FIG. 1), which represents the hardware environment in which the present invention is practiced, including performing the steps performed by server 108, as described below in connection with FIGS. 18-43. Referring to FIG. 2 , the server 108 may have a processor 210 coupled to various other components through a system bus 212 . Operating system 240 may run on processor 210 and provide control and coordinate the functions of the various components of FIG. 2 . In accordance with the principles of the present invention, applications 250 may operate in conjunction with operating system 240 and provide calls to operating system 240 that implement various functions or services performed by applications 250 . For example, applications 250 may include programs for performing the steps performed by server 108, as described below, for various enhanced services described in connection with FIGS. 18-43.

A read only memory (ROM) 216 may be coupled to system bus 212 and includes a basic input/output system (“BIOS”) that controls certain basic functions of server 108 . Random access memory (RAM) 214 and disk adapter 218 may also be coupled to system bus 212 . It should be noted that software components including operating system 240 and applications 250 may be loaded into RAM 214, which may be the main memory of server 108. Disk adapter 218 may be an integrated drive electronics ("IDE") adapter that communicates with a disk unit 220, such as a disk drive. It has been noted that the applications for performing the steps performed by the server 108 may be resident on the disk unit 220 or the applications 250, as described above in connection with FIGS. 18-43.

Referring to FIG. 2 , a communications adapter 223 may also be coupled to system bus 212 . The communication adapter 223 can be connected to the bus 212 through the external network 102 so that the server 108 can communicate with the IP phone 101 .

Implementations of the invention include implementation as a computer system programmed to perform the method or methods described herein, and implementation as a computer program product. Depending on computer system implementation, the set of instructions for performing the method or methods may reside resident in random access memory 214 of one or more computer systems, typically configured as described above. Until required by server 108, the set of instructions may be stored as a computer program product in another computer memory, for example, in disk drive 220 (which may include, for example, an optical disk or a floppy disk ultimately used in disk drive 220). Furthermore, the computer program product can also be stored on another computer and transmitted when desired to the user's workstation via a network or an external network such as the Internet. Those skilled in the art will understand that the physical storage of the instruction set physically changes the medium on which it is stored so that the medium carries computer-readable information. The change may be electrical, magnetic, chemical or some other physical change.

FIG. 3 shows an embodiment of the elements of the invention of the external configuration of the IP telephone 101 . Referring to FIG. 3, the IP phone 101 includes a touch screen display 301 capable of displaying graphical images and capturing input from the user by moving in the screen with a finger or an instrument such as a stylus designed for this purpose. Press specific areas to achieve. The IP phone 101 may further include a message waiting indicator 302 to alert the user that a new message has arrived in the user inbox. Below the touch screen display 301, the IP phone 101 includes four direction keys 303A-D (303A is configured to move the image displayed on the screen 101 upward; 303B is configured to move the image displayed on the screen 101 downward; 303C is configured to move the image displayed on the screen 101 downward; 303D is configured to move the image displayed on the screen 101 to the right); and the OK button 304, as an alternative to using the touch screen to manipulate the user interface screen 301 and select the focused item. IP phone 101 includes a SEND key 305 and an END key 306 for each side of arrow keys 303A-D, respectively. The keys 305, 306 can be used as an alternative to a touch screen to perform call functions in the graphical user interface 301, such as initiating and ending calls. Additionally, the keys 305, 306 can be used to help the user navigate the user interface; for example, use the END button 306 to go directly to the home screen or to cancel an action. IP phone 101 may also include the following connectors distributed along side 313 for external devices: Universal Serial Bus (USB) 314, Handset 315, Microphone 316, Ethernet for Personal Computer (PC) and Local Area Network (LAN) respectively Switch ports 317 and 318, power supply 319, RJ-11 (POTS) connector 320, antenna 321 for supporting wireless protocols including but not limited to Wireless Fidelity (WI-FI) and Zigbee, RS-232 serial row port 322, and JTAG connector 323.

The IP phone 101 may further include an opening 307 for a phone speaker and a handset cradle bracket 308 for a corded or cordless handset. The IP phone 101 may further include a standard telephony keypad array 309 consisting of the digits 0 to 9, an asterisk key, and a pound key. Below keypad 309 , IP phone 101 may include a circular key 310 for activating and deactivating speakerphone 307 . On each side of the speaker microphone key 310, two triangular keys 311A-B can be used to increase (311B) and decrease (311A) the volume of an active audio output handset, earpiece, speaker or ringer. Below speakerphone key 310 and volume keys 311A-B, respectively, IP phone 101 includes indicator 312 that is on when speakerphone 307 is active and off when speakerphone 307 is inactive.

With reference to FIG. 4 , an implementation manner of the hardware configuration of the IP phone 101 is provided below. Referring to FIG. 4 , the IP phone 101 may include a processor 401 coupled to various other components through a system bus 413 . An operating system 410 may run on the processor 401 and provide functions for controlling and coordinating the various components of FIG. 4 . Applications 411 in accordance with the principles of the present invention may operate in conjunction with operating system 410 and provide algorithms, domain-specific knowledge, and calls to operating system 410 that implement the various functions or services performed by applications 411 . Applications 411 may include, for example, applications configured to perform wake-up call transactions, phone directory searches, message and content replies, and enhanced call-control functions. Applications 411 may include other applications to perform the steps performed by IP phone 101 as discussed further below.

A read-only memory (ROM) 402 may be coupled to system bus 413 and may include a basic input/output system (“BIOS”) that controls certain basic functions of IP phone 101 . Persistent storage ("FLASH") 412 may be coupled to system bus 413 and include operating system 410, configuration data, and user data. It is further noted that one or more applications 411 may reside in FLASH 412 . Random access memory (RAM) 409 and disk adapter 407 may also be coupled to system bus 413 . It should be noted that software components including the operating system 410 and applications 411 can be loaded into RAM 409, which can be the main memory of the IP phone 101. Disk adapter 407 may be an integrated drive electronics ("IDE") adapter that communicates with a disk unit 408, such as a disk drive. It has been noted that the above-mentioned applications may be resident in the disk unit 408 .

Returning to FIG. 4 , in connection with FIG. 1 , communications adapter 405 may also be coupled to system bus 413 . Communication adapter 405 may interconnect bus 413 with external network 404, enabling IP telephone 101 to communicate with data network 102, servers 107, 108, 109, 110, 118, 119, with analog telephone 113 via PSTN 105, and with The mobile phone 115 and the like communicate.

Returning to FIG. 4 , in conjunction with FIG. 3 , other devices 403 may be integrated into system bus 413 via miscellaneous input/output (I/O) ports 406 .

Implementations of the invention include embodiments as VoIP phones (IP phones) programmed to perform the method or methods described herein, and embodiments as computer program products. Depending on implementation, the set of instructions for performing a method or methods may be resident in random access memory 409 of one or more systems generally configured as described above. Until needed by IP phone 101 , the set of instructions may be stored as a computer program product in another computer memory, for example, in disk unit 408 . Furthermore, the computer program product can also be stored at another computer and transmitted to the IP phone 101 over a network or an external network such as the Internet when desired. Those skilled in the art should understand that the physical storage of the instruction set physically changes the medium on which it is stored, so that the medium bears computer-readable information. The change can be electrical, magnetic, chemical or some other physical change.

The IP phone 101 includes a software platform with multiple layers adapted for use with different applications operating on the IP phone 101 and for use with different communication infrastructures. An embodiment of such a software platform is provided below in conjunction with FIG. 5 .

Referring to FIG. 5, the platform 500 of the IP phone 101 may include five layers. Layer 1 (hardware platform) 501 of platform 500 may include software to control the physical implementation of IP phone 101 . The physical implementations include, but are not limited to, application specific integrated circuits (ASICs), processing units, input/output (I/O) devices, peripherals, and memory units.

Layer 2 (operating system services) 502 of platform 500 provides interfaces to access operating system (OS) services and hardware platform devices. Layer 2 502 provides an execution environment for software modules and hardware abstraction layers. Among the responsibilities of layer 2 502 are: performing common OS services, such as memory management, task management, data and time information, and access to peripheral devices; providing file system services to emulated hard disk drives on flash memory devices; providing transmission control protocol Implementation of the Internet Protocol (TCP/IP) networking API and other required protocols such as Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), Simple Network Time Protocol (SNTP), and Simple Network Management Protocol (SNMP); provides an embedded web server implementation that allows remote configuration through a web browser; implements core graphics functions for drawing, window management, event routing, fonts, and bitmaps; and peripherals for each aggregated communication terminal 101 A device implements a hardware driver.

Layer 3 (communication infrastructure services) of platform 500 may be configured to interface with multiple communication infrastructures. As shown in FIG. 6, layer 3 503 of platform 500 includes local service pools and remote service pools. It is important to note that the system 100 (FIG. 1) includes a base set of telephony functions provided by the Common Converged Communications Base Service (CCCBS) layer 504, as described below, since such functions are not server/proxy dependent, the The base set can directly communicate with fewer servers.

Figure 6 shows an embodiment of the invention for layer 3 503. Referring to FIG. 6 , in conjunction with FIG. 1 and FIG. 5 , layer 3 503 may include a remote service pool 601. Remote service pool 601 represents components that are not locally resident on an IP phone 101, but are resident on a PSTN 105 or call service 109 with which the IP phone 101 must cooperate, To provide extended communication capabilities and aggregated voice/data/video services and/or interface with dedicated IP PBX 107, application servers 108 and with PSTN elements such as central switches, call managers and soft switches. As described below, for each specific external collaborating entity, there may be an adapter module that implements all or part of the functions disclosed by the Communication Infrastructure Service (CIS) API 507.

Layer 3 503 may further include a local service pool 602. Local service pool 602 represents components that are resident on IP phones 101 and can provide interfaces to communicate and cooperate with private IP PBXs 107, application servers 108, and PSTN elements such as central switches, call managers, and soft switches . Although the vendor-specific interface implementation may reside locally or remotely on the network server or switch, the advantage of implementing the component on the network server or switch and leaving only those services locally is that the Each change to creates a new aggregated communication terminal 101 image requirement. Additionally, gateway implementations may not be constrained by the (possibly) limited IP phone 101 resources.

Returning to FIG. 5 , the platform 500 includes a layer 4 (generic aggregated communication infrastructure service) 504 . As shown in FIG. 7, layer 4 504 includes communication (call) specific services and other data services required by domain-specific aggregated communication applications (representing applications operating on the IP phone 101).

FIG. 7 shows an embodiment of the present invention for layer 4 504. Referring to FIG. 7, layer 4 504 includes call service 701. Call service 701 includes call processing functions that implement the core functionality to initiate, terminate and manage telephone calls over VoIP and/or POTS communication infrastructure. Layer 4504 may further include the implementation of signaling, media transport, voice processing and call control functionality. Among the responsibilities of these functions are: providing basic call control features; providing call setup and teardown functionality through protocols such as Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP) and others; (RTP) and Real-time Control Protocol (RTCP) protocols provide media transport and signaling; provide voice processing functions (echo cancellation, voice activity detection (VAD), jitter buffering, etc.); and notify call-related events to upper layers.

Layer 4 504 may further include other services 702, such as data services. Services 702 may include hypertext transfer protocol (HTTP) clients, remote procedure call/simple object access protocol (RPC/SOAP), extensible markup language (XML) parsers, directory services, configuration, personal computer/personal digital assistant ( PC/PDA) synchronization, and user interface. The HTTP client service provides a transport protocol to store and retrieve objects such as XML documents and images from servers, and plays an important role in IP communication and application development, thus enabling aggregated communication terminals 101 to participate in wcb-centric architecture. RPC/SOAP services implement interfaces to make remote procedure calls. Remote procedure calls allow IP phone 101 to send requests to and receive responses from components in the computer network. SOAP is an implementation of RPC to use XML to format request/response information, and HTTP to transport the information. Providing support for SOAP enables IP phone 101 to participate in web services. The XML parser service translates data presented in XML format into internal data structures and requests services. Documents built using XML allow information to be shared between different platforms and applications. In the IP phone 101, there are at least three applications for XML: to describe user interface layout and components, to make remote procedure calls, and to format configuration files. Lightweight Directory Access Protocol (LDAP) provides an interface to access information in directory servers. Typically directory services are used to implement the three main requirements of Internet Protocol (IP) telephony: authentication, personalization, and white pages. Configuration service allows management of IP phone 101 settings such as: device ID, network, dial plan, audio (codec, dual tone multi-frequency (DTMF), voice processing), call control, SIP related parameters, volume , Display, Date/Time, Authentication, Security, Voicemail, Phonebook, Ringer Behavior, Power Management, Language, Peripherals, and Software Management. These services also implement routines for automatically retrieving phone configuration and software updates from the server. The PC and PDA communication service provides an interface to communicate and cooperate with external user devices such as PCs and PDAs. The IP phone 101 should work closely with these devices to share information, keep that information synchronized, and complete tasks more efficiently.

Figure 8 shows the relationship between open-standard protocols 802 on top of physical, data link and network layers 803, and TADS protocol suite and services 801, according to one embodiment of the present invention. The TADS protocol suite and services 801 use open-standard communication protocols to exchange information with similar software components in other TADS-enabled devices. New protocols and services can be added to an existing pool by defining the protocol and service type. These types are used by the TADS Client Protocol Engine 1101 (discussed below in conjunction with FIG. 11 ) and the TADS Server Protocol Engine 1006 (discussed below in connection with FIG. 12 ) to direct TADS messages to their An appropriate destination will be discussed in conjunction with FIG. 11 ) or one of the TADS servers depicted in FIG. 1 . Each protocol or service defines its own message format and message sequences that are required in engaging in providing or requesting such a service. Examples of these services include, but are not limited to: Enhanced Wake-Up Service (provided by TADS Wake-Up Call Server 108) (Figures 14-21), Enhanced Data Integrity Method (provided by TADS/Yellow Pages Alert Server 108) (Figures 22-25) , Enhanced Merchant-Consumer Interaction Method (provided by RVCD 2402 (discussed in conjunction with Figure 24) in cooperation with IP Phone 101) (Figures 26-27), Enhanced Auto-Conference Method (via SIP Server 109, TADS Calendar Server 108 , customer database 1208 (discussed in conjunction with FIG. 12 ) provided in cooperation with IP phone 101) (FIGS. 28-30), enhanced usage control method (through TDS server 108 and customer DB 1208 (discussed in conjunction with FIG. 12) with IP phone 101 in cooperation) (FIGS. 31-32), and enhanced user experience methods (provided by TA distribution engine 109 (discussed in conjunction with FIG. 12) in cooperation with IP Phone 101) (FIGS. 33-41). Each of these services represents an embodiment of the current invention and contributes to all services that provide advertisements on the TADS platform.

Returning to FIG. 5 , platform 500 includes layer 5 (domain-specific applications) 505 . As shown in FIG. 9 , layer 5505 implements business logic and presentation logic for running applications operating on IP phone 101 .

Figure 9 shows an embodiment of the unit of the present invention at layer 5 505. Referring to Figure 9, Layer 5 505 includes business logic 901 that provides mechanisms to incorporate services provided by lower layer modules into consistent applications that add some value to the end user. Some components of the business logic 901 may run locally on the IP phone 101, while some components will run remotely in the application server 108 (FIG. 1). Some examples include extended calling capabilities, phone directories, administrative and diagnostic tools, unified messaging, intelligent call management, instant messaging, contact management, personalized ring tones, call tracking, remote collaboration tools, and industrial specific application. It is at this layer that domain-specific differentiation is implemented.

Layer 5 505 further includes presentation logic 1102, which responds to the fact that the user interface (UI) module is primarily concerned with the mechanics of user interaction and how to present an appropriate presentation to the user, in contrast to business logic 901 which is primarily concerned with application domain policies Interact with persistent storage. The UI module can be changed according to the customer's needs without changing the core functionality of the application. For example, the same application domain modules with rich web-based clients, or text-based clients can be reused. Furthermore, application modules can be tested independently without resorting to difficult graphical user interface (GUI) scripting tools.

Returning to FIG. 5, layer 4 504 may play an intermediary role in the design of different IP phones 101 via the following API. Operating system services API 506 provides common methods to access services provided by the operating system. For each specific operating system, there exists a module that supports extraction.

Communication Infrastructure Services (CIS) API 507 provides common methods to access aggregated communication services available via installed infrastructure. For each vendor-specific infrastructure, there will be modules that support extraction.

The Common Converged Communication Base Service (CCCBS) API 508 provides a standard method to access previously developed common Converged Communication Services to satisfy a wide range of Converged Communication domain-specific applications.

The platform 500 can be used to develop domain-specific applications for converged communication devices (specific applications operating on IP phones 101) to redirect one or more domain-specific applications developed for specific IP phones 101 to new hardware platform and/or operating system and/or communication infrastructure.

FIG. 10 illustrates one embodiment of the present invention using an Application Hosting Service ("AHS") architecture 1000 of software platform 500 (FIG. 5) in an IP phone 101. As shown in FIG. AHS architecture 1000 may be used to facilitate management of third party applications operating on platform 500 (FIG. 5) of IP phone 101. This includes, but is not limited to: searching the web for suitable applications, downloading host-supported applications to the target, loading and running the application on the target, and security and protection mechanisms to protect other code and data on the target from malicious applications.

Figure 10 further shows an embodiment of the invention how layer 4 (CCCBS) 504 of the software platform 500 in the IP phone 101 supports transaction applications (TA) in layer 5 (domain-specific applications) 505 . Note that three examples of applications of domain-specific hosts are presented as examples, namely: Enhanced Wake-Up Call Service 1001 , Automated Conference Service 1002 and Data Integrity Service 1003 . Enhanced wake-up call services 1001 are a series of services that allow users to establish configurations that will, among other capabilities, allow the TADS server to adjust wake-up call times to account for real-time traffic and weather conditions as well as user calendar events. Automated conference service 1002 allows a user to schedule and book a conference call, which will then be automatically initiated without user intervention. Data Integrity Service 1003 allows automatic monitoring of business directory services (eg, Yellow Pages) for erroneous listings due to disconnected numbers, moved numbers, wrong numbers, etc. All three types of applications 1001-1003 can generate transactions, voice calls and other events for added user configuration.

The TADS protocol stack 1004 in the CCCBS layer 504 implements the communication protocols required to distribute TAs, execute transactions, and collect TA events. The TADS transaction manager 1005 in the CCCBS layer 504 uses the TADS protocol stack 1004 to perform transactions with another transaction manager at the TADS server 1201 . The TADS programming manager 1006 in the CCCBS layer 504 receives and manages programming information from the TADS server 1201 to schedule initiated programming and other advertising. Application Hosting Service (AHS) 1007 provides the environment required by third-party applications to run in Layer 5 505. A Secure Sockets Layer (SSL) module 1008 in the CCCBS layer 504 provides secure transmission of information between nodes of the network.

TADS client 1302 (discussed further below in connection with FIG. 13 ) services can be shared by applications for a wide range of domains, thus reusing the code that provides the services and effectively shortening the development cycle of domain-specific applications.

In the operating system service layer 502 , the application host service framework 1000 may further include an RTOS service 1009 that interfaces with platform drivers and hardware 1010 .

One embodiment of a client-server communication architecture is shown in FIG. 11 for which a software platform 500 (FIG. 5) and method can be used to develop a client-aggregated communication that can support the distribution of value-added services to end users. Terminal device 101.

Referring to FIG. 11 , a client-service communication architecture 1100 forms the basis of a Transactional Application Delivery System (TADS) for service providers and/or third-party developers and content providers to rapidly develop, deliver, and manage revenue-generating applications for IP phones 101 and productivity-enhancing data-to-voice applications. Data-Voice applications are applications that take advantage of those Voice over Internet Protocol (VoIP) and/or POTS/broadband infrastructures.

As shown in FIG. 11 , a TADS server-side unit 1101 communicates with a TADS client-side unit 1102 such as an IP phone 101 via a data network 102 such as the Internet. Client-service communication architecture 1100 has built-in flexibility, allowing it to evolve with advances in hardware, software, protocols, thereby providing an expanded platform for the delivery of applications and content. The following are the main features of the software platform 500 (client-server communication architecture 1100).

TADS 1100 provides an integrated download and content management system that enables software and content delivery to supported devices. This download manager supports the entire process of software provisioning, including submission of content and applications from third-party developers, testing and validation of those applications, bundling, pricing, statistically-based targeting, and delivery to supported endpoints.

TADS 1100 further includes the ability to provision, configure, diagnose or update compatible devices remotely (as described in Figures 42-43 below). This can provide online help support to users and reduce the need for in-store visits. With this capability, service providers can bring in new customers, push the latest software updates to endpoints, or remotely perform moves, additions or changes to a customer's system.

The TADS server 1101 can process all voice and data before transmission to the device. The TADS server 1101 communicates with the device 1102 to determine the optimal delivery, compression, and formatting of the information to be displayed on the IP phone 101 . This content optimization will maximize the service provider's use of the available device resources occupied at the consumer's premises.

TADS 1100 further includes the capability to use open standard interfaces to enable quick and easy integration with operators' existing systems and third-party equipment and software.

In addition, all software components of the TADS 1100 include redundancy and load balancing to provide a very high level of service availability. To enable carrier-grade reliability, if the TADS server 1101 encounters any hardware or software failure, it routes all voice and data traffic to other servers. TADS 1100 provides scalability by simply adding servers. A more detailed description of TADS 1100 is provided below in conjunction with FIGS. 12 and 13 .

FIG. 12 shows an embodiment of the present invention on the server side of TADS 1100. Referring to FIG. 11 , TADS 1100 includes a server side 1101 and a client side 1102. It has been noted that the TADS server 1101 refers to the server 108 (FIG. 1) and the TADS client 1102 refers to the IP phone 101 (FIG. 1 and FIGS. 3-4).

Referring to FIG. 12, the TADS server side unit 1101 includes a front end console 1201 that allows administrators to submit multimedia content via a web-based interface (not shown), define demographic/configurable characteristics of target audiences, schedule applications and The date and time when the Service should be delivered and, if applicable, billed for the Service.

The TADS server side unit 1101 further includes a TADS server protocol engine 1206 that handles all communications using the TADS protocol on the server side to process transactions, distribute applications and services, subscribe customers to distribution groups, and send The user delivers the product.

The TADS server side unit 1101 further includes various server software modules and databases 1205 upon which telephony applications 1203 and aggregated voice-data applications and services 1204 can be built. The TADS server-side unit 1101 further includes a settlement manager 1202 that maintains a log of all end-user actions during the aggregated communication session, which can then be used to determine the overall value chain (merchant, content provider, service provider , and owners of content distribution platforms) and to obtain valuable closed activity reports that can be used to drive new services and log valuable demographic data on all end-user transactions. TADS Heartbeat Handling 1207 informs other TADS enabled devices about its processor load and other transient data by sending periodic heartbeat messages. Proxy server 120 (FIG. 1) may be used to distribute requests for TADS services among several TADS servers 108 (FIG. 1), content media servers 119 (FIG. 1), and aggregated messaging and directory servers 110 (FIG. 1) for consistent You can balance the load across all these servers strategically, or avoid sending requests to servers that have become unavailable. Unavailable servers are for servers that have not received a heartbeat message for a configurable period of time. They can be thought of as infinitely loaded with requests for services. The TADS server software modules and database are depicted in more detail in FIG. 14, as described further below.

FIG. 13 shows an embodiment of the present invention on the client side of TADS 1100. The client side includes a TADS client protocol engine 1301 that handles all communications using the TADS protocol on the client side in order to process transactions, execute applications and access services. The client side also includes various TADS client software modules 1302 and databases, as described further below, which are described in more detail in FIG. 15 .

Referring to FIG. 14, a TADS front-end (console) 1201 can be configured as a front-end to an API 1403 for Transactional Application Delivery System (TADS) programming. The TADS front end (console) 1201 presents a selective view of all data accessible to the programmatic API 1403. This includes custom graphical user interfaces, web-based interfaces, command line interfaces, and others. Custom front ends can also be developed by third parties.

The TADS programming API 1403 exposes all aspects of the TADS framework to calling applications. This includes browsing (reading, writing, deleting, adding) of information on consumers, vendors, billing, channel definitions, transactions, content and distribution groups.

The TADS server side unit 1101 further includes a vendor management module 1404 configured to allow access to a vendor database 1405 . Vendor management module 1404 may be an adapter to communicate with an existing system or internal vendor database 1405 . All information about a vendor is stored and accessed through the vendor management module 1404 . The vendor management module 1404 can be used by the content programming module 1406 to obtain vendor information. Vendors buy advertising space/time on IP phones 101 and get orders from customers through IP phones 101 .

The TADS server-side unit 1101 further includes a demographics module 1407 configured to access a customer database 1408 and apply rules to query records exhibiting particular demographic characteristics. The demographics module 1407 may further include adapters to communicate with existing systems or internal customer databases 1408 .

The TADS server side unit 1101 further includes a user management module 1409 . Vendors using TADS can consider users of TADS-enabled clients as consumers. Through the use of the user management module 1409, users may be added, changed or deleted. All information about a user is accessed through the user management module 1409.

As mentioned above, the TADS server side unit 1101 further includes a content programming module 1406 . The content programming module 1406 is included in the network definition distribution and advertisement display through TADS-enabled clients such as IP phones 101 . Advertisements are displayed at remote clients through transactional applications distributed by TADS server 1101 . Vendors can use the graphical user interface exposed by the TADS front end 1201 to access the content programming module 1406 . The content programming module 1406 may be used to create distribution groups for advertisements and to schedule presentations among clients in the group. Vendors can use criteria such as user demographics, geographic or organizational boundaries, and purchase history to define the level and distribution of impressions for advertisements. The resulting schedule information is stored in distribution group schedule database 1410 .

The TADS server side unit 1101 further includes a transaction engine 1411 . The transaction engine 1411 is an engine that automatically processes transactions from the TADS client 1102 . Transaction engine 1411 may be configured to maintain a record of all transactions processed. The transaction engine 1411 can also access an accounting database 1412 (or an external accounting system). The transaction engine 1411 may also alter the customer database 1408 to reflect in the customer database 1408 specific information about the customer's purchasing behavior. A transaction is initiated by a client 1102. A transaction is initiated with a user selecting a service or application on a TADS enabled device 1102 . The client and server exchange session details, and the product is delivered (when appropriate) over the network 102 after confirmation of the request. Delivery ends when the product is delivered to a TADS enabled device such as IP phone 101 .

As mentioned above, the TADS server side unit 1101 further includes a TADS server protocol engine 1206 . The TADS server protocol engine 1206 can be configured to handle all communications using the TADS protocol on the server side. The TADS communication protocol is used to process transactions, distribute advertisements, subscribe clients to distribution groups, and deliver products to clients 1102 .

The TADS server side unit 1101 further includes a transaction application (TA) distribution engine 1413 . The TA distribution engine 1413 can be used to distribute the transaction application (TA) to the TADS-capable client 1102 such as the IP phone 101 . The TA distribution engine 1413 may be configured to look up the schedule database for TA distributions and use the TADS protocol engine 1206 to send them to the appropriate destinations. A destination is defined as the group of TADS capable clients 1102 that have been identified as having the appropriate channel to handle the TA to be sent. The transaction application has the task of advertising products and completing sales transactions from a network of TADS enabled clients 1102 .

Channels of content are created based on demand based on demographic information (managed by Demographics Module-1407 and stored in Consumer DB 1408) and vendor requests (managed by Vendor Management Module 1404 and Vendor DB 1405). Each channel may have different characteristics including, but not limited to, the size and location of the display (screen "real estate"), the type of content provided by the channel (still or animated images, sound, voice messaging, multimedia (integrated visual and audible elements, even apps, etc.)), the duration of the presentation (10sec, 30sec, 30min), the time and frequency of the presentation ("main time", "red eye", "repeat every 10 minutes", etc.) for each event display, Rules-based presentation ("show during calls", "show when users search for pizza", etc.), target demographics (eg, "show in luxury suites", "show in underground areas", "show in technical Office Park Display", etc.), numeric display levels (100 TADS-enabled devices, 100,000 TADS-enabled devices), and device-based display levels ("TADS-enabled phones," "TADS-enabled PCs," "TADS-enabled TADS-enabled PDA"). Based on channel characteristics, vendor configuration, and demographic information, the content programming module 1406 can create channels for content distribution. Each channel will have an overhead associated with putting information into the channel based on its characteristics and sales agreements obtained with vendors (perhaps by auctioning time on the channel). This information will be billed 1412 by the billing manager 1416 for the time the vendor is used in the channel. Certain channels can have different overhead and characteristics at different times of day (for example, "prime time" may have a larger overhead than "red-eye"). Also, TADS 1101 may assign different channels to TADS capable devices based on TADS capable device 1102 group information (managed by group subscriber/non-subscriber module 1414 and stored in distribution group schedule 1410).

The TADS server-side unit 1101 further includes a group subscription manager module 1414 configured to handle subscription and unsubscription for each distribution group by the TADS-capable client 1102 . The distribution group includes an identifier for each of the TADS-capable clients 1102 that are members of the group. Reservation can occur at client registration time, or can be initiated by the server at any time the TA schedules distribution. The scheduling process is the delivery of scheduling information by the TA to the client 1102 supporting TADS.

The TADS server side unit 1101 further includes a product delivery engine 1415 configured to assist the processing engine 1411 to complete the sale by delivering purchased products to the TADS enabled client 1102 whenever possible.

The TADS server side unit 1101 further includes an accounting manager module 1416 for accessing accounting information. The billing manager module 1416 may include adapters to communicate with external billing systems or the internal billing database 1412 .

The billing database 1412 may contain information on sales made on behalf of vendors for which fees are distributed through TADS and TA. The service provider bills the vendor for the usage of the TADS. Accounting database 1412 may also handle service-usage accounting.

Other databases in the TADS server side unit 1101 include a transaction database 1417 configured to contain records of all transactions supporting TADS.

Another database in the TADS server-side unit 1101 is the vendor database 1405, as described above. Vendor database 1405 contains vendor information.

Another database in the TADS server-side unit 1101 is the customer database 1408, as described above. Customer database 1408 contains all information about customers. A consumer is a user of a client 1102 that supports TADS.

Another database in the TADS server side unit 1101 is the distribution group schedule database 1410, as described above. Distribution group schedule database 1410 contains information about what devices should get what TAs and when they should be displayed.

Another database in the phoneme 1101 on the TADS server side is the content database 1418 . The content database 1418 contains products and TAs that will be delivered by the TADS server 1101 .

Referring to FIG. 15 , elements of the TADS client 1102 include a TA programming manager module 1505 configured to receive reservation requests from the server through the TADS client protocol engine 1301 . The TA programming manager module 1505 can be configured to track what TAs are expected to pass through each channel at a particular time, and where they are presented in the phone user interface.

The TADS client protocol engine 1301 can be configured to handle all communications using TADS in each client. The TADS communication protocol is used to process transactions, distribute advertisements, subscribe clients to distribution groups, and deliver products to customers 1102.

The client side unit 1102 may further include a TA execution engine 15 configured to execute TA at a client such as the IP phone 101 . TAs use the transaction broker module 1508 to perform transactions with the TADS server 1101. The TA execution engine 1503 also presents advertisements on the user interface of the TADS enabled client 1102 , such as the IP phone 101 .

The client-side unit 1102 may further include a UI event handler 1506 . The UI event handler 1506 is not provided by the TADS framework. It is part of the infrastructure of the client 1102 that supports TADS. The UI event handler 1506 acquires events from the UI of the TADS-capable client, such as the IP phone 101 , and forwards these events to the transaction broker module 1508 and the TA execution engine 1503 .

The transaction broker module 1508 interacts with the processing engine 1501 at the TADS server 1101 through the TADS client protocol engine 1101 . The transaction broker module 1508 assists the TA to complete the transaction.

The client-side unit 1102 may further include a product installer module 1507 configured to install products into the database 1502 delivered through the TADS framework.

The client side unit 1102 may further include a product downloader module 1501 that interacts with the product delivery engine at the TADS server 1101 through the TADS client protocol engine 1101 . The product downloader module 1501 downloads purchased products through TADS.

The client-side unit 1102 may further include a group and channel binding database 1504 that contains what TAs will be delivered by each distribution group, and when and where in the UI their advertisements will appear.

As mentioned above, the installed applications database 1502 will hold all applications installed through TADS.

It has been noted that server and client-side implementations of TADS 1100 may include other and/or additional modules, which have not been described for clarity. Note further that TADS 1100 can be implemented by different combinations of modules, and those modules presented in the discussion of FIGS. 12-15 are exemplary.

Additional details regarding TADS as described above are disclosed in U.S. Patent Application Serial No. 11/082,361, filed March 17, 2005, entitled "Internet Protocol (IP) Phone with Search and Advertising Capability" , which application is hereby incorporated by reference in its entirety.

Examples of services implemented by an embodiment of the present invention described in connection with FIGS. 1 and 11-15 include, but are not limited to: enhanced wake-up service (provided by TADS wake-up call server 108) (FIGS. 16-23), enhanced Data Integrity Method (provided via TADS/Yellow Pages Alert Server 108) (FIGS. 24-27), Enhanced Merchant-Consumer Interaction Method (via Remote VoIP Call Distributor (RVCD) 2402 (discussed in conjunction with FIG. 28) with IP Phone 101 provided) (FIGS. 28-29), enhanced auto-meeting method (provided through SIP server 109, TADS calendar server 108, customer database 1208 (discussed in connection with FIG. 12) in cooperation with IP phone 101) (FIGS. 30-32 ), enhanced usage control methods (provided by TDS server 108 and consumer DB 1208 (discussed in conjunction with FIG. (discussed in conjunction with Figure 14) provided in cooperation with IP Phone 101) (Figures 35-41). Each of these services represents an embodiment of the current invention and contributes to providing all services advertised on the TADS platform.

The following presents a discussion of the exemplary services or applications described above in conjunction with FIGS. 16-41 , which may accommodate the TADS building blocks and software platform 500 ( FIG. 5 ) discussed in FIGS. 11-15 . Accordingly, each of these figures of Figures 16-41 will be discussed below in conjunction with Figures 1-13.

TADS Wake Up Call Service (TWCS) 108 controls service execution and configuration. Vendor Server 118 , Consistent Messaging Server 110 , Content and Media Server 119 cooperate with the TWCS via data network 102 to deliver specific services requested by users via IP Phone 101 . IP phone 101 receives the wake-up call and enables all other enhanced services described in connection with Figures 16-23.

The enhanced wake-up service relies on the user being able to create and store personal preferences and configuration files directly at the IP phone terminal 101 or using a web browser through a configuration entry to the wake-up server 108 . The configuration sequence is presented in FIG. 16 . FIG. 16 is a flowchart of a method 1600 for creating and storing personal preferences or configuration files via a configuration entry to the wake-up server 108 . Referring to FIG. 1 and FIG. 16 , in step 1601 , the user logs in to the wake-up server 108 . In step 1602, if wake-up server 108 verifies the user's authentication credentials, wake-up server 108 provides the user with access to the main configuration page. In step 1603, the user adds, modifies or deletes any of the following configuration parameters: rules for wake-up calls, their schedule (recurrence) and wake-up sound preferences; snooze mode: interval between calls, how long, Wake-up sound; list of tasks and appointments (manually or by synchronizing with another server); source of information feeds and directories of interest: news, weather, sports, travel itineraries. For example, wake-up server 108 may automatically adjust wake-up call settings based on user-specified rules. The input parameters for these rules can be information obtained on the network or on the user's profile (weather and traffic conditions, morning appointments, out-of-store events, travel schedules, etc.). Alternatively, wake-up server 108 may suggest changes to settings to the user, rather than automatically changing them, so that the user can verify and allow the changes. Some specific situations where this approach can be applied are as follows. Based on sudden traffic jams on my way to work or to the airport, the wake-up server 108 automatically adjusts the wake-up call time earlier than normal by a certain period of time. In another example, the wake-up server 108 suggests a change in reoccurring wake-up calls due to an early morning appointment at the office, an appointment with a doctor, an appointment with a mechanic, or a trip with a friend. In another example, the wake-up server 108 may use information from the user's travel itinerary to create or suggest wake-up call settings in advance. In another example, the wake-up server 108 may look up the estimated arrival time from the hotel to the airport in the network (taking into account distance and traffic conditions) and adjust the time accordingly. Wake up server 108 may even take into account differences in time zones. Vendors can log into the TADS server in the same way as normal users, and can associate advertisements, services, and offers with wake-up calls and schedule advertisements, services, and offers for wake-up calls.

It is noted that method 1600 may include other and/or additional steps, which are not described here for the sake of clarity. Note further that method 1600 may be performed in an order other than the order presented, and that the order presented in the discussion of FIG. 16 is exemplary. It is further noted that certain steps in method 1600 may be performed in a substantially simultaneous manner.

FIG. 17 shows a high-level state machine diagram of a wake-up service according to an embodiment of the present invention. This processing consists of three states: call execution (1702), wakeup (1703), and doze (1704). Processing begins at a start point (1701) and ends at an end point (1705). The process starts at start point 1701 when the wake-up server 108 initiates a call and the phone 101 starts ringing or automatically answers the call. If the user confirms the wake-up call, ie prompts the wake-up server 108 that he/she has woken up, the state machine transitions to the wake-up state 1703. Once in the awake state 1703, the wake-up server 108 may begin pushing enhanced services (reminders/alerts) described below to the phone 101 . If the user does not confirm the wake-up call, and the user has activated the snooze function in his/her configuration file, then the state machine will transition to the doze state 1704. Based on the user's profile, the state machine will stay there for a given amount of time, and then transition to the Perform Call state 1702 to attempt to wake up the call again.

There are two main scenarios associated with enhanced wake-up calls. In the first scenario, phone 101 automatically answers the call. This scheme is depicted in FIG. 18 . In the second scenario, the user answers the call. This scheme is depicted in FIG. 19 .

Figure 18 shows (via the arrows indicated below) the sequence of events associated with phone 101 (Figure 15) automatically answering a wake-up call, according to one embodiment of the present invention. Wake-up server 108 performs a call to IP phone 101 at the time of the wake-up call (arrow 1802). The call is marked as a wake-up call. The IP phone 101 checks the identity of the incoming call (arrow 1803), and if in fact the call is a wake-up call, the IP phone 101 automatically answers the call (arrow 1804), thus sending a call answer signal to the wake-up server 108 signal (arrow 1805). Wake-up server 108 contacts media server 119 to indicate user preferences, ie, what sound will be sent (arrow 1806). Wake-up server 108 connects the local end of the media channel to media server 119 to send audio (music, pre-recorded messages, and live morning news) to phone 101 in real-time. When the user 1801 wakes up, the user 1801 will provide a confirmation to the wake-up server 108, either hang up the call, or choose to continue listening to the media stream (arrow 1807). Either of these two actions will indicate to the server 108 that the wake-up call was successful (arrow 1808). If the user 1801 does not perform any of these two actions, the server 108 disconnects the call after a given time elapses, and considers the wake-up call to be unsuccessful. After time has elapsed, the user 1801 will complete the wake-up session (arrow 1809).

Figure 19 shows (via the arrows marked below) the sequence of events associated with a user 1801 answering a wake-up call, according to one embodiment of the invention. Wake-up server 108 makes a call to IP phone 101 (arrow 1901 ) upon a wake-up call that has an identity that phone 101 recognizes as a wake-up call. Upon receiving the wake-up call, the terminal 101 starts ringing. Since phone 101 can recognize the incoming call as a wake-up call, it can play an appropriate ring tone according to the current user configuration (arrow 1902). Ringtone tones can go beyond simple rhyme patterns and include more complex sound files, such as short music snippets and relaxing sounds (stored in the phone's non-volatile memory). When the user 1801 wakes up, the user 1801 will answer the call (arrow 1903) and the terminal will send a signal to the wake-up server 108 that the call has been answered (arrow 1904). The wake-up server 108 connects the phone to the media server 119, which will start transmitting the configured audio stream (arrow 1905) while the media session remains established (arrow 1906). User 1801 will provide server 108 with confirmation that he/she has woken up, and either hangs up the call or chooses to continue listening to the incoming audio stream (arrow 1907). If the user 1801 does not pick up the phone 101, the server 108 will disconnect the call after a given time elapses and consider the call unsuccessful. After a period of time has elapsed, user 1801 will complete the call session (arrow 1908).

The wake-up server described above may also provide functionality similar to that found in digital alarm clocks. In this case, wake-up server 108 initiates a wake-up call, which may be answered either automatically by phone 101 or by user 1801 . If the wake-up call fails (ie, the user does not provide confirmation), the server 108 will try again, relying on the callback settings configured by the user. If the user does not acknowledge the call within a given amount of time, the wake-up call was unsuccessful. The server 108 continues to initiate wake-up calls and check for success until the abandon condition specified in the configured user's profile is reached. The number of times the server 108 calls back and the interval between calls can be customized for each user. For example, server 108 may call back every 10 minutes for half an hour using a relaxing sound, and then try using a stronger sound at shorter intervals after that period of time. If no answer is received, the system will trigger an alert which will signal the appropriate personnel to check the physical condition of the person for whom the wake-up call was made (retirement home, hospital, restaurant, etc.).

Figure 20 shows (via the arrows marked below) how the wake-up service reminds the user 1801 of a specific date in the calendar, such as birthdays, anniversaries, according to one embodiment of the invention. The user 1801 is allowed to arrange for the purchase and delivery of the gift, if applicable. TADS/wake-up server 108 and user 1801 establish a wake-up call, which can be answered automatically by phone 101 or by user 1801 (arrow 2005). The server 108 notes that there is an entry for a birthday or anniversary in the user's calendar today. Server 108 suggests a list of gift options (flowers, chocolates, books, etc.) (arrow 2006). User 1801 selects a gift option (arrow 2007). Server 108 provides a list of local vendors for that gift category (arrow 2008). User 1801 selects a vendor from the list (arrow 1809). IP phone 101 downloads a transaction application (arrow 2010) to allow user 1801 to select, pay for and arrange for delivery of gifts (arrow 2011). User 1801 interacts with IP phone 101 to perform an order. Phone 101 posts the transaction to server 108 . The TADS server 108 posts transactions to a particular vendor server 118 . Alternatively, since the TADS server 108 may have provided a contact number, the user 1801 can simply press a button to call the vendor to carry out the order.

Figure 21 illustrates (via the arrows marked below) how a wake-up service according to one embodiment of the invention may alert the user 1801 to special entertainment events that may be of his/her interest and allow the user 1801 to book or purchase tickets for these events . TADS/wake-up server 108 and user 1801 establish a wake-up call, which can be answered automatically by phone 101 or by user 1801 (arrow 2101). The server 108 takes note of the date and provides the user 1801 with a list of weekend events (concerts, movies, theatre, conferences, travel special packages) that match the list of interests stored in the user's profile on the server 108 ( arrow 2102). User 1801 selects an activity from the list (arrow 2103). The phone 101 downloads the application (arrow 2104) to allow the user 1801 to purchase tickets and make/confirm reservations (arrow 2105). User 1801 interacts with IP phone 101 to perform an order. Phone 101 delivers the transaction to server 108 (arrow 2106). The TADS server 108 posts the transaction 1811 to the specific vendor server 118 (arrow 2107).

For the service industry, combinations of the services described in connection with Figures 20 and 21 are conceivable. The wake-up service shows the user 1801 what is available on the restaurant menu or list of events/tours for that day. The server 108 and the user 1801 establish a wake-up call. The server 108 presents the user 1801 with a list of restaurant breakfast menus and events for that day. Phone 101 downloads an application to allow user 1801 to order room service for breakfast or book tickets for a given event.

Figure 22 shows (via the arrows marked below) how a wake-up service according to one embodiment of the invention can send an urgent unread email or voicemail to user 1801 that arrives late at night and Needs immediate attention in the morning. TADS/wake-up server 108 and user 1801 establish a wake-up call, which can be answered automatically by phone 101 or by user 1801 (arrow 2201). Server 108 requests information from messaging server 110 about a new urgent email or voicemail for the current user at a later time (arrow 2202). Alternatively, messaging server 110 may notify wakeup server 108 when a new message arrives. Then, the server 110 may check whether there is any message log recorded at the time of the wake-up call. The phone 101 downloads the application so that the user 1801 sees and hears the list of emergency messages, and answers if appropriate (arrow 2203). User 1801 browses the list of messages (arrow 2204) and requests more information about a particular message (arrow 2205). The phone 101 shows text or plays the selected message (arrow 2206). After reviewing the message, user 1801 may use phone 101 to answer, if appropriate (arrow 2207).

Figure 23 shows (via the arrows marked below) how a wake-up service according to one embodiment of the invention can send information to the user 1801 that may be of interest when waking up (usually in the morning), such as news headlines, local weather Conditions, sports results, and stock quotes (collectively "newspaper material"). TADS/wake-up server 108 and user 1801 establish a wake-up call, which can be answered automatically by phone 101 or by user 1801 (arrow 2301). The server 1801 sends a list of message categories for selection based on the user's preferences (arrow 2302). User 1801 selects the type of information he/she wants to browse (arrow 2303). Server 108 sends the application to phone 101 to present information to user 1801 (arrow 2304). A download of each category of interest (arrows 2305, 2306, 2307) is initiated from the content server 119, vendor server 118 or TADS/wakeup server 108. The server 108 shows the user information of personal interest in the morning (arrow 2308), such as task lists and appointments for the day, news headlines, local weather, traffic conditions, sports results, inspirational/funny quotes, and cartoons comic strip. User 1801 may initiate a transaction based on the advertisement delivered by TADS server 108 along with information of interest (arrow 2309). Server 108 sends the transaction application (arrow 2310). The transaction is established by user 1801 via IP phone 101 (arrow 2311). The transaction is posted to the TADS server 108 (arrow 2312) and ultimately to the vendor server 118 (arrow 2313).

The services enabled by one embodiment of the present invention related to the development of an enhanced data integrity method that accommodates the TADS building blocks discussed in FIGS. 14-15 are discussed below in conjunction with FIGS. 24-26 and software platform 500 (FIG. 5) to facilitate maintenance of digital directories such as the Yellow Pages (discussed below in conjunction with FIGS. 24-26). That is, FIGS. 24-26 disclose a method for identifying a phone number dialed by a user of the IP phone 101 that does not reach the intended recipient. Additionally, FIGS. 24-26 disclose a method for identifying a failed contact directory search performed by a user of the IP phone 101 .

This enhanced approach is based on the availability of the so-called TADS/Yellow Pages (YP) alert server 108 (discussed further below in connection with FIG. Alerts that calls to specific phone numbers or URIs can be done. This alert mechanism is triggered on the call either manually via the UI event handler 1506, or automatically by an error response code. The alert can be classified as critical (manually generated) or informational (automatically generated). In both cases, administrator 2408 (FIG. 24, described below) has the ability to select failure thresholds that will cause warnings to be generated.

Figure 24 shows (via the arrows indicated below) the sequence of events associated with an optional failure threshold (manual resolution) according to one embodiment of the invention. Referring to FIG. 24, the call service server 109 sends a wrong number (the user tries to connect to the number but finds it is a wrong number) and/or a SIP/H323 error message 2401 to the IP phone 101 along with an error sound or statement. The interface provided by the IP phone 108 via the UI event handler 1506 displays a "broken link" type button. The user triggers a warning report by pressing the button. This activity will send a "Critical Warning" message (arrow 2402) to the TADS Server 108 (via the Transaction Broker Module 1508 and the TADS Client Protocol Engine 1301) indicating a "Bad Phone Number". The critical alert message will cause the TADS server 108 to increment the corresponding alert count for the called number (arrow 2403). Once a phone number's alert count reaches the selected failure threshold, the number will be flagged (arrow 2404 ) and displayed on the TADS front end console 1201 . The Directory Manager 2208 will then see the marked number (arrow 2405) and will initiate an investigation to determine why the failure occurred (disconnected number, changed number, etc.) (arrow 2406). Once the cause of the failure is determined, the administrator 2408 proceeds to update the database to avoid future call failures (arrow 2407).

Figure 25 shows (via the arrows marked below) the sequence of events associated with selectable failure thresholds (automatic resolution) according to one embodiment of the invention. Referring to FIG. 25, the call service server 109 transmits a SIP error message (with any one of the following SIP error codes: 301, 404, 410, and 604) to the IP phone 101 (arrow 2501). Upon receiving the error message, the IP phone 101 will generate an information alert (arrow 2502) which will be sent to the TADS server 108 (via the TA execution module 1303 and the TADS client protocol engine 1301) indicating "bad phone number" . This information alert message will cause the TADS server 108 to increment the corresponding alert count for the called number (arrow 2503). Once a phone number's alert count reaches the selected failure threshold, the number will be flagged (arrow 2504 ) and displayed on the TADS front end console 1201 . The Directory Manager 2408 will then see the marked number (arrow 2505) and will initiate an investigation to determine why the failure occurred (disconnected number, changed number, etc.) (arrow 2506). Once the cause of the failure is determined, the administrator 2408 proceeds to update the database to avoid future call failures (arrow 2507).

Figure 26 shows (via the arrows indicated below) a detailed sequence of events associated with selectable failure thresholds applicable to both the previously described manual and automated methods, according to one embodiment of the invention. Referring to FIG. 26, the call service server 109 sends a SIP or wrong number (the user tries to connect to the number, but the result is a wrong number) error message (with any one of the following SIP error codes: 301, 404, 410, and 604) to the IP phone 101 (arrow 2601). Once an error message is received, the IP Phone 101 will send a message to the TA Execution Engine 1303 (arrow 2602), and the UI Event Handler 1506 wakes up the system with an alert. The TA execution engine 1503, the UI event handler 1506 deliver the warning to the transaction broker module 1508 (arrow 2603), which then delivers the warning to the TADS client protocol engine 1101 (arrow 2604), which enables The alert is forwarded to the TADS server protocol engine 1206 using the TADS protocol (arrow 2605). The TADS server protocol engine 1206 reports the alert (arrow 2606) to the transaction engine (alert manager) 1411, which increments the corresponding alert count (arrow 2607) and records it on the transaction database 1417. If the threshold is reached, the transaction engine (Alert Manager) 1411 will flag the phone number (arrow 2608 ) and display on the TADS front end console (Alert Viewer) 1201 . Once the alert administrator 2408 sees the tagged number (arrow 2609), he/she will initiate an investigation (arrow 2610) and, if appropriate, update the Yellow Pages database 1418 (arrow 2611).

In both the manual and automated methods described above, the TADS server protocol engine 1206 will receive alerts and store them on the transactional database 1417 until they are cleared or saved to an alternate location. The Warning Manager app will monitor warnings or warning counts based on data configured by the administrator. This application will make alerts available to system administrators by displaying alerts using the TADS front-end console 1201 . Reports of flagged numbers may be viewed by Yellow Pages administrators in order to initiate inquiries regarding the validity of a particular alerted or flagged number. Alerting mechanisms can be implemented by using SIP (SUBSCRIBE/NOTIFY) messages, SNMP based traps, or similar protocols and services. If SNMP is used, this part of the TADS communication protocol is defined for the object identifiers of the management information base and the way they will be translated. If the SIP SUBSCRIBE/NOTIFY mechanism is used, the schema of the XML files exchanged with the two types of messages defines the TADS communication protocol for this service. The TADS client protocol engine 1301 can provide a programmatic interface to create and parse the object or file. Note that the above approach uses warnings as the important type of event, but could be extended to use other events in order to create more granular schemes for updating the directory database. For example, a traffic measure could be used where the number of Yellow Pages local lookups compared to the number of final local lookups yields a call availability performance indicator.

In both the manual and automatic methods described above, the content of the alert message may include ID, severity (information, crisis, other), type (contact, graphic, etc.), query, query return, error source, and cause source. False triggers can be generated by the IP phone 101 . Sources of errors can include IP phones 101, dial plans, or empty searches (searches that return contacts with no phone numbers). Reason codes can include blank numbers, obfuscated numbers (letters instead of numbers), SIP error codes, manual (user notified error), etc. Warning types can include wrong graphics or phone numbers.

The services enabled by one embodiment of the invention are discussed in conjunction with FIG. 27, where the invention pertains to the development of a self-fulfilling method that accommodates the TADS building blocks and software platform 500 discussed in FIGS. 14-15 (FIG. 5) to facilitate the management of telephone directory updates.

From time to time, a vendor may have to relocate telephone lines from one location to another. Although the phone number remains the same, the geographic location associated with the phone number changes. It will take several months for service providers to update their systems to reflect this change. This can result in a potential loss of consumer leads when consumers conduct searches for local businesses.

Figure 27 is a flowchart of a method 2700 for facilitating management of catalog updates via vendor self-fulfillment, according to one embodiment of the invention. Referring to FIG. 27 , in step 2701 , the vendor connects to the TADS server 108 via the front-end console 1201 and obtains access to his records via the vendor management module 1404 . In step 2702, the vendor updates, corrects or sets the contact information associated with the phone line of interest. In step 2703, the TADS server 108 generates a confirmation code which is sent to the seller's email address along with the phone number to call. In step 2704, the Vendor calls the telephone number provided by the TADS server (implemented using Caller ID) from the line whose contact information is to be updated, and enters a confirmation code when prompted. In step 2705, the TADS server 108 generates and sends a new email or fax to the vendor, indicating that the phone line contact information has been successfully updated.

It is noted that method 2700 may include other and/or additional steps, which are not depicted for clarity. Note further that method 2700 may be performed in an order different from that presented, and that the order presented in the discussion of FIG. 27 is exemplary. It is further noted that certain steps in method 2700 may be performed in a substantially simultaneous manner.

The services enabled by one embodiment of the present invention are discussed in conjunction with FIGS. 28-29 , where the invention pertains to the development of enhanced merchant-consumer interaction methods that accommodate the TADS building blocks discussed in FIGS. 14-15 and A software platform 500 (FIG. 5) to facilitate communication between the parties discussed below in connection with FIGS. 28-29. In particular, "click to dial" and "more information" scenarios are presented. The "click-to-dial" scheme allows an end user to click a button placed on a participating merchant's web page, directing the end user's IP phone to then place a call to the corresponding number. The "More Information" scheme allows the end user to click a button placed on a participating merchant's web page or phone-based advertisement, directing the merchant to dial the end user's IP phone.

Figure 28 illustrates (via the arrows indicated below) the sequence of events associated with the "Click-to-Dial" enhanced merchant-customer interaction method in accordance with one embodiment of the present invention. A browser plug-in or small application called Remote VoIP Call Distributor (RVCD) 2802 should be installed on the user's personal computer. This software will be configured with information from the IP phone 101 for the user in the form of a URI. Alternatively, an IP Phone 101 auto-discovery mechanism may be implemented when the RVCD 2802 broadcasts to its subnet requesting identification of all answering IP Phones 101. The IP phone 101 will respond to the request with a TADS echo message indicating the Internet Protocol contact information, and the credentials to be authenticated by the requestor. This is also possible if the IP phone 101 periodically broadcasts a SIP message calling the SUBSCRIBE method with all the information required by the RVCD. The web server 108 contains an advertisement page 2801 to be formatted by a SIP based URI. Once the end user 2801 clicks on an ad, phone number or SIP URI (arrow 2803), the web browser will pass the URI to the RVCD 2802 (arrow 2804). Once the RVCD 2802 receives the target URI, it will send a SIP message calling the REFER SIP method to the user's IP phone 101 (arrow 2805) to make a new call to the merchant 1801 (arrow 2806). Alternatively, the RVCD 2602 can use the information previously received in the SIP SUBSCRIBE by the RVCD 2802 to send a NOTIFY message (arrow 2805) to the IP phone 101 to make a new call (arrow 2806), but the preferred method is to use the REFER message . Once the call is accepted, the dialog is established (arrow 2807).

Figure 29 illustrates (via the arrows indicated below) the sequence of events associated with the "more information" enhanced merchant-customer interaction method, according to one embodiment of the present invention. To the local end user's 1801 personal computer, a local HTML page 2801 will be available. This page 2801 will contain a form which once filled will generate a cookie which is saved on the personal computer 1801. The cookie will contain contact information (URI, phone number, etc.) for the user. Alternatively, the page 2801 served by the page server 108 should also include a way to request contact information in case cookies are not available. The web server 108 will contain an application that will be used to track and send "Request More Information" transaction messages. Requests for information transactions will be presented in a continuous fashion on the GUI available through this application. These requests for information transactions may be one-time only transactions or subscription transactions. In the case of a subscription transaction, the requester can choose how to obtain the subscription content on the IP phone 101 via email or via targeted advertising. The web server 108 will serve a specially formatted ad page (arrow 2901) which will contain Java script which will be used to fill the hidden sheet. Alternatively, pages served by web server 108 should also include a way to request contact information in case cookies are not available. These pages may be considered TADS transactional applications. A cookie can be thought of as a user profile. When the end user 1801 browsing the webpage clicks on the link of "request more information" (arrow 2902), the browser will send the form to the server (arrow 2903). This form will have a set of values (Item ID, Title ID, Inventory ID) hard-coded at the server 108 that will be used to determine the type of information requested. Once the form is received by the TADS server 108, the information will be saved in the database 808 (arrow 2904) and presented to the user through the TADS front end console 1201 previously described for use by the customer representative 2808 (arrows 2905, 2906, 2907). The front-end console will be provisioned, which causes it to periodically fetch content from the database (arrow 2905). Once new requests are obtained from the database (arrow 2906), they will be displayed on the front-end console. At this point, the customer representative 2808 will call the client to provide the requested information (arrow 2908). Alternatively, the customer representative 2808 will send the targeted content to the IP phone 101 (arrow 2909). Information retrieved through the form may be used to collect and store demographic statistics.

The services enabled by one embodiment of the present invention are discussed below in conjunction with FIGS. 30-32 , where the invention pertains to the development of an auto-conference call method that accommodates the TADS building blocks discussed in FIGS. 14-15 and software platform 500 (FIG. 5) to facilitate automatic generation and management of conference calls. Three approaches are presented based on phone synchronization, phone subscription, and server-hosted conferencing.

The enhanced approach differs from the current approach in that a TADS enabled user profile can be created to integrate with the user's calendar, directory and profile settings to automatically manage meeting-calls based on desired rules. For example, users don't have to remember to set up call forwarding at specific times, or reschedule scheduled conference calls due to scheduling conflicts. Users can create rules that take into account the user's calendar, directory, and profile settings. For example, a user may create a rule that says "From 6am to 6pm, if the calendar indicates a meeting, then forward the call to <phone 2>". TADS-based user-profiles allow information mobility so that all TADS-enabled communication devices can load your user-profile without having to program rules for each location. The integration of the user's calendar, the user's profile, and rules allows the user more freedom by combining the rules with fine-grained functionality and allows for enhanced responsiveness (e.g., the user does not have to remember to respond to a vacation message on the phone) set up). A user can set up a rule that whenever the calendar says to be out of office, the phone will send a vacation message indicating when the user will be back, except for calls from phone-X, calls from phone-X will automatically forward to phone-Y .

The method described here is based on user-profiles. Users will access a TADS-based user profile to specify how they want to handle automated meeting functionality. These profiles may contain preferences for the user as to how incoming calls are handled or how outgoing calls are made based on certain rules. User profiles are mobile. When users move from one location to another, they can decide to bring all or part of their profile to the new location. For example, a user may want to have settings for home, business, travel, etc. in their user profile. User profiles combined with automated conferencing to set rules for call handling based on phone/calendar conditions. Some possible rules could be: Do Not Disturb; Call Forwarding; Automatic Message Response; Priority Based Interruption.

An example of rule usage is now discussed. For example, a "do not disturb" rule is used when the user is already on a conference call, or any time during the day when the user needs to be alone. By using a "Do Not Disturb" rule, users can set the rule so that incoming calls and messages go directly to voicemail. Call Forwarding can be set up so that calls are automatically forwarded to a different number at certain times of the day. For example, in a work-sharing situation, two employees can set up call forwarding to automatically forward calls to each other during each other's lunch time. "Automatic Message Response" allows special messages to be sent back to callers at special times. For example, at the time the call is answered, if the user's schedule indicates that the user will be out of the office for 2 hours, there will be an automated message response asking the caller to leave a message and informing the caller that the message will be received in 2 hours. "Priority Based Disconnect" is a rule that can be set to allow a phone call to disconnect any other call. For example, a person could set priority-based interrupts to receive notifications for all calls from a child's school, even in the middle of a meeting, overriding the "do not disturb" rule.

Figure 30 shows (via the arrows marked below) the sequence of events associated with an auto-conference call phone synchronization scheme, according to one embodiment of the present invention. This approach requires the IP phone 101 to be synchronized with a TADS enabled personal computer or workgroup server 108 based calendar application. It is also necessary to run the small calendar based application 3002 on the IP phone 101 . User 1801 schedules a meeting via the TADS server 108 calendar application (arrow 3005). The calendar application then creates a conference call conference profile and sends the profile to the TA distribution engine 1413 (arrow 3006). This configuration file will contain contact information (eg, phone numbers) for all meeting participants, as well as other meeting related attributes, such as the set of instructions to follow based on configuration file activation. TA distribution engine 1413 sends the configuration file to TA distribution engine 1413 (arrow 3006), which in turn sends the configuration file to Phone A calendar application 3002 (arrow 3007), which then saves the configuration file to the installed applications database 1302 (arrow 3008) and will assign an ID to the profile. Conference profiles are considered by the TA as they will be executed by the TA execution engine 1411 at specific times. During a conference call conference, the IP phone 101 will load this configuration file and invoke the TA execution engine 1411 in order to execute the configuration file (arrow 2809). Once the IP Phone 101 starts executing the configuration file, the TA Execution Engine 1411 will instruct the IP Phone 101 to make a conference call to the involved participants (arrow 3010). At this point, phone A 101 proceeds to request phone B 116 and phone C 117 to join the conference.

The auto-conference call subscription method requires the installation of a plug-in application on a TADS-enabled personal computer or workgroup server 108 based calendar application. This plug-in will have access to user profiles through the user management module 1409 , where the user profiles will be stored on the customer database 108 . As previously defined, a user profile will be used to determine call handling preferences for that user. Once the client IP phone 101 subscribes, the configuration file will be sent by utilizing the TA distribution engine 1413 . This plugin will also be responsible for sending a Notify message to the VoIP phone 101 at the moment the conference is started. This notification message contains a new "auto-meeting" XML dialog that includes all URIs or contact information for meeting participants. New call control functionality will be added to the IP phone 101 which will use these notification messages and based on parsing the contents of this XML dialog will generate (host) a conference to the conference participants.

Figure 31 shows (via the arrows marked below) the sequence of events associated with an auto-conference call subscription scheme, according to one embodiment of the present invention. Phone 101 schedules a meeting via client PC 112 using a calendar application resident on TADS server 108 (arrow 3102). Phone A 101 registers with SIP server 109 (arrow 3103) and subscribes to the auto-conference service via the calendar application on TADS server 108 (arrow 3104). TADS server 108 sends the corresponding subscriber profile to phone A 101 (arrow 3105). While the conference call is conferencing, the TADS server 108 notifies phone A 101 that a new conference call should be established (arrow 3106). Phone A 101 sends an INVITE message to establish communication with phone B 116 via SIP server 109 (arrow 3107), which then forwards the INVITE to phone B 116 (arrow 3108). Phone A 101 sends an invitation message to establish communication with phone C 117 via SIP server 109 (arrow 3109), which then forwards the invitation message to phone B 116 (arrow 3110).

Figure 32 shows (via the arrows indicated below) the sequence of events associated with an auto-conference call phone subscription scheme, according to one embodiment of the invention. Phone A 101 schedules a meeting using a calendar application resident on TADS server 108 (arrow 3201). The TADS server 108 stores the profile on the customer's database 1408 and assigns an ID to the profile (arrow 3202). This configuration file will contain contact information (eg, phone numbers) for all conference participants as well as SIP multi-conference unit information. This configuration file contains the set of instructions that activation based on the configuration file will obey. At the time of the conference call, the calendar application resident on the TADS server 108 requests a configuration file from the customer's database 1408 (arrow 3203), receives the configuration file (arrow 3204) and sends the configuration file to the TA distribution engine 1413 (arrow 3205), wherein the TA Distribution Engine 1413 sends a signal to the TADS-based SIP MCU 109 (SIP Multi-Conference Unit) that a conference call should be started (arrow 3206). The TADS-based SIP MCU 109 invites phone A 101 (arrow 3207), invites phone B 116 (arrow 3208), and invites phone C 117 (arrow 3209) to participate in the conference call. The advantage of this approach is that it is centralized from the perspective of the TADS server 108, whereby the number of conference participants is not limited by telephone. This approach requires that the calendar-based application is running on the server and that the server is configured with information for the SIP multi-conference unit.

Services enabled by one embodiment of the present invention are discussed below in conjunction with FIGS. 33-34 , where the present invention pertains to the development of an enhanced usage control method that accommodates the TADS building blocks discussed in FIGS. 14-15 and software platform 500 (FIG. 5) to facilitate control of IP telephony use via user profiles that specify allowed and disallowed data and call transactions.

The enhanced method is based on the configuration files used in the phone combined with the information in the TADS server 108 (customer database 1408). Administrators of TADS-enabled devices can create rules for what content and calls can be sent and received on the phone. "Content" refers to the content and applications served by TADS. A call-related configuration file may include a list of phones that are allowed to call, numbers that will be received, numbers that will be barred from calling, and numbers that will be barred from receiving. Profiles associated with data may include content that is allowed to be received, information sites that are allowed to be accessed, information that is prohibited from being received, and information sites that are prohibited from being accessed. These values are stored in the customer database associated with the TADS server 108, and may be associated with the distribution schedule 1410 (in cases where content/calls to be allowed/not allowed vary throughout the day). The configuration files will be managed via the configuration file information front-end console 1201 or other tool management provided using the TADS programming API 1403 to make entering or editing this information simple so that the end user does not have to understand the actual value of the values of these configuration files Format. For example, you can display a country, state, or world map and let the user decide which area codes/city codes/country codes are allowed or not. Front end users may be provided with the ability to check call/application logs to ADD and REMOVE directly to the appropriate listed numbers or applications. Lists can be added to "group" profiles (distribution groups) so that they can be easily assigned to multiple phones. For example, you can define a "build 1 phone" group that cannot call anywhere in Europe, but a "build 2 phone" group can. Other options are available to create distribution groups associated with all calls from one person. For example, User A may want to avoid calls from User B no matter where User B is. User A can create a profile that includes User B's home phone, cell phone, and business phone, and User B's TADS-enabled computer system and personal digital assistant (PDA). In this configuration file, User A adds User B's phone number to a list of prohibited phone numbers and adds User B's IM ID name to a list of prohibited contacts. Permitted and prohibited information can alternatively be stored on external media that can be moved with the individual if desired. For example, a USB driver could be used to store this information, and when connected to a TADS capable device, the USB driver could add these rules. Allowed and prohibited information may alternatively be sent directly from a TADS-enabled device to another TADS-enabled device (eg, by sending email between two TADS-enabled computers). Phones and groups of phones (distribution groups) can be associated with specific instructions as to what to control and when to control. These lists are also associated with "schedules" so that the numbers allowed to call/receive (or data/application access) can be different at different times of the day. Some examples of how administrators can control usage include: Parents determine that specific phones should not be called after 10 p.m.; Employers can create "do not call" lists to prevent specific numbers from being called (e.g., 976 numbers, long distance calls, etc.); Parents can block TADS server games and content from their kids' phones from 6p.m to 6a.m; and employers can block employees' access to some TADS content that may not be appropriate for their company.

Figure 33 shows (via the arrows indicated below) a sequence of events associated with a usage control method related to a content distribution scheme, according to one embodiment of the invention. The user administrator logs into the TADS server 108 via the client PC 112 and edits preferences (configuration files) for all phones under a particular interest group (eg, "Family") (arrow 3301). TADS server 108 (using user management module 1409, group subscriber/non-subscriber module 1014, and content programming module 1406) stores profile preferences in customer database 1408 (arrow 3302). Phone A 101 and Phone B 116 are assigned to a distribution group using the group subscription management module 1414. Configuration files are stored in the consumer database 1408 with possible associations made in the distribution group schedule 1410 for rules that only apply at certain times. When phone A 101 initiates a request for content (arrow 3303), TADS server 108 accesses profile information from customer database 1408 to determine if this is an allowed transaction (arrow 3304). The customer database 1408 returns profile information (arrow 3305). If requests for the content are allowed, the TADS server 108 sends the content to Phone A 101 (arrow 3306). When Phone B 116 initiates a request for content (arrow 3307), TADS server 108 accesses profile information from customer database 1408 to determine if this is an allowed transaction (arrow 3308). The customer database 1408 returns profile information (arrow 3309). If the request for content is prohibited, the TADS server 108 sends an error message to Phone B 116 (arrow 3311).

Figure 34 shows (via the arrows marked below) a sequence of events associated with a usage control method in relation to a call control scheme, according to one embodiment of the invention. The user administrator logs into the TADS server 108 via the client PC 112 and edits preferences (configuration files) for all phones under a particular interest group (eg, "Family") (arrow 3401). TADS server 108 (using user management module 1409, group subscriber/non-subscriber module 1414, and content programming module 1406) stores profile preferences in customer database 1408 (arrow 3402). Phone A 101 and Phone B 116 are assigned to a distribution group using the group subscription management module 1414. Configuration files are stored in the consumer database 1408 with possible associations made in the distribution group schedule 1410 for rules that only apply at certain times. When phone A 101 initiates a request for a call to phone B (arrow 3403), TADS server 108 accesses profile information from customer database 1408 to determine if this is an allowed transaction (arrow 3404). The customer database 1408 returns profile information (arrow 3405). If the request for the call is allowed, the TADS server 108 sends a call message to Phone A 101 (arrow 3406). Phone A 101 then invites phone B 116 for the call (peer-to-peer scenario) (arrow 3407). If the configuration file indicates that phone B 116 cannot be called from phone A 101, then TADS server 108 will return a forbidden call message to phone A 101 (arrow 3408).

The services enabled by the present invention are discussed in conjunction with FIG. 35, where the invention pertains to the development of an enhanced user experience approach that accommodates the TADS building blocks and software platform 500 discussed in FIGS. 14-15 (FIG. 5) to facilitate content distribution and control over service calls.

TADS front-end tools 1201, content programming modules 1406, or third-party implementations using TADS-programmed API 12014033 can be used to generate content "packages" to be displayed in TADS-enabled devices. These packages can have all the information to display custom content and provide the user with controls that the user can use to access content that may not be locally stored on the TADS enabled device. Restaurants and content providers can create TADS-enabled applications 411 (FIG. 4) to assist consumers with various needs, such as check-in/check-out assistance and information, billing information, room service ordering, concierge access services, and the like. Through TADS-enabled applications, hotel rooms can obtain web-based feeds of news, sports, entertainment, financial and weather content for display directly to consumer rooms. This, combined with the potential to support user-specific TADS profiles, means users can have a wealth of information and services automatically delivered to their guest rooms. A restaurant's property management system (PMS) that stores information such as reservation information, check-ins and check-outs, prices, fee/billing information, guest profiles, alerts, etc. can be accessed to customize such content through the content programming module 1406 Send to phone. TADS transaction engine 1411 will have software for content handlers/converters (applications for converting information from external formats (e.g. PMS data, web offerings, other web sites) into data that can be sent and understood by TADS enabled devices) .

The TA execution engine 1403 in a client supporting TADS will use these packets to display content and respond to user events. The content programming module 1406 may be used in conjunction with a hotel's property management system (PMS) to schedule and display targeted content for guest rooms in the restaurant. Packages may be assigned to room distribution groups by using the group subscription management module 1414. Multiple rooms can be associated with different distribution groups. This can allow a hotel to have independent "packages" that can be assigned to different "groups" of guest rooms. Packages can be reused. For example, the same package can be sent to different restaurants in the same chain, shared among restaurants in multiple chains, or even sold in a shrink-wrapped version so that smaller restaurants can use it as a pre-packaged solution.

If the guest has a TADS enabled profile (an entry in the TADS customer database 1208), then using the TA distribution engine 1413 as well as the product distribution engine 1415, they can choose to have their TADS enabled content added directly to their hotel room . This allows guests to access their preferred content in addition to the restaurant's recommended content, thereby enhancing their experience. This would require that the restaurant has allowed external access to the customer's TADS server, or that the customer has provided the information via the USB drive 214 (FIG. 2).

Figure 35 is a flow diagram of a method 3500 of defining a user experience defined by content and distribution applications for a TADS enabled device in accordance with one embodiment of the invention. Referring to Figure 35, in step 3501, the content administrator 3607 identifies local and remote content and applications for distribution packages. In step 3502, the content administrator 3607 defines distribution groups and associated packages. In step 3503, the system administrator 3607 distributes the package.

It is noted that method 3500 may include other and/or additional steps, not shown for clarity. Note further that method 3500 may be performed in an order different than that presented, and that the order presented in the discussion of FIG. 35 is exemplary. It is further noted that certain steps in method 3500 may be performed in a substantially simultaneous manner.

Figure 36 shows (via the arrows marked below) the sequence of events associated with distributing content to a phone. Content administrator 3607 creates content via TADS front-end console 1201 or third-party console 1419 (arrow 3601 ), stores content on database repository 111 (arrow 3602 ), and assigns profiles via group subscriber/non-subscriber module 1414 To phone group (arrow 3603). The group subscriber/non-subscriber module 1414 reads the new content ID from the database repository 111 (arrow 3603) and assigns the content ID to the phone group (arrow 3604). When phone A 101 requests content associated with its ID (arrow 3605), TA distribution engine 109 will return corresponding content (arrow 3606).

Figure 37 shows (via the arrows marked below) the sequence of events associated with updating existing content, according to one embodiment of the invention. User A 3607 updates content (arrow 3701) via TADS front-end console 1201 or third-party console 1419, and stores it on the database warehouse 111 (arrow 3702), and generates a message to the TA distribution engine 109 from the database warehouse 111 to Notify of new content (arrow 3703). The TA distribution engine 109 then sends an update notification to Phone A 101 (arrow 3750). Updated content is then exchanged between the TA Distribution Engine 109 and Phone A 101 via Content Request (arrow 3705) and Content Return (arrow 3706).

Figure 38 shows (via the arrows indicated below) the sequence of events associated with processing a local content request, according to one embodiment of the invention. The phone requests local content from the TADS server 108 for its profile (arrow 3801). The TADS server 108 looks up the cached content on the local time store 111 (arrow 3802), and sends the content to Phone A 101 via the TADS server 108 (arrow 3803) (arrow 3804).

Figure 39 shows (via the arrows marked below) the sequence of events associated with processing an external content request, according to one embodiment of the invention. Phone A 101 sends a request to the TADS server 108 for external content (arrow 3901). The TADS server 108 first looks up a cached copy of the requested content in local storage (arrow 3902). If there is a cached copy, the sequence will be exactly as described in Figure 38. If there is no cached copy, the TADS server 108 will receive an "Error - Not Found" message (arrow 3903). The TADS server 108 will then request the external content via the data network 102 via the external content (3904). Once the TADS server 108 receives the requested external content (arrow 3905), the TADS server 108 will perform reformatting of the content for Phone A 101 supporting the TADS device and store a cached copy in the database repository 111 (arrow 3906), And the formatted content is returned to phone A 101 (arrow 3907).

Figure 40 shows (via the arrows marked below) the sequence of events associated with handling PMS interactions in a service setup, according to one embodiment of the invention. Phone A 101 sends a request (arrow 4001) for PMS information (e.g., billing information) to the TADS server 108 (arrow 4002) via the PMS interface provided by the TA execution module 1503. The TADS server 108 looks up the cached content on the local database repository (arrow 4003). If there is a cached copy, the sequence will be exactly as described in Figure 38. If there is no cached copy, TADS server 108 will receive an "Error - Not Found" message (arrow 4004). The TADS server 108 will then request the external content from the PMS system via the data network 102 (arrow 4005). Once the TADS server 108 receives the requested external content (arrow 4006), the TADS server 108 will perform reformatting of the content for Phone A 101 supporting the TADS device and store a cached copy in the database repository 111 (arrow 4007), And the formatted content is returned to phone A 101 (arrow 4009) via the PMS interface (arrow 4008) provided by the TA execution module 1303.

Figure 41 shows (via the arrow as marked with ) the PMS associated with the service settings when a request for PMS information update (e.g., to update the guest name in the room) Sequence of events in Handling PMS interactions. The PMS system makes a request to the TADS server 108 via the data network 102 to update the PMS information associated with phone A 101 (arrow 4101). The TADS server 108 converts the PMS-related content into a form suitable for the phone A 101, and stores the information on the database warehouse 111 (arrow 4102), and sends the updated and formatted PMS interface to the PMS interface provided by the TA execution module 1503 Information (arrow 4103), the PMS interface then sends the content for display to Phone A 101 (arrow 4104).

One embodiment of the present invention is a framework for software module deployment, update and configuration (see Figure 11). A transaction application (TA) can be considered a software module. Such a framework would be hosted by the application and TADS server 108 and would work in conjunction with the deployment and configuration services on the IP phone 101 to keep the individual software modules up to date and properly configured. Deployment and configuration services are part of other services 502 . Software deployment to IP phones 101 may be based on demographic data taken from demographics module 1007 or from selection of groups of IP phones 101 by a maintenance technician. Once the phone is selected as a software deployment candidate, communication is initiated between the TADS server 1000 and the IP phone 101 to complete the deployment, update, and/or configuration operations. Communication is based on HTTP messages containing XML data in their bodies. The format of this data is part of the TADS protocol suite 1000 (discussed below in connection with FIG. 10).

FIG. 42 presents the exchange of messages between the TADS server 108 and the IP phone 101 during a software deployment and update operation 420 . An optional DEPLOY message 4201 may be sent by the application and the TADS server 108 to trigger manipulation. The IP phone will respond with an OK message 4202. The IP phone 101 will send a REQUEST_INFO message 4203 to the application and TADS server 108 to initiate the deployment and update process. This message includes information about the current versions of hardware and software (each module) available for the software modules on IP phone 101 and module interdependencies for use in determining what modules can be updated.

The application and TADS server will respond with a RESPONSE_DEPLOY_INFO message 4204 to indicate any available updates for the individual software modules and dependencies with other modules. An example of the content of this message is as follows: FTP messages 4205, 4206, 4207, and 4208 may be exchanged using multiple FTP sessions established by the application and TADS server 108 or vendor server 118 to download individual software modules to IP phone 101. Optionally, messages SEND_DATA 4209 and START_UPDATE 4210 may be exchanged between the application and TADS server 108 and IP phone 101 to backup configuration data.

FIG. 43 presents the message exchange between the application and the TADS server 108 and the IP phone 101 during the software configuration operation 4300 . The application and TADS server 108 can optionally send a CONFIGURE message 4301 to trigger the configuration process. The IP phone 101 will send an OK message 4302 in response to this CONFIGURE message 4301 . The IP phone will then send a REQUEST_INFO message 4303 to the application and TADS server 108 requesting configuration information. The application and TADS server 108 will respond with a RESPONSE_CONFIGURE_INFO message 4304 containing any new or different configuration information for the individual software modules.

Although the present method, computer program product and system have been described in connection with several embodiments, it is not intended to be limited to the particular form described herein, but rather is intended to cover the spirit and scope of the invention as defined by the appended claims such substitutions, modifications and equivalents as are reasonably included herein.

Claims (38)

1. one kind is used for method that the telephone number of not relating to the recipient who wants that the user transferred to of Internet Protocol (IP) phone is discerned, and described method comprises step:

Send error message by server to described IP phone, the telephone number of failing to connect that this error message indicates the described user of described IP phone to transfer to;

Receive alert message from described IP phone, the recipient's who wants telephone number is not related in this alert message indication;

Increase is at the fail count of the described telephone number of not relating to the described recipient who wants; And

If described fail count surpasses threshold value, then the described telephone number of not relating to the described recipient who wants is carried out mark.

2. method according to claim 1 further comprises step:

Show the indication of the call of failure by described IP phone; And

Triggering will be to the described alert message of described server transmission.

3. method according to claim 1 further comprises step:

Initiate investigation and surpass described threshold value why with the described fail count of determining to be associated with the described telephone number of not relating to the described recipient who wants.

4. method according to claim 1, wherein said alert message is automatically produced in response to receiving described error message by described IP phone.

5. one kind is used for the method discerned by the directory search of the contact of the performed failure of the user of Internet Protocol (IP) phone, and described method comprises step:

Send error message by server to described IP phone, this error message indication is by the directory search of failing to discern the described contact that has telephone number of described user's execution of described IP phone;

Receive alert message from described IP phone, this alert message is indicated incorrect figure;

Increase is at the fail count of the contact of described search; And

If described fail count surpasses threshold value, then described directory search is carried out mark.

6. computer program, described computer program is included in the machine readable media, be used for being discerned by the telephone number of not relating to the recipient who wants that the user transferred to of Internet Protocol (IP) phone, described computer program comprises following programming step:

Send error message to described IP phone, this error message is indicated the telephone number of failing to connect that described user transferred to of described IP phone;

Receive alert message from described IP phone, the recipient's who wants telephone number is not related in this alert message indication;

Increase is at the fail count of the described telephone number of not relating to the described recipient who wants; And

If described fail count surpasses threshold value, then the described telephone number of not relating to the described recipient who wants is carried out mark.

7. computer program according to claim 6, wherein said alert message is automatically produced in response to receiving described error message by described IP phone.

8. computer program, described computer program is included in the machine readable media, be used for being discerned by the directory search of the contact of the performed failure of the user of Internet Protocol (IP) phone, described computer program comprises following programming step:

Send error message to described IP phone, the directory search of the described contact that has telephone number is discerned in this error message indication by performed the failing of described user of described IP phone;

Receive alert message from described IP phone, this alert message is indicated incorrect figure;

Increase is at the fail count of the contact of described search; And

If described fail count surpasses threshold value, then described directory search is carried out mark.

9. system comprises:

Be applicable to the memory cell of storage computation machine program, described computer program is applicable to being discerned by the telephone number of not relating to the recipient who wants that the user transferred to of Internet Protocol (IP) phone; And

Be coupled to the processor of described memory cell, wherein said processor comprises in response to described computer program:

Be used for sending to described IP phone the circuit of error message, this error message is indicated the telephone number of failing to connect that described user transferred to of described IP phone;

Be used for receiving from described IP phone the circuit of alert message, the recipient's who wants telephone number is not related in this alert message indication;

Be used to increase circuit at the fail count of the described telephone number of not relating to the described recipient who wants; And

If be used for that described fail count surpasses threshold value then the circuit that the described telephone number of not relating to the described recipient who wants carried out mark.

10. system comprises:

Be applicable to the memory cell of storage computation machine program, described computer program is applicable to being discerned by the directory search of the contact of the performed failure of the user of Internet Protocol (IP) phone; And

Be coupled to the processor of described memory cell, wherein said processor comprises in response to described computer program:

Be used for sending to described IP phone the circuit of error message, this error message indication is by the directory search of failing to discern the described contact that has telephone number of described user's execution of described IP phone;

Be used for receiving from described IP phone the circuit of alert message, this alert message is indicated incorrect figure;

Be used to increase circuit at the fail count of the contact of described search; And

If be used for that described fail count surpasses threshold value then the circuit that described directory search carried out mark.

11. a method comprises step:

From first wake-up call of server reception to Internet Protocol (IP) phone;

If described first wake-up call confirmed by the user of described IP phone, then receive one or more prompting, caution, newspaper material and the information category tabulation from described server; And

If described first wake-up call is not confirmed by the described user of described IP phone, then after the fixed special time period of described user's configuration file document, receive second wake-up call.

12. method according to claim 11 further comprises step:

If described first wake-up call is labeled as wake-up call by described IP phone, described first wake-up call of automatic-answering back device then;

The contact second server is with the described user's that obtains described IP phone preference; And

Be connected to described second server to send audio frequency to described IP phone.

13. method according to claim 12 further comprises step:

If described user does not confirm described first wake-up call, then disconnect described first wake-up call.

14. method according to claim 11 further comprises step:

If described first wake-up call is labeled as wake-up call by described IP phone, then automatically reply described first wake-up call;

Play suitable jingle bell tone;

When described first wake-up call of described user answer, send the signal that described user has replied described first wake-up call to described server; And

Be connected to second server to send audio frequency to described IP phone.

15. method according to claim 11, described one or more in wherein said prompting, caution, newspaper material and the tabulation of described information category comprise the tabulation of present kind and at the master list of selling of each present kind of listing, wherein said method further comprises step:

Described user by described IP phone selects the seller from described tabulation;

Described user and described seller execution by described IP phone are ordered; And

Utilize the second server that is associated with described seller to deliver affairs.

16. method according to claim 11, the one or more entertainment event that comprise described in wherein said prompting, caution, newspaper material and the tabulation of described information category are tabulated, and wherein said method further comprises step:

Described user by described IP phone selects entertainment event from described tabulation;

Described user's execution by described IP phone is ordered; And

Utilize with the second server that entertainment event for described selection provides the seller of admission ticket to be associated and deliver affairs.

17. one kind is used for the gray method that contact shows, comprises step on Internet Protocol (IP) phone:

Be received in the advertisement on the webpage that shows on the described IP phone, the described advertisement on the wherein said webpage comprises the unified resource identifier (URI) of dialogue-based initiation protocol (SIP);

Select described advertisement;

By the web browser of described IP phone, will be passed to the application of described IP phone with the URI that the advertisement of described selection is associated; And

, the businessman that is associated with the advertisement of described selection produced call out based on the described URI that is associated with selected described advertisement by the described application of described IP phone.

18. a method that is used for producing from Internet Protocol (IP) phone Conference Calling comprises step:

In response to arranging meeting, create the Conference Calling meeting configuration file that comprises contact details for all meeting participants;

First phone application to described IP phone sends described Conference Calling meeting configuration file, and wherein said first phone application is configured to first user's who keeps described IP phone calendar;

Carry out described Conference Calling meeting configuration file; And

Indicate described IP phone so that the described meeting participant who discerns in the described configuration file is produced Conference Calling.

19. method according to claim 18 further comprises step:

Allocation identification is given described configuration file, allows the user to have the configuration file of a plurality of definition thus and can select among them.

20. a method that is used for producing from Internet Protocol (IP) phone Conference Calling comprises step:

User by described IP phone is that the meeting participant who discerns arranges meeting;

Receive the configuration file of storage at the meeting participant's of described identification contact details;

Reception should be set up the notice of Conference Calling; And

Send invitation message to each of the meeting participant of described identification, communicate by letter to set up with described IP phone.

21. one kind is used for setting up the method for Conference Calling with Internet Protocol (IP) phone, comprises step:

To comprise at the Conference Calling meeting configuration file of all meeting participants' contact details and store, wherein said Conference Calling meeting configuration file comprises instruction set, after described Conference Calling meeting configuration file is activated, will follow this instruction set;

Receive the Conference Calling that indication is associated with described Conference Calling meeting configuration file with beginning;

Activate described Conference Calling meeting configuration file; And

Each of inviting described meeting participant communicated by letter to set up with described IP phone.

22. one kind is used for the method for content distribution that control commutes Internet Protocol (IP) phone, comprises step:

The configuration file preference of configuration file is stored in the database, the described configuration file preference of wherein said configuration file comprises rule, and these rules are to receive which call and content and forbid that the described user of described IP phone receives which call and content about the user who allows described IP phone;

Described configuration file is associated with timetable, and wherein said timetable makes the different time in a day to receive and forbids different calls and content;

The request that receives is to send to content the described user of described IP phone; And

Based on the described configuration file preference of described configuration file, determine whether to allow the described user of described IP phone to receive described content.

23. method according to claim 22 further comprises step:

If forbid described user's received content of described IP phone, then send error message so that send described content to the described user of described IP phone to the sender of described request.

24. method according to claim 23 further comprises step:

The described user of described sender and described IP phone is assigned to distribution group.

25. one kind is used for the method for content distribution that control commutes Internet Protocol (IP) phone, comprises step:

The configuration file preference of configuration file is stored in the database, the described configuration file preference of wherein said configuration file comprises rule, and these rules are to receive which call and content and forbid that described first user of described IP phone receives which call and content about first user who allows IP phone;

Described configuration file is associated with timetable, and wherein said timetable makes the different time in a day to receive and forbids different calls and content;

Receive request so that be connected to described first user of described IP phone by phone by second user; And

Based on the described configuration file preference of described configuration file, determine whether to allow described first user of described IP phone to be connected to described second user by phone.

26. method according to claim 25 further comprises step:

If described first user of described IP phone forbids being connected by phone with described second user, then send message to described second user, indicate described first user of described IP phone to forbid being connected by phone with described second user.

27. method according to claim 27 further comprises step:

Described second user and described first user are assigned to distribution group.

28. a method that is used for the user from the content of restaurant's visit on Internet Protocol (IP) phone may further comprise the steps:

Generation will be on described IP phone the content displayed bag, wherein said content bag comprises the content of customization, wherein said content bag comprises following one or more: go into shop/departure auxiliary and information, accounting information, housekeeping service order and gatekeeper's information on services;

Described content bag is sent to described IP phone; And

The content of the content bag of control to visit described generation is provided to the user of described IP phone.

29. method according to claim 28, wherein said restaurant comprises the system that is configured to customize described content bag.

30. method according to claim 28, wherein said content bag further comprise following one or more: the content of information and the content of amusement.

31. a method that is used to support the management that catalogue is upgraded comprises step:

In response to the seller carry out to the contact details that are associated with interested telephone wire upgrade, correct and be provided with in one or more affirmation codes that produce;

Described affirmation code is sent to described seller's e-mail address together with the telephone number of calling out;

Produce one or more in Email and the fax; And

Described one or more in described Email and the described fax are sent to described seller, indicate described telephone wire contact details successfully to upgrade.

32. a method that is used for content is distributed to Internet Protocol (IP) phone comprises step:

The content stores that to be created by the keeper is to data warehouse;

Configuration file is distributed to telephone set;

Distribute to described telephone set from described data warehouse reading of content sign and with described content identification of reading; And

Return content corresponding to the sign of request.

33. method according to claim 32 further comprises step:

With the content stores upgraded in described data warehouse;

The message of the content of described renewal is notified in generation;

The message of described generation is sent to IP phone; And

The content of described renewal is sent to described IP phone.

34. method according to claim 32 further comprises step:

Receive at local requests for content from IP phone;

The local content of search described request in described data warehouse; And

The local content of described request is sent to described IP phone.

35. method according to claim 32 further comprises step:

From the request of IP phone reception at exterior content;

Exterior content via data network request described request;

Receive the exterior content of described request;

The exterior content of the request of the described reception of reformatting;

The copy of the exterior content of the request of described reformatting is stored in the described data warehouse; And

The exterior content of the request of described reformatting is sent to described IP phone.

36. according to right 33 described methods, the method that wherein is used for content is distributed to IP phone appears at service environment.

37. according to right 34 described methods, the method that wherein is used for content is distributed to IP phone appears at service environment.

38. according to right 35 described methods, the described method that wherein is used for content is distributed to IP phone appears at service environment.

Images