AU777728B2

AU777728B2 - Distributed communications network including one or more telephony communication devices having programmable functionality

Info

Publication number: AU777728B2
Application number: AU15753/01A
Authority: AU
Inventors: James A. Batson Jr.; Daniel G. Petrie; Richard W. Schaaf
Original assignee: Pingtel Corp
Current assignee: Pingtel Corp
Priority date: 1999-10-26
Filing date: 2000-10-26
Publication date: 2004-10-28
Anticipated expiration: 2020-10-26
Also published as: JP2003527786A; AU1575301A; CN1399839A; WO2001031900A3; CA2389089A1; WO2001031900A2; SG129290A1; KR20020064889A; EP1287667A2

Description

WO 01/31900 PCT/US00/29576 -1- DISTRIBUTED COMMUNICATIONS NETWORK INCLUDING ONE OR MORE TELEPHONY COMMUNICATION DEVICES HAVING PROGRAMMABLE FUNCTIONALITY RELATED APPLICATION This application claims priority under 35 U.S.C. §119(e) to commonly-owned, copending U.S. provisional patent applications serial no. 60/161,144, entitled, "Communications Network Using Intelligent Telephones", filed October 26, 1999, and serial no. 60/190,613, entitled, "Method and Apparatus for Organizing Configuration Information for a C6mmunications System" filed March 20, 2000, which both are incorporated herein by reference in their entities.

FIELD

This application is directed to a communications network having intelligent end points for placing telephone calls. In particular, this application relates to a data network including one or more telephony communication devices that provide and control one or more telephony applications.

BACKGROUND

For a typical telephony communications network, including wireless and wirebased networks, the endpoints of such a network are telephony communication devices such as a telephone or a telephony-enabled computer.

A telephony communication device as used herein is a device capable of performing at least the following traditional telephony tasks: initiating the setting up of a telephone call by sending a signal onto a transmission medium of a communications network, detecting and indicating ringing, beeping or blinking a light) that a telephone call is incoming, determining that a user has responded to a phone call off-hook detection, a keypad entry, a keyboard entry or a mouse click), sending a signal indicating that the user has responded onto the transmission medium, receiving dialing instructions from a user from a rotary dial, push buttons, voice activation, keyboard or mouse), sending a signal representing the dialing instructions on to the transmission medium, transmitting and receiving acoustic audio signals to WO 01/31900 PCT/USOO/29576 -2and from, respectively, a user, and transmitting and receiving media audio data) on to the transmission medium of the network.

As used herein, a "telephony function" is a function performed in association with a telephone call. A "telephony application" is an application that performs one or more telephony functions. Telephony functions may be divided into two categories: core telephony functions and feature telephony functions. Core telephony functions may be divided into three categories: phone set management, call control and media processing.

As used herein, "phone set management" refers to the control of low-level device interactions on a telephony communication device such as, for example, button presses, hook switch operations and lamp or light emitting diode (LED) operations.

As used herein, "media processing" refers to the transmitting and receiving of media between a user of a telephony communication device and a transmission medium of a network on which the telephony communication device resides.

As used herein, "call control" refers to the controlling of setting up, maintaining and tearing down a telephone call. For a traditional telephony communication device, controlling a telephone call typically involves the use of a single call control protocol including peer-to-peer-type protocols such as, for example, the Sessions Initiation Protocol (SIP) or the H.323 protocol, or a master/slave-type protocol such as, for example, the Media Gateway Control Protocol (MGCP), the Megaco/H.248 protocol, or the Skinny Station protocol promulgated by Cisco Systems, Inc.

The SIP protocol is defined in RFC 2543, SIP: Session Initiation Protocol by Internet Engineering Task Force (IETF) as of October 26, 1999. The H.323 protocol is described by the International Telecommunications Union in the ITU-TN Recommendation: H.323 Packet-Based Multi-Media Communications System, Geneva, Switzerland, February, 1998. The Megaco/H.248 protocol is defined by IETF RFC 2885 and ITU H.248. The MGCP protocol is described in RFC 2705 as of October 1999.

As used herein, a "feature telephony function" is a function performed in association with a telephone call, beyond or in enhancement of the core telephony functions provided by phone set management, media processing and call control. For example, traditional telephony feature functions include placing a call on hold, call forwarding, voice mail functions, call waiting, conference calling, etc... As referred to WO 01/31900 PCTIUSOO/29576 -3herein, a "feature telephony application" is an application that performs one or more feature telephony functions.

Performing core telephony functions and feature telephony applications requires processing resources. In traditional telephony communications networks such as, for example, Public Switched Telephone Networks (PSTN), Private Branch Exchanges (PBX), or Central Office Exchange Services (Centrex), telephony communication devices rely on a server, switch, or other centralized processing entities as the processing resource to control and perform the bulk of the telephony functions associated with a telephone call. Thus, traditional telephony communications networks typically have centralized processing resources.

In typical traditional communications networks, to perform telephony functions, a telephony communication device receives instructions from one or more network resources such as a server or central switch, and operates based on those instructions.

Typically, the network resource maintains state information associated with the telephony functions and decides how to respond to events associated with the functions.

Traditional communications networks include analog lines for transmitting analog data, digital lines for transmitting digital data, or a combination of both analog and digital lines. Further, some of these networks may include high-speed backbone segments, for example, a backbone segment comprising a fiber optic cable.

Further, traditional communications networks may include any of a variety of telephones including telephones that include analog logic for performing telephony functions, digital logic for performing telephony functions or a combination of analog and digital logic.

For a telephone connected to a digital line, the telephone must include logic for converting acoustic audio signals into digital audio data. As used herein, a "digital telephony communication device" is a telephony communication device that, in addition to the telephony tasks described above, converts acoustic audio signals into digital audio data, and transmits digital data, including digital audio data, onto a data line.

More recently, communications networks have begun using data networks to transmit voice data Voice-over-IP data) and other data between a caller and one or more recipients. Such data networks include Local Area Networks (LANs), Metropolitan Area Networks (MANs) and Wide Area Networks (WANs) such as the Suz-4-Zuuz US0029576 -4- Internet. Typically, these data networks are designed to transmit data in accordance with the Internet ProtoEol (IP).

During a telephone call across one or more data networks, digital audio data from a digital telephony communication device on a data network may be transmitted to another digital telephony communication device on the data network, or to gateways between the data network and other communications networks.

Data networks typically are more distributed less centralized) than traditional telephony communications networks, relying on one or more servers or other network resources for processing as opposed to a central switch.

In data networks, one or more telephony functions and/or applications may be made available on a digital telephony communication device through hardware, sometimes in combination with software and/or firmware. Typically, after initial deployment installation) of the communication device in the field, at a customer's premises, the available telephony functions are essentially fixed in nature.

Sometimes, one or more of the telephony functions include one or more user-definable parameters that allow a user to define values, and thus have a limited role in programming the telephony communication device. For example, user-definable parameters may include the type or volume of a ring, a user password, numbers to be dialed automatically at the press of a single button, etc. The telephony functions themselves, however, are "closed" inaccessible) to a user of the telephony communication device and third party vendors such that the definition of the telephony functions may not be modified by the user or third party vendors.

Typically, to change a telephony function on an installed digital telephony communication device, the vendor that controlled development of the telephony functions must provide new hardware or software, or upgrade the existing hardware or software. Further, additional telephony applications may not be added to a telephony communication device after the telephony communication device has been installed in the field.

The telephony capabilities of typical telephony communication devices are limited in several ways. First, many telephony communication devices today are not capable of controlling telephone calls in which they participate, and those devices that are capable of controlling a telephone call some digital phones) are capable of AMENDED SHEET WO 01/31900 PCT/US00/29576 controlling the telephone call using only a single call control protocol, for example, SIP or H.323.

Second, many telephony communication devices perform telephony operations in response to instructions received from external communications network resources upon which telephony applications are being executed. Further, for those telephony communication devices upon which telephony applications are defined and upon which the telephony applications may be executed, after these telephony communication devices have been initially deployed in the field, no further telephony applications may be added to the telephony communication device.

Also, for such telephony communication devices, after these telephony communication devices have been deployed in the field, the telephony applications are closed to users and third party vendors such that the telephony applications are essentially fixed in nature, they may not be modified by users and third party vendors.

The telephony capabilities of typical communications networks also arc limited in several ways, due in part to the limitations of the telephony communication devices that reside on these communication networks.

First, the processing resources of many communications networks are highly centralized such that relatively few network resources provide telephony functionality for the entire communications network. Second, even for those communication networks that are more distributed and include one or more telephony communication devices that have telephony applications defined thereon and have the capability to execute such telephony applications, after a telephony communication device has been initially deployed, its telephony applications are not modifiable by a user or a third party vendor and additional telephony applications may not be added to the telephony communication device.

Consequently, the telephony functionality of a traditional communications network is limited either by the telephony functionality provided by a centralized network resource or the fixed telephony functionality available on the telephony communication devices of the network. These limitations impair the flexibility of a network user to expand or modify the telephony functionality of the user's telephony communication device, thereby limiting the scalability and flexibility of the communications network.

P.%OPER~K,2S3166 p.I.d- 2 7 /08/04 -6-

SUMMARY

According to the present invention, there is provided a telephony communication device that is part of a communications network that comprises a transmission medium, the telephony communication device comprising a call processing module adapted for representing and controlling at least a first telephone call that includes one or more connections to other users, each user corresponding to another telephony communication device on the communications network, the telephony communication device characterized in that: for at least a first of the one or more connections, the call processing module is adapted for selecting a first call protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like available on the first telephony communication device, and adapted for controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol.

The invention also provides a method of controlling one or more telephone calls on a telephony communication device connected to a communications network, a first telephone call including one or more connections to other users, each user corresponding to another telephony communication device on the communications network, the method characterized in that it comprises, for at least a first of the one or more connections, acts of: S 20 selecting a first call control protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like available on the telephony *communication device; and i controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol.

The invention also provides a computer program for controlling a first telephone call on a telephony communication device connected to a communications network, the telephone call including one or more connections to other users, each user corresponding to another telephony communication device on the communications network, the computer program including computer-readable signals tangibly embodied on a computer-readable medium that define a method characterized in that it comprises, for at least a first of the one or more connections, acts of: selecting a first call control protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like available on the first telephony communication device; and controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol.

P: OPER\KL\2531668 V l dx-27/O4 6a Embodiments of the invention provide a telephony communication device having an open telephony system architecture such that one or more telephony applications defined on the telephony communication device may be modified, after initial deployment in the field on a customer premise), independently of a vendor that controlled development of the one or more telephony applications.

Embodiments of the invention provide a telephony communication device having an extensible telephony system architecture such that the telephony functionality defined thereon can be expanded by adding telephony applications to the telephony communication device.

Embodiments of the invention provide a telephony communication device capable of controlling a connection during a telephone call using any of a plurality of call control protocols, including SIP, H. 323, MGCP, Megaco/H. 248, and the Skinny Station protocol.

Further, for a telephone call involving multiple connections, for example, a conference call, the telephony communication device can control communications on each connection concurrently and can use a different call control protocol for each connection.

Embodiments of the invention provide a communications network including one or more telephony communication devices having one or more of the following properties: an open telephony system architecture, an extensible telephony system architecture; the S* capability to control a telephony call using any of a plurality of call control protocols.

20 Such a communications network has more flexible and scaleable telephony functionality S° than existing communication networks.

In a first embodiment, provided is a first telephony communication device that is part of a communications network that includes a transmission medium. The first telephony communication device includes a telephony hardware component and a telephony software component. The telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmission medium, and one or more inputs to transmit media to the first user and second data to the transmission medium. The telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. The telephony application is modifiable after the first telephony communication device is deployed on WO 01/31900 PCT/US00/29576 -7the communications network with modifications developed independently from creation of the telephony software component.

In another embodiment, a method of defining functionality for a telephony communication device is provided, where the telephony communication device is part of s a communications network that includes a transmission medium. The telephony communication device includes a telephony hardware component and a telephony software component. The telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmission medium, and includes one or more outputs to transmit media to the first user and second data to the l0 transmission medium. The telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. After the telephony communication device is deployed on the communications network, the telephony application is accessed on the telephony communication device, and modified with modifications developed independently from creation of the telephony software component.

This embodiment may be implemented as a computer program product that includes a computer-readable medium and computer-readable signals stored on the computer-readable medium that define instructions. These instructions, as a result of being executed by a computer, instruct the computer to perform the acts described above for this embodiment.

In yet another embodiment, provided is a system for defining functionality for telephony communication device that is part of a communications network that includes a transmission medium. The telephony communication device includes a telephony hardware component and a telephony software component. The telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmission medium, and includes one or more outputs to transmit media to the first user and second data to the transmission medium. The telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. The system includes means for accessing the telephony application on the telephony communication device after the telephony communication device is deployed on the communications network, and means for modifying the WO 01/31900 PCT/US00/29576 -8telephony application with modifications developed independently from creation of the telephony software component.

In another embodiment, a communication network is provided that includes a transmission medium and one or more telephony communication devices, where each telephony communication device comprises a telephony hardware component and a telephony software component. For each telephony communication device, the telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmission medium, and one or more outputs to transmit media to the first user and second data to the transmission medium. The to telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. The telephony application is modifiable after the telephony communication device is deployed on the communication network with modifications developed independently from creation of the telephony software component.

In another embodiment, provided is a first telephony communication device that is part of a communications network that includes a transmission medium, where the first telephony communication device includes a telephony hardware component and a telephony software component. The telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmissionmedium, and includes one or more outputs to transmit media to the first user and data to the transmission medium. The telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. At least part of an additional telephony application can be added to the telephony software component after the first telephony communication device is deployed on the communications network.

In yet another embodiment, functionality is defined for a telephony communication device that is part of a communication network that includes a transmission medium, where the telephony communication device includes a telephony hardware component and a telephony software component. The telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmission medium, and includes one or more outputs to transmit media WO 01/31900 PCT/US00/29576 -9to the first user and second data to the transmission medium. The telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. After the telephony communication device is deployed on the communication network, the telephony software component may be accessed on the telephony communication device, and at least a part of an additional telephony application may be added to the telephony software component.

This embodiment may be implemented as a computer program product that includes a computer-readable medium and computer-readable signals stored on the l0 computer-readable medium that define instructions. These instructions, as a result of being executed by a computer, instruct the computer to perform the acts described above for this embodiment.

In another embodiment, provided is a system for defining functionality for a telephony communication device that is part of a communications network that includes a transmission medium, where the telephony communication device includes a telephony hardware component and a telephony software component. The telephony hardware component includes one or more inputs to receive audio input from a first user and first data from the transmission medium, and includes one or more outputs to transmit media to the first user and second data to the transmission medium. The telephony software component controls operation of the hardware component and includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. This system includes means for accessing the telephony software component after the telephony communication device is deployed on the communications network, and means for adding at least a part of an additional telephony application to the telephony software component.

In another embodiment, a communications network is provided that includes a transmission medium and one or more telephony communication devices, where each telephony communication device includes a telephony hardware component and a telephony software component. For each telephony communication device, the telephony hardware component comprises one or more inputs to receive audio input from a first user and first data from the transmission medium, and includes one or more outputs to transmit media to the first user and second data to the transmission medium.

The telephony software component controls operation of the hardware component and WO 01/31900 PCT/US00/29576 includes at least a portion of a telephony application defining a telephony function to be performed in association with a telephone call. At least a part of an additional telephony application can be added to the telephony software component after the telephony communication device is deployed on the communications network.

In yet another embodiment, provided is a first telephony communication device that is part of a communication network that includes a transmission medium, where the telephony communication device includes a call processing module. The call processing module represents and controls at least a first telephone call that includes one or more connections to other users, where each user corresponds to another telephony communication device on the communications network. For at least a first of the one or more connections, the call processing modules operative to control communications on a telephony device corresponding to the first connection using a first call control protocol selectable from a plurality of call control protocols available on the first telephony communication device.

In another embodiment, a first telephone call is controlled on a first telephony communication device that is connected to a communications network. The telephone call includes one or more connections to other users, where each user corresponds to another telephony communication device on the communications network. For at least a first of the one or more communications, a first call control protocol is selected from a plurality of call control protocols available on the first telephony communication device, and communications on the telephony communication device corresponding to the first connection are controlled using the first call control protocol.

In another embodiment, provided is a system for controlling a first telephone call on a first telephony communication device connected to a communications network. The telephone call includes one or more connections to other users, where each user corresponds to another telephony communication device on the communications network. For at least a first of the one or more connections, the system includes means for selecting a first call control protocol from a plurality of call control protocols II WO 01/31900 PCTIUS00/29576 -1lavailable on the first telephony communication device, and means for controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol.

In yet another embodiment, a communications network is provided that includes s a transmission medium and one or more telephony communication devices, where each telephony communication device includes a call processing module. For each telephony communication device, the call processing module represents and controls at least a first telephone call that includes one or more connections to other users, where each user corresponds to another telephony communication device on the communications network. For at least a first of the one or more connections, the call processing module is operative to control communications corresponding to the first connection on the telephony communication device using a first call control protocol selectable from a plurality of call control protocols available on the first telephony communication device.

In another embodiment, a computer program product is provided that includes a computer-readable medium, and computer-readable signals stored on the computerreadable medium that define instructions that, as a result of being executed by a telephony communication device, instruct the telephony communication device to perform a telephony application. At least a portion of the telephony application may be added to the telephony communication device after the telephony communication device has been deployed on a communications network.

In another embodiment, a computer program product is provided that includes a computer-readable medium, and computer-readable signals stored on the computerreadable medium that define instructions that, as a result of being executed by a telephony communication device, instruct the telephony communication device to perform a telephony application. At least a portion of the telephony application may be modified on the telephony communication device after the telephony communication device has been deployed on a communications network with modifications developed independently from creation of the telephony application.

The features and advantages of the invention described above and other features and advantages of the invention will be more readily understood and appreciated from the detailed description below, which should be read together with the accompanying drawing figures.

WO 01/31900 PCT/US00/29576 -12- BRIEF DESCRIPTION OF THE DRAWINGS In the drawings, Fig 1. is a block diagram illustrating an example embodiment of an open and extensible telephony system architecture for a telephony communication device; Fig. 2 is a block diagram illustrating an example embodiment of a core telephony functionality layer of the open and extensible telephony system architecture of Fig. 1; Fig. 3 is a data flow diagram illustrating an example embodiment of a media processing component corresponding to the media processing module of Fig. 2; Fig. 4 is a block diagram illustrating example embodiments of the call processing module of Fig. 2 and the media processing module of Fig. 2; Fig. 5 is a diagram illustrating an example embodiment of a telephony communication device; Fig. 6 is a diagram illustrating an example embodiment of a graphical display provided by a telephony communication device; Fig. 7 is a block diagram illustrating an example embodiment of a communications network including one or more telephony communication devices having modifiable and expandable functionality; Fig. 8 is a flowchart illustrating an example embodiment of a method of indicating an incoming call to a second user of a telephony communication device; Fig. 9 is a flowchart illustrating an example embodiment of a method of selectively transmitting media during a telephone call; Fig. 10 is a flowchart illustrating another example embodiment of a method of selectively transmitting media during a telephone call; Fig. 11 is a flowchart illustrating an example embodiment of a method of scheduling and performing a telephone call; Fig. 12 is a flow chart illustrating an example method of displaying text associated with a telephone call; Fig. 13 is a flow chart illustrating an example embodiment of a method of communicating information in accordance with a state of a telephony communication device; Fig. 14 is a flow chart illustrating an example embodiment of a method of communicating information in accordance with a state of a telephony communication device; WO 01/31900 PCT/USOO/29576 13- Fig. 15 is a flow chart illustrating an example embodiment of a method of communicating an audible expression during a telephone call; Fig. 16 is a flow chart illustrating an example embodiment of a method of screening a telephone call based on information associated with the call; Fig. 17 is a flow chart illustrating an example embodiment of a method of playing content of an e-mail message as audio on a telephony communication device; Fig. 18 is a flow chart illustrating an example embodiment of a method of sending a graphical message for a user to a telephony communication device; Fig. 19 is a flow chart illustrating an example embodiment of a method of communicating a graphical message to a user of a telephony communication device; Fig. 20 is a flow chart illustrating an example embodiment of a method of placing one or more connections on hold during a telephone call; and Fig. 21 is a flow chart illustrating an example embodiment of a method of dynamically configuring a telephony communication device.

WO 01/31900 PCT/US00/29576 -14- DETAILED DESCRIPTION 1. Telephony System Architecture A telephony system architecture is a system architecture including one or more inter-related system components that together define the available telephony applications on a Telephony Communication Device (TCD). An open telephony system architecture is a telephony system architecture that, in addition to a vendor that controlled development of the one or more telephony applications defined by the telephony system architecture, is accessible for users and third party vendors to modify the telephony functionality of one or more of the telephony applications after such telephony applications have been deployed in the field on a TCD. An extensible telephony system architecture is a system architecture that allows telephony applications to be added to a TCD already deployed in the field.

Fig. 1 is a block diagram illustrating an example embodiment of an open and extensible telephony system architecture 1 for a TCD. The extensible telephony system architecture may be considered a layered architecture 1 where adjacent layers of abstraction (or layers) communicate between each other such that layers on either side of a given layer are independent of each other. In other words, functions may be defined for a higher layer of abstraction to be performed on a non-adjacent lower level of abstraction without knowing or specifying the details of the non-adjacent lower layer.

For illustrative purposes, the TCD on which the telephony system architecture 1 resides is referred to herein as a first TCD. This first TCD may be connected to a communications network, as will be described in more detail below in relation to Fig. 7.

The open and extensible telephony system architecture 1 may include an applications layer 3, an open application programming interface layer 5, a core telephony functionality layer 9, an operating system layer 11, a software/hardware interface layer 13 and a telephony hardware layer 1.1 Telephony Hardware Layer The telephony hardware layer or telephony hardware component 15 includes several hardware elements for performing the telephony operations associated with a telephone call. The telephony hardware component 15 may include a processor for processing instructions corresponding to a telephony operation. Such a processor may be chosen such that the processor is capable of processing a telephone call at a real-time rate such that a user participating in a telephone call does not experience any delays in the WO 01/31900 PCT/US00/29576 telephony functions associated with the telephone call, particularly in the transmission of audio data. For example, the processor may be the StrongArm 1110 running at 206 MegaHertz (MHz).

The telephony hardware component 15 also may include memory for storing s information. For example, the memory may include non-volatile memory such as a flash read-only memory (Flash ROM) for persistently storing telephony applications and data, and may also include volatile memory such as synchronous dynamic random-access memory (SDRAM) for temporary storage of and faster access to telephony applications and data The capacities of the volatile memory and non-volatile memory may be selected and changed in accordance with the storage needs and configuration of the first TCD within the communications network. For example, the first TCD may be configured, as a part of being initialized, to download telephony applications and/or non-telephony applications from one or more storage resources on the network. In such a configuration, the first TCD may have a relatively larger amount of volatile memory for faster processing because a relatively lower amount of non-volatile memory is needed for storing applications.

In contrast, the first TCD may be configured to store large amounts of data such as, for example, audio files, or to store one or more large applications or a large number of applications. In such a configuration, the first TCD may have a relatively larger amount of non-volatile memory to store the data and applications, resulting in less volatile memory. Obviously, the capacities of the volatile and non-volatile memories also are affected by the physical space available within the first TCD.

The telephony hardware component 15 also may include audio processing circuitry for processing the audio information transmitted during a telephone call. The audio processing circuitry may include a codec for performing typical audio processing functions including the compression and decompression of audio data being transmitted to and received from, respectively, the communications network. The audio processing module may be designed to sample audio data in a variety of sizes and process the audio data at any of a variety of sample rates. For example, the audio processing module may include the UDA 1341TS stereo codec from Philips Semiconductors and sample audio data at a 16-bit size and at a sample rate of 32 kilohertz (KHz). Other sample rates may be used, such as, for example 44.1 and 48 KHz.

SU2-U4-2002 US0029576 -16- The telephony component 15 also may include video processing circuitry, including one or more video codecs, for processing video using known techniques.

As will be discussed in more detail below in relation to Fig. 5, the telephony hardware component 15 also may include a display screen and associated graphical logic. In an embodiment, the display screen is a 160 x 160 pixels graphics display. The display screen may be capable of displaying color, monochrome, or gray-scale pixels.

For example, in an embodiment, the display screen is designed to display pixels using a gray-scale.

The telephony hardware component 15 also may include a network interface for communicating data between the first TCD and the transmission medium of the communications network. In an embodiment, the communications network adheres to the Ethernet protocol and the network interface is an Ethernet interface such as, for example, the CS 8900A-CQ3 10BaseT Ethernet controller from Cirrus Logic.

The telephony hardware component 15 also includes power circuitry for powering the first TCD. In an embodiment, the first telephony hardware component includes circuitry to receive power supplied by a Category 5 (CatS) cable. The power supply circuitry may use powering approaches compatible with Cisco Inline-Power techniques for Cat5/Ethernet LANs developed by Cisco Systems, Inc.

1.2 Software/Hardware Interface Layer The software/hardware interface layer 13 may define a plurality of drivers for operating the hardware elements of the telephony hardware layer 15. The drivers may be programmed in any of a plurality of programming languages, for example, C.

1.3 Operating System Layer The operating system layer 11 may comprise any of the plurality of operating systems. As will be described below in more detail in relation to Fig. 2, the core telephony functionality layer is configured such that abstraction layers 3 and 5 may be programmed independently of the operating system of the operating system layer 11.

The operating system of the operation system layer 11 may be a real-time operating system (RTOS) or another operating system, such as, for example, Windows® NT, Mac® OS, UNIX® or LINUX®, which are more commonly associated with a general purpose computer.

AMENDED SHEET 02-04-2002 U.U029576 -17- In an embodiment of the operating system layer 11 that uses an'RTOS, the RTOS may be VxWorks® from Wind River Systems, Inc. and the operating system layer 11 may also include other components supplied by Wind River including: Personal JWorks® 3.0 (Personal Java, JDK True FFS Flash file system manager; the Simple Network Management Protocol (SNMP) vl/v2c; and the Rogue Wave tools.h++ Library.

1.4 Core Telephony Functionality Layer The core telephony functionality layer 9 defines the core telephony functions associated with a telephone call. Fig. 2 is a block diagram illustrating an example embodiment of the core telephony functionality layer 9, which includes an OS abstraction layer 33, the core telephony functions module 25, the telephony application objects module 23 and the core telephony functionality API module 21.

1.4.1 OS Abstraction Layer The OS abstraction layer 33 interfaces the native operating system of the operating system layer 11 with the remaining modules and layers of the telephony system architecture, including modules 21, 23 and 25 and layers 3 and 5. The OS abstraction layer 33, by providing an interface to the native operating system VxWorks or Windows NT) avoids dependence on the native operating system by the remaining modules and layers. The OS abstraction layer 33 may include abstractions for maintaining date and time information, registering events, managing message queues, managing socket-based communications, synchronizing telephony operations on the TCD, managing tasks, and providing timers.

1.4.2 Core Telephony Functionality Module The core telephony functions module 25 includes the phone set management module 27, the media processing module 29 and the call processing module 31. The phone set management module 27 includes abstractions defined to handle low-level device interactions, such as button presses, hook switch operations, and lamp (LED) control.

1.4.2.1 Media Processing Module The media processing module 29 provides a framework for the first TCD to perform real-time audio processing for one or more telephone calls. The media processing module 29 may be organized such that the media data flows through with AMENDED SHEET WO 01/31900 PCT/US00/29576 -18minimum latency. The audio data may be processed in chunks, each chunk being audio data from a particular temporal interval. For example, the media processing module 29 may process the audio data in 10 millisecond (ms) chunks. For example, as is described below in more detail in relation to Fig. 3, each processing element of a media processing component 30 may process media in 10 ms chunks.

The media processing module 29 may include one or more media processing components, each media processing component corresponding to a particular telephone call. In a hardware embodiment, the media processing module 29 may include physically-separate media processing components such that the number of telephone calls that the media processing module can process concurrently is limited by the number of these physical media processing components. In such a hardware embodiment, at least part of the media processing module 29 may be implemented using a dedicated digital signal processor (DSP).

In a software embodiment where an object-oriented programming language, for example, or Java, is used, one or more abstractions classes or structs) may be used to represent the media processing module 29 and one or more media processing components, as described below in more detail in relation to Fig. 4.

1.4.2.1.1 Media Processing Component Fig. 3 is a data flow diagram illustrating an example embodiment of a media processing component 30. Traditionally, only audio has been associated with a telephone call. More recently, however, video has become a part of telephone calls. As described below in more detail, the first TCD may support telephone calls including audio, video and other associated data Accordingly, although most of the media data and media processing elements described below are audio-related, the media processing component 30 also may include video processing elements that process video data in coordination with the audio processing elements of the processing component The media processing component 30 may include one or more connection media input interfaces 41, a user media input interface 59, a local call bridge 51, one or more connection media output interfaces 87 and a user media output interface 82.

For a telephone call between one or more first users of the tirst TCD and one or more second users at one or more second TCDs, for each second TCD, the call processing module 31 (described in more detail below in relation to Fig. 4) maintains a corresponding connection to the second TCD. The media processing of the telephone LOUVU4CZDI -19call is represented by the media processing component 30. Each connection media interface 41 and corresponding connection media output interface 87 together represent a connection between the first TCD and one of the second TCDs.

Each connection media input interface 41 includes an input buffer 42, a dejitter buffer 44 and a decoder 47.

The input buffer 42 receives connection input media 40 and generates connection media 43. The connection input media 40 is media data received from the transmission medium of the network over a network connection from another telephone call participant, and may be received in the form of data packets conforming to one or more media transport protocols, such as, for example, the Real-Time Transport Protocol (RTP) and the Real-Time Transport Control Protocol (RTCP). The input buffer 42 may depackage the connection input media 40 by removing the media transport information from the audio data packets of the connection input media 40 to produce the connection media 43.

The connection input media 40 may be a chunk data from a temporal interval greater than the temporal interval, e.g. 10 ms, that the media processing component 30 is configured to process. Accordingly, the input buffer 42 may be configured to buffer the connection input media 40, process the connection input media 40 in chunks corresponding to the configured temporal interval, and output the connection media 43 in chunks corresponding to the configured temporal interval. Although not shown in Fig. 3, the other inputs, microphone audio data 55, tone indicator 57 and stored audio data 58, also may be received by input buffers and buffered such that the inputs received by the echo suppressor/cancellor 61, the tone generator 69 and the first mixer 74 are each a chunk of data corresponding to the configured temporal interval.

The dejitter buffer 44 receives the connection media 43 and generates dejittered media 45. The dejitter buffer 44 applies known techniques to remove information from the connection media 43 to remove "jitter" from the resulting media played to a user of the first TCD. During transport across the-network medium of the communications network, data packets of the connection input media 40 may have been routed and copied such that the connection input media 40 may include re-ordered packets and/or multiple same packets. For example, if ordered packets 1, 2 and 3 were sent from a second TCD to the first TCD, packet 1 may be duplicated and the packets re-ordered such that packets 1, 3, 1 and 2 arrive at the first TCD. The dejitter buffer 44 of the TCD includes logic to AMENDED SHEET I WO 01/31900 PCT/US00/29576 recognize and eliminate re-ordered and duplicate packets such that the dejittered media includes the originally transmitted media packets 1, 2 and 3, properly ordered and without duplicates.

The connection input media may have been encoded using known techniques by a second TCD before transmission to the first TCD. The decoder 47 receives the dejittered media 45, and decodes the dejittered media 45 using known techniques to produce decoded connection media 49, which is then sent to local call bridge 51.

The user media input interface 59 includes an echo suppressor/canceller 61, a tone generator 69, a first mixer 74, a second mixer 65 and a splitter 73.

The echo suppressor/canceller 61 receives microphone audio data 55 and generates de-echoed audio data 63. The microphone audio data 55 is audio data received from the user of the TCD through a microphone. For example, the microphone audio data 55 may be received from a microphone of a telephone handset, a microphone embedded in a telephone base as part of a speaker phone, or a microphone used for input to a computer.

The echo suppressor/canceller may include echo suppression logic to control the suppression of echoes in the microphone audio data 55. For example, if a TCD has a speaker phone base assembly including a base speaker for playing audio signals of a telephone call, the echo suppressor/canceller 61 may include echo suppression logic to detect when the microphone audio data 55 includes voice data and to turn off the base speaker as a result of this detection. Accordingly, the microphone that a user is using during a telephone call does not receive any sound from the base speaker which would cause echoes of one or more voices of the telephone call to be included in the microphone audio data The echo suppressor/canceller 61 also may include echo cancellation logic to apply echo cancellation techniques, by recognizing the Lower intensity, delayed audio signals of an echo and to subtract these signals from the microphone audio data 55 to produce the de-echoed audio data 63. Other echo suppression and cancellation techniques may be used.

The tone generator 69 receives a tone indicator 57 and generates an indicated tone 71. The indicated tone 71 is a tone indicated by the tone indicator 57. For example, the tone indicator 57 may represent a digit of a telephone number entered by a user from a standard telephony touch tone dialing keypad, computer keyboard or mouse. In this WO 01/31900 PCT/US00/29576 -21example, the indicated tone 71 generated by the tone generator 69 may be a tone associated with the digit in accordance with the Dual Tone Multi-Frequency (DTMF) standard.

The tone indicator 57 also may represent other tones associated with a telephone call. For example, in response to a user lifting a handset from a switch hook or pressing a button on a telephone base, the tone indicator 57 may represent a dial tone to be generated by the tone generator 69. In response to attempting to establish a telephone call with another TCD that is busy, the tone indicator 57 may represent a busy signal and the tone generator 69 may generate, as the indicator tone 71, a corresponding busy 0to signal. Further, in response to a call set-up message from anther TCD, the tone indicator 57 may represent an incoming telephone call indicator, for example, a ring. Other tones associated with a telephone call may be generated by the tone generator 69.

A first mixer 74 may receive the indicated tone 71 and stored audio data 58. The stored audio data 58 may be a portion of an audio file or other form of audio data stored in an audio storage medium 60. For example, the audio data 58 may be streaming audio that is a portion ofa voicemail message or a prerecorded sound. The audio storage medium 60 may be non-volatile memory on the TCD or another storage resource on the communications network on which the TCD resides. The stored audio data 58 may be sent to the first mixer 74 in accordance with a telephony application.

The first mixer 74 may be configured with one or more of a plurality of mixing parameters 76. For example, one or more of the mixing parameters 76 may indicate weights to be associated with the indicated tone 71 and the stored audio data 58. These weights may weigh the amplitudes of the indicated tone 71 and stored audio data 58 to generate the mixed audio 75. Accordingly, the mixing parameters 76 may effectively disable mixing of either the indicator tone 71 or the stored audio data 58, may give either input greater impact in generating mixed audio 75 or may be weighted such that the indicator tone 71 in the stored audio data 58 are mixed equally.

The splitter 73 receives the mixed audio 75 and sends the mixed audio 75 to the second mixer 65 and a third mixer 83.

The second mixer 65 receives the mixed audio 75 and the de-echoed audio data 63 and mixes the two inputs to produce mixed user audio 67. This mixed user audio 67 is sent to the local call bridge 51, which determines the media sent to each of the participants in the telephone call. Accordingly, the second mixer 65 may be configured WO 01/31900 PCT/US00/29576 -22with one or more of the plurality of mixing parameters 76 to weigh the amplitudes of the mixed audio 75 and the de-echoed audio data 63, thereby defining the impacts of each of these inputs on the mixed user audio 67.

The local call bridge 51 receives the mixed user audio 67 and one or more decoded connection media 49, each decoded network media 49 corresponding to a connection, and produces one or more connection mixed media 53 and a user-specific mixed media 81. The local call bridge 51 determines which of the decoded connection media 49 and the mixed user audio 67 to mix to produce the user-specific mixed media 81 and each of the one or more connection mixed media 53. Further, the local call bridge 51 may receive bridge parameters 52 that configure the local call bridge 51 for such mixing.

For example, the local call bridge 51 may be configured such that the userspecified mixed media 81 does not include some or all of the mixed user audio 67. Such a configuration prevents the user of the TCD from hearing the microphone audio data spoken by the user. This prevention may be desirable not only because the user may not need to hear her own voice, but also because hearing her own voice with a slight delay as part of the mixed audio output 85 may confuse the user, or at least make the mixed audio output more difficult to understand.

Similarly, the local call bridge 51 may be configured to prevent each connection mixed media 53 corresponding to a first connection from including media of the connection input media 43 corresponding to the first network connection. For example, consider a conference call including participants UI corresponding to the first TCD, a second user U2 corresponding to a second TCD and a third user U3 corresponding to a third TCD. The local bridge 51 receives a mixed user audio 67, MI, corresponding to the first user and two decoded connection media 59, M2 and M3, corresponding to the first user U I and the second user U2, respectively. The local bridge 51 may be configured to mix media MI and media M3 to produce a connection mixed media 53, C1, to be transmitted to the second user U2. Analogously, the local call bridge 51 may be configured to mix media M1 and M2 to produce connection mixed media 53, C2, to be transmitted to the third user U3.

Although some mixing configurations have been described above, the local call bridge 51 may be designed such that the bridge parameters 52 can configure the call bridge 51 to mix in any of a variety of ways. For example, as is described below in SUZ-U4-UUe UDUU It 23 relation to feature telephony applications, an application may define a particular mix, or a user may provide values through an application for one or more of the bridge parameters 52 that define a particular mix such that a particular combination of the mixed user audio 67 and the one or more decoded network media 49 may be mixed and prevented from being mixed in generating the user-specific mixed media 81 and/or the one or more connection mixed media 53.

Each connection media output interface 87 may include an encoder 89 that receives the connection mixed media 53 and encodes this media using known techniques to produce the encoded media 91. An output buffer 97 receives the encoded media 91 and configures the encoded media 91, for example, by adding transport protocol data RTP and RTCP) to produce the connection output media 99. The connection output media 99 is transmitted to the TCD connected by the connection corresponding to the connection output media 99.

The third mixer 83 receives the user-specific mixed media 81 and the mixed audio 75, and mixes these inputs to produce the mixed audio output 85. The mixed audio output 85 may be sent to any of a variety of audio output devices such as, for example, a speaker of a telephone handset of the first TCD or a base speaker on the base of first TCD.

The recording buffer 93 may receive the mixed audio output 85 and store the mixed audio output to an audio storage medium 62 such as, for example, a non-volatile storage medium or another storage resource external to the first TCD, located on the communications network. The audio storage medium 62 and the audio storage medium may be a same storage medium or may each be part of a same storage medium.

The third mixer 83 may be configured using one or more of the mixing parameters 76 to weight the amplitudes of the user-specific mixed media 81 and the mixed audio 75, thereby defining the impacts of each of these inputs on the mixed audio output Each of the processing elements of the media processing module 29, including 41,42, 44, 47, 51, 59, 61, 65, 69, 73, 74, 82, 83, 89, 93 and 97, and data elements associated therewith, including 40, 43, 45, 49, 52, 53, 55, 57, 58, 63, 67, 71, 75, 76, 81, 91 and 99, may be represented using software, firmware, hardware, or any combination thereof.

AMENDED SHEET WO 01/31900 PCT/US00/29576 -24- In an example software embodiment, each processing element and associated data elements may be represented using a general purpose object-oriented programming language such as, for example, or Java.

Fig. 4 is a block diagram illustrating in an example embodiment of the call processing module 31 of Fig. 2 in relation to an example software embodiment of the media processing module 29. In this software embodiment of the media processing module 29, the media processing component 30 is represented using an object-oriented programming language such as or Java.

The media processing module 29 may include a plurality of media processing controllers 115 and a plurality of media processing components 30, where each controller 115 and component 30 corresponds to a particular telephone call.

The media processing component 30 includes a plurality of media processing abstractions 117, where each media processing abstraction 117 represents a processing element from Fig. 3 and the input and output data elements associated with the processing element. Each media processing abstraction 117 may be of a different type, where each type inherits from a master media processing abstraction.

Each media processing abstraction 1 17 may include an attribute identifying the media processing component 30 to which the media processing abstraction 117 belongs and may include a plurality of methods that may be invoked on the media processing abstraction 117. The methods defined for one or more of the media processing abstractions 117 may include methods that do the following: enable and disable the media processing abstraction 117, initiate processing by the media processing abstraction 117 of the chunk of media it received, determine one or more states of the media processing abstraction 117, determine the media processing component 30 to which the media processing abstraction 117 belongs, determine a name or unique identifier of the media processing abstraction 117, determine information regarding the data input and output from the media processing abstraction, determine a maximum and minimum number of inputs and outputs for the media processing abstraction 117, determine the current number of inputs and outputs defined for the media processing abstraction, determine whether an input or an output is currently connected for the media processing abstraction 117, etc.

WO 01/31900 PCT/US00/29576 1.4.2.1.2 Media Processing Controller The media processing controller 115 controls the creation, operation and destruction of the media processing component 30. More specifically, the media processing controller 115 controls the creation of the media processing abstractions 117, the definition of the relationships between the media processing abstractions 117, the operation of the media processing abstractions 117, and the destruction of the media processing abstractions 117.

For example, the media processing controller 115 may include methods for creating and destroying a media processing abstraction 1 17. The media processing controller 115 also may include a method for linking two media processing abstractions 117 together, thereby defining that the output of a first media processing abstraction is the input of a second media processing abstraction. The media processing controller 114 also may include a method for destroying such links, thereby destroying the relationship between two media processing abstractions. This adding and destroying of abstractions and links may be considered as building and removing, respectively, a media processing component 30 as part of setting up and tearing down, respectively, a telephone call.

Telephony applications of the applications layer 3, and other higher-level abstractions, may use the media processing controller 115 to dynamically create media processing components 30, and to link media processing elements during a telephone call. Further, a telephony application may be defined to configure media processing elements in unique ways to create custom media processing abstractions for a particular feature provided by the telephony application.

The media processing controller 115 may include methods for enabling and disabling a media processing component 30. If there are currently multiple media processing components 30 representing multiple telephone calls, it may be desirable to disable a particular media processing component 30 when the telephone call that it represents is not active on hold) such that media processing resources are conserved. Conversely, when a telephone call becomes active, the enabling method may be used to enable the corresponding processing component The media processing controller 115 may include a method for indicating when a media processing component 30 is ready for processing media, and also a method for indicating that the media processing component 30 is no longer needed and may be destroyed.

uL-U+-Ue-U UZUUZ /bt -26- The media processing controller 115 may include methods for initiating processing of a next chunk of data by the media processing component 30, locating a media processing abstraction 117, determining a number of media processing abstractions 117 of the media processing component 30 and determining a number of links and a media processing component As described above in relation to Fig. 3, a media processing component 30 may include representations of one or more connections. Accordingly, the media processing controller 115 may include an attribute corresponding to each connection represented by the media processing component 30. Further, the media processing component 30 also may include a method for retrieving a pointer to a connection.

As described above in relation to the connection media input interface 41 and the connection media output interface 87 of Fig. 3, media may be received and transmitted in the form of data packets conforming to one or more media transport protocols.

Accordingly, the media processing module 29 may include an abstraction for representing a session, an RTP session, of one of the media transport protocols, and the media processing controller 115 may contain an attribute pointing to such abstraction. Further, for each media processing abstraction 117 representing a connection of a telephone call, a media transport protocol such as, for example, RTCP, may maintain statistical information pertaining to the connection. The statistical information for the one or more connections may be aggregated and represented by an abstraction so as to monitor the transporting of the media on each connection. For example, this abstraction may be an RTCP session. The media processing controller 115 may contain an attribute that points to this RTCP session and may include a method for retrieving a pointer to the RTCP session.

For setting up a call between the first TCD and another TCD, the media processing controller 115 may include a method for determining one or more audio processing encoding algorithms supported by each TCD. As a result of this determination, the media processing controller 115 may control the decoding and encoding algorithms used by the decoder 47 and the encoder 89, respectively, of the media processing component The media processing controller 115 also may include a method for creating a connection media processing abstraction 117 such as, for example, the connection media input interface 41 and the connection media output interface 87.

AMENDED SHEET WO 01/31900 PCT/US00/29576 -27- The media processing controller 115 also may include methods for controlling the starting and stopping of media input to the media processing component 29. For example, the media processing module 29 may include methods that perform one or more of the following functions: controlling the tone generator 69 to start or stop generating the indicated tone 71; controlling the connection input media interface 41, in particular the input buffer 42, to start and stop generating the connection media 43; controlling the echo suppressor/cancellor 61 to start and stop receiving the microphone audio data 55; controlling the first mixer 74 to stop, start or pause receiving the stored audio data 58 to generate the mixed audio t0 The media processing controller 115 also may include methods for controlling media output from the media processing component 30. For example, the media processing component may include methods to perform the following functions: controlling the user media output interface to start and stop sending the mixed audio output 85 to audio output hardware and to start and stop storing the mixed audio output 85 to an audio storage medium 62; and controlling the connection media output interface 87, in particular the output buffer 97, to start and stop outputting connection output media 99 to the communications network.

Although the first TCD currently may be involved in multiple telephone calls, the user of the first TCD can only actively participate in one telephone call at a time. For example, the user may have two telephone calls on hold, and be actively participating in a third telephone call. Because the user can only participate in one telephone call at a time, at any given time, only one media processing component 30 needs to use the one or more microphones and the one or more speakers of the first telephony communications device. Accordingly, the media processing controller 115 may include methods for assigning and de-assigning the microphones and speakers to a media processing component All of the functions described in relation to the media processing controller 115 and the media processing component 30 may be invoked in response to functions defined by higher-layer abstractions such as the telephony applications of the applications layer 3. Specifically, these telephony applications communicate with the call processing module 31 to control the call processing associated with one or more telephone calls, and the call processing module 31 controls the media processing module 29 to process media in accordance with the one or more telephone calls.

WO 01/31900 PCT/US00/29576 -28- Representing the media processing and call processing of a call independently, with the call processing module 31 and the media processing 29, provides flexibility in designing the call processing module 31. For example, the media processing module may be implemented as part ofa DSP or as one or more software abstractions. As a s result, the call processing module 31 may be configured such that the abstractions of the call processing module 31 are generic to more than one implementation of the media processing module 29, such that less programming is needed to adapt the call processing module 31 to a particular implementation of the media processing module 29.

1.4.2.2 Call Processing Module Fig. 4 shows the call processing module 31 of Fig. 2 in more detail. The call processing module 31 may model the state transitions of one or more telephone calls.

Accordingly, applications running on the first TCD, for example, applications defined in the applications layer 3, may query the abstractions of the call processing module 31 to determine the state of a telephone call and its connections. Further, applications may register to be automatically notified if the state of a telephone call, including one of its connections, changes, or if other telephony events occur.

The call processing module 31 may include the following abstractions: a call manager 105, one or more calls 109, one or more call processing media interfaces 1 13, one or more call control connections I1 l, a call control transport controller 107, one or more call control network input interfaces 101 and one or more call control network output interfaces 103.

The processing performed by the call processing module 31 includes controlling one or more calls in accordance with one or more call control protocols, signaling protocols) and controlling the media processing associated with each call and the one or more connections included in the call.

1.4.2.2.1 Call Manager The call manager 105 may be considered the nucleus of the call processing module 31 and serves as an interface between the call processing module and higher layers of abstraction. The call manager 105 controls the one or more calls 109 that represent the telephone calls in which the first TCD is currently participating. The call manager 105 communicates telephony events to the appropriate call 109. Such events may include call control events, for example, a call control message, and application- WO 01/31900 PCT/US00/29576 -29level events, for example, an event indicating to create a new call 109 or connection or to terminate a connection or call. For example, during a telephone call, or in setting up or tearing down a telephone call, higher level telephony applications may invoke methods defined by the call manager 105, which, subsequently, may invoke a corresponding s method of the appropriate call 109.

Each call 109 may contain several methods, many of which correspond to the methods of the call manager 109, that are executed in accordance with the performance of a telephone call. It may be desirable to configure higher-level abstractions to communicate with the call manager 105, as opposed to an appropriate call 109, because calls 109 are relatively transient abstractions that may be available at one instance during a telephone call) and gone at a next instance after someone hangs up a telephone). Accordingly, the call manager 105 provides a less transient more persistent) abstraction that is available regardless of whether the first TCD is currently participating in any telephony calls.

Because the call manager 105 and each of the calls 109 that it manages include several analogous methods, it should be understood that, for illustrative purposes, several methods are described below in relation to the call manager 105 or a call 109, but such methods may be applicable to both types of abstractions in accordance with how the abstractions are configured.

The call manager 105 may include several functions for controlling the setting up, maintaining, tearing down, and media processing of a telephone call.

The call manager 105 may include an attribute that maintains a list of all calls 109 currently represented by the call processing module 31, and may include methods for creating a call and dropping a call. For example, the call manager may create a call in response to a user dialing a number or entering a URL, or in response to the user answering a call by picking up a handset or pressing a button.

The call manager 105 may drop a call in response to a user of the first TCD hanging up or in response to a signal received from another TCD indicating that the user of that device has terminated the telephone call.

The call manager 105 may include a method for determining the number of calls 109 currently represented by the call processing module 31, and for determining the call states of each of these calls 109. The call manager 105 and calls 109 define states that model a telephone call similar to how the Java Telephony Application Programming WO 01/31900 PCT/US00O/29576 Interface (JTAPI) models a telephone call. Accordingly, the states defined for a telephone call may include: the call state, such as, for example, idle, active or invalid; the terminal state which represents the state of the first TCD; the address state that represents the first TCD's address telephone number or URL); the call connection state that associates the first TCD's address with a telephone call; and the terminal connection state that associates the first TCD with a connection.

The terminal connection may be desirable to define a state of a particular terminal connection because one or more TCDs may be associated with a same address. For example, a home may have a plurality of telephones reachable at a same telephone number.

The call manager 105 may include a variety of methods commonly associated with a telephone call, including methods for adding a connection to a telephone call, dropping a telephone call, and transferring a telephone call to another TCD. Other methods may define, in response to receiving a call set-up message from another TCD, a function for accepting a connection with another TCD. Accepting a call may include invoking a function on the media processing interface 113 that controls the phone to ring.

Further methods may define, in response to receiving a call set-up message, a function for either rejecting a connection, including invoking methods of the media processing controller 115 to control generating a busy signal and sending it to the calling TCD, or re-directing the calling TCD to another TCD.

The call manager 105 also may include a method for dropping a connection from a telephone call, for example, in response to input from the user of the first TCD or in response to receiving a signal indicating that the user of another TCD has hung-up.

The call manager 105 also may include methods for determining the number of call control connections 111 of a call 109, for getting control of a call control connection 11 and determining a state of a call control connection 11 The call manager 105 also may include methods for determining addresses that have been called as part of a call 109 and for determining the addresses of the TCDs that have called the first TCD as part of the call 109.

The call manager 105 also may include methods for completing the set-up of a connection between the first TCD and a second TCD, for example, by sending a response to a call control set-up message or by sending an acknowledgement to another TCD acknowledging that the other TCD accepted the invitation to have a telephone call.

US:UU2e!Jbb -31- Such methods may communicate with the call control transport controller 107, described in more detail below.

1.4.2.2.2 Media Processing Interface For each call 109, the media processing interface 113 provides an interface between the call 109 and the media processing controller 115 and media processing component 30 corresponding to the call 109. Through the media processing interface 113, a call 109 may control its own media processing independently from the media processing of other calls 109.

The media processing interface 113 may include several methods corresponding to the methods of the media processing controller 115. Further, the media processing interface 113 may include methods that control the media processing module 29 to process media in accordance with a specific telephony event. As described above in relation to Fig. 4, the media processing controller 115 may include functions for controlling the tone generator 69 to start and stop the generating of indicated tones 71.

The media processing interface 113 may include functions to control the media processing controller 115 to control generation of a specific tone corresponding to a telephony event. For example, the media processing interface 113 may include functions for starting and stopping the playing of specific tones such as DTMF tones, dial tones, a tone indicating that another TCD is busy a busy signal), and a tone indicating that a telephone call is incoming a ring), etc.

The media processing interface 113 may function as described in the following example. The call manager 105 may receive an indication, from the phone set management module 25, that a user has pressed a key on a telephone keypad. The call manager 105 determines the call 109 associated with the pressed key and invokes a method on the call 109 to play the DTMF tone associated with the key. Consequently, the call 109 invokes the appropriate method on the media processing interface 113 to start playing the DTMF tone, and this method invokes the appropriate method of the media processing controller 115 to control the tone generator 69 to receive the tone indicator 57, which indicates the DTMF tone, and to generate the DTMF tone as the indicated tone 71.

The media processing interface 113 also may include one or more methods for querying the media processing module 29. For example, the media processing interface AMENDED SHEET PCTIUSOO/2957 6 WO 01/31900 32- 113 may include methods for determining that the media processing module is receiving connection input media 40 and transmitting connection output media 99.

The media processing interface 113 also may include methods for querying the The media processing the status of low-level devices, such as the phone set management module 25 regarding the status of loleel deice, such a e hook switch. For example, the media processing interface 13 may include one or module methods for querying one or more abstractions f the phone set management module to determine if a handset is off-hook.thods for determ n The media processing interface 113 also may incud o o send the codec algorithms supported by the TCD, for assigning an audio output device to send the mixed audio output 85 and for determining whether an audio output device is the mixed audio output 85, and for determi e currently enabled, for example, by querying the phone set management module The media processing interface 113 may be any of a variety of types of media processing interfaces 113. For example, as part of the telephony system architecture residing on the first TCD, the media processing interface 113 is of a type defined specifically for a TCD. In another example, the call processing module 31 may model specifically for a TCD. In ano two networks or a signaling the call processing performed on a media gateway between two networks or a signaling gateway between different signaling protocols. In these cases, the media processing interface 113 may be of a type that is defined specifically for the type of processing necessary for the particular gateway.oce g The media processing interface 113 deals primarily with processing edia.

Another aspect of the call processing module 31 is to control a telephone call, including the use of call control signaling) protocols This aspect of the call processing module 31 will now be described in more detail.

1.4.2.2.2 Call Control Protocols of call, for example, a peero-peer (peer A call 109 may be of a particular species of callcall tt ncl des oeeee call) or a master/slave call (slave call). A peer call 109 represents a call that includes one or more connections adhering to a peer-to-pee protocol for example, SIP or .323, and may include one or more connections adhering to a master/slave protocol for example, MGCP, Megaco/H.

24 8 or Skinny Station. A lave call 09 represents call that includes one or more connections adhering to a master/slave protocol- Each species of call 109 includes abstractions for defining data correspondingto the type of connections included in the call and for defining methods for controlling a telephone call in accordance with the species of protocol.

PCT/US00/ 29 5 76 WO 01/31900 -33- A slave call 109 is a call that is controlled by a network resource external to the first TCD. A slave call 109 may be one of a plurality of master/slave call types, including an MGCP call, a MegacoH.

24 8 call or a Skinny Station call MGCP calls 109, Megaco/H.

24 8 calls 109 and Skinny Station calls 109 are calls that adhere to MGCP, Megaco/H.

2 4 8 and the Skinny Station protocol, respectively Each of these types of slave call may be defined as an abstraction that inherits from an abstraction of a generic slave call 109, and may further define functionality associated with the type of slave call that it represents- ll control connections 11 The call processing module 31 includes one or more ca co Each call control connection 111 (except a ghost call connection described below in more detail) has a corresponding media control call connection as represented by a media processing abstraction 117 of the media processing module 29. As described above in relation to the media processing component 30, such media processing abstractions represent the media flow of the connection. In contrast, a call control connection 111 of s1 a call 109 defines and controls the signaling communications on the first TCD that are associated with a call 109 in accordance with a particular call control protocol.

A slave call 109 may include a plurality of slave call control connections 111 that control the call signaling communications for the call on the first TCD in accordance with the type of master/slave call control protocol that the slave call control connection ll1 represents.

For a peer call 109, each call control connection II I may be one of several types, including an H.323 call control connection, a SIP call control connection, a ghost call control connection and a slave proxy call control connection.

An H.323 call control connection and a SIP call control connection control the signaling communications of a connection on the first TCD in accordance with the H.323 protocol and the SIP protocol, respectively.

A ghost call control connection represents a connection between two other TCDs.

For example, if the first TCD transfers a call to another TCD and for some reason it is desired to track the progress of the transferred connection, a ghost call control connection may be used to monitor the state of the connection between the two other TCDs. To monitor the state of the transferred connection, the ghost call control connection may receive communications from one of the two other TCDs. Because the connection is WO 01/31900 PCTUS00/2 95 76 -34between the two other TCDs, a ghost call control connection does not have a corresponding media processing connection.

If a peer call 109 represents a call including a slave connector, a slave proxy call control connection 111 that proxies a slave call control connection Ill may be used to represent the slave connection 111. each A telephone call represented by a call 109 may include several connections, each connection represented by a call control connection 111. As described above, each connection included in the telephone call may adhere to any of a plurality of call control protocols. Accordingly, a call 1 09 may control one or more call control connections I11, where each call control connection I11 is of a different type, for example, an H.323 call control connection or a SIP call control connection.

Representing each connection of a telephone call with an independent call control connection I 1, and independently representing the media processing and call processing of a telephone call enables a call 109 including multiple connections 111 to represent and control each connection concurrently, where each connection may adhere to any of a plurality of call control protocols.

For example, during a telephone call between the first CD, a second TCD a d a third TCD, a first connection may exist between the first and second TCDs, and a second connection may exist between the first and third TCDs. The first connection may be represented by a SIP call control connection I 1, and the second connection may be represented by an H.323 call control connection I 1. Further, the first and second connections may be represented by independent media processing abstractions 117 that represent the media processing of the connection.

The call 109 that represents such a telephone call may control the SIP and H.323 call control connections Il and the corresponding media processing abstractions 117.

During the telephone call, for each connection Ill, in accordance with the call control protocol that the connection repre5ents, SIP or H.323, the call 109 may invoke methods of the media processing interface 1 13, which invokes methods of the media processing controller to control the processing of media on the appropriate connections through the corresponding media processing abstractions 117.

The call control connections 111 control the signaling communications of a connection on the first TCD at a relatively high level. The call processing module 3 1 also includes a call control transport controller 107 that controls the signaling PCT(USOO/2 9 576 WO 01/31900 communications of a connection on the first TCD at a lower level that controls the transport and ensures the reliability of signaling messages transmitted from and received at the call processing module 31.

The call processing module 31 also includes call control network input interface 101 for receiving call control message corresponding to a call control protocol, and a call control network output interface 103 that transmits call control messages from the call control transport controller 107 to the communications network.

To send a call control message, for example, a SIP message, a call control To send a call control message, troller 107 which then connection 111 sends the message to the call control transport controller 107 which then o sends the call control messageto the call control network output interface 103, which then sends the call control message on to the communications network.

Foren sends comihe call control messages, the call control network input interface 101 receives the call control message and communicates the message to the call control transport controller 107, which communicates the incoming call control message to the call manager 105. The call manager 105 then dispatches the call control message to the appropriate call 109 that includes the connection 11I representing the network connection from whih the call control message was received.

The call control transport controller 107 also notifies the call manager 105 of sent call control messages that have been sent on to the communications network, but for any of a variety of reasons failed to reach their destination Further, in response to such a failure, the call control transport controller 107 may re-send a call control message onto the communihcations network through the call control network output interface 103.

Using the various abstractions described above, the call processing module 31 may be configured to support any of a plurality of call control protocols. Further, the call processing module 31, or an application using the call processing module 3, may be configured to select one of the plurality of call control protocols for a particular connection. This selection may depend on any of a number of factors, including available network resources and the capabilities of the TCD connected to the first

TCD

by the connection. l 31 or an For outgoing calls from the first TCD, the call processing module 31 or another telephony application may be configured to select a call control protocol to u set-upr. For a call with another TCD based on a sequence of digits or a URL entry by a user. For example, an application may define a rule indicating that, ifa user enters a three-digit extension, PCTIUSOO/2 95 76 WO 01/31900 -36the H.323 protocol is used to control the telephone call. Further, an application may include a rule indicating that, if a user enters a ten-digit PSTN telephone number, then SIP is used to control the telephone call.a rule indicating that ifa user In yet another example, an application may define a rule indicating that, enters a URL including the character string "SIP", then the SIP protocol is used to control the telephone call, and if the user enters a URL including the character string "H.323", then the H.323 protocol is used. call control protocols are Significantly, because the details pertaining to different a ono oo handled by the call processing module 31, the coretelephon API layer 21 and open API to layer 5, each described in more detail below, may be used to develop applications that are generic to all the call control protocols, allowing the call control details to be handled by the call processing module 31. Thus, call processing modue 31 allows APl- of both the core telephony API layer 21 and open API layer 5 to be callcontrorooo independent. nfigurd to support any number of call contol Although the first TCD may be configured to suppor any connetion, ther of call control protocols, and to select a particular call control prtcol for aonnection, the call processing module 31, another module of the core telephony functionality layer 9, or ton or more telephony applications of the applications layer 3 may configure the first TCD to support only certain call control protocols. For illustrative purposes, the various techniques that may be used to configure the first TCD to support particular call control protocols will be described with reference to the call processing module 31, although other modules or layers may define applications to apply the same techniques The call processing module 31 may be configured to determine the call control Thecall procesngmodue3, co on which the first TCD resides. For protocols supported by the communications network on which the first TCD resides F example, upon being initialized for the first time at a customer's prcmises the ca processing module 31 may send communications onto the customer's communication network to determine what call control protocols are supported, to determine any network resources that the first TCD should communicate with to implement the call control protocol, and to load any software necessary to support the call control protocol.

Further, the call processing module 31 may be configured to determine which call control protocols are supported by the communications network for incoming and outgoing telephone calls.

U* -U4-ZUU- U jUUZYb/b -37- The call processing module 31 may be configured to perform the discovering process in any of a number of ways, including: as a result of being initialized in the field, periodically, upon request by a user, or any combination thereof. Further, this discovery process may be performed for the first TCD by another network resource, for example, a TCD deployment server, discussed below in more detail in connection to Fig.

7.

In an embodiment, the call processing module 31 is programmed to know the location of the one or more network resources that may be used for implementing one or more call control protocols.

A communications network on which the first TCD resides may include a Dynamic Host Configuration Protocol (DHCP) server. The DHCP server may be configured to store information about the call control protocols that are supported by the communications network, and may indicate one or more servers that may be used to help implement the one or more call control protocols. If such a DHCP server is present, the call processing module 31 may access the DHCP server to retrieve the above-described call control information. Using DHCP servers to discover call control servers is described in the Internet draft document by the IETF entitled "DHCP Options for Call Control Servers" located at URL: http://www.ietf.org/internet-drafts/draft-ietf-dhcp- 01.txt as of April 6, 2000.

If the communications network does not include a DHCP server, or for some reason the DHCP server does not return the necessary call control protocol information, the call processing module 31 may be configured to communicate with one or more other network resources to determine the call control protocols, and their associated servers, Ssupported by the communications network.

For example, to determine whether the communications network supports the H.323 protocol, and the location of any H.323/SIP signaling gateways on the communications network, gatekeeper discovery techniques may be used. For example, the gatekeeper discovery techniques described by the International Telecommunications Union in the ITU-T Recommendation: H.323 Packet-Based Multi-Media Communications Systems, Geneva, Switzerland, February 1998 may be used.

To determine if the communications network supports the SIP protocol, and the location of any SIP servers on the communications network, the call processing module 31 may be configured to locate the one or more SIP servers using SRV DNS records as AMENDED SHEET PCT/US00/29 576 WO 01/31900 -38outlined in Appendix D of RFC 2543, SIP: Session Initiation Protocol by IETF as of October 26, 1999. If this SIP discovery technique fails, the call processing module 31 may be configured to attempt to contact a SIP proxy server at sip.<local domain> at default port 5060, using UDP and/or

TCP

To determine whether the communications network support the MGCP protocol, and the location of any MGCP call agents, the call processing module 31 may be configured to use the SRV DNS records approach (analogousto the technique described above for SIP in RC 2543) An MGCP call agent is an entity responsible for controlling teephone calls for a communications network using the MGCP protocol.

controlling telephone calls for c ionres that, Iif this attempt to locate the to The call processing module 31 may be configured such that,cate the MGCP call agent is unsuccessful, an attempt is made to contact an MGCP call agent at mgcp. <local domain> using UDP at the default port for MGCP, port 2427.

mgcp.<local domain> usge UDP at the Megaco/H.248 To determine whether the communications network supports the Megaco/H.

2 4 8 protocol, the call processing module 31 may be configured to use a similar technique to that described above for the MGCP protocol. The Megaco/H.

24 8 protocol standard is defined in IETF RFC 2885 and ITU H.248.

The call processing module 31 may be configured such that if the communications network does not support a particular call control protocol, then a space-saving stub may be installed as the call control connection 111 for the particular call control protocol. etose a pariculacall control The call processing module 31 may be configured protocol for example, SIP, as the call control protocol for all outgoing calls. If, however, the call processing module 31 determines that only a single call control protocol is supported by the communications network, the call processing module 31 may assign this call control protocol as the protocol used for all outgoing calls.

Further, if the call processing module 31 determines that the communications network supports multiple call control protocols for outgoing calls, but only a single call control protocol for inbound calls, the call processing module 31 may assign this single call control protocol as the call control protocol used for all outgoing calls.

The call processing module 31 also may be configured to use a particular call control protocol as he cal contro prooco for all incoming calls. If, however, the call porocessing module 31 det ine hat only a sngle call control protocol is supported by processing module 31 determines that only a sing U,-U4-UUZ UbUUJb /b -39the communications network, call processing module 31 may assign this call control protocol as the protocol used for all incoming calls.

Further, if the call processing module 31 determines that the communications network supports multiple call control protocols for incoming calls, but only a single call control protocol for outbound calls, the call processing module 31 may assign this single call control protocol as the call control protocol for all incoming calls.

By using abstractions 101-113, the call processing module 31 may be configured to support several features in accordance with a call control protocol SIP. Such call control features may include: transmitting and receiving call control messages in accordance with a variety of transport layer protocols, for example, Transport Control Protocol (TCP) and User Datagram Protocol (UDP); basic call set-up functions such as sending a call set-up message and responding to a call set-up message; and firewall support.

The call processing module 31 may support registering the first TCD in a registry or directory, for example, on a SIP server. Such a directory may reside on the first TCD, or on another network resource, for example, a companion computer to the first TCD or a network server. As described in more detail below in relation to Fig. 7, each entry of such a server may map a name or a URL of a user to a network address of the first TCD.

The call processing module 31 also may support having a registry entry corresponding to the first TCD expire after a predetermined amount of time. Further, the module 31 may be configured such that such entry is refreshed periodically to avoid expiration of a user's entry while the TCD is active powered on).

The call processing module 31 also may be configured to initiate placing a telephone call on hold. For example, a signal may be sent from the first TCD to another TCD indicating that the first TCD will stop consuming bandwidth. Analogously, the call processing module 31 also may be configured to receive a message from another TCD indicating that the other TCD will stop consuming bandwidth is placing the telephone call on hold).

The call processing module 31 may be configured to redirect phone calls in a plurality of ways. For example, the call processing module 31 may be configured such that if the user of the first TCD is already participating in another phone call, an incoming telephone call is redirected to another device on the communications network.

For example, the other device may be a voicemail server that plays the user's voicemail, AMENDED SHEET PCT/USOO/29 76 WO 01/31900 or may be another TCD. Further, user input, for example, from a button on a user interface may indicate that the user does not want to be disturbed regardless of whether the user is participating in a telephone call. Accordingly, an incoming call will be redirected automatically. Alternatively, an incoming call may be redirected if the incoming call is not answered afer a predetermined amount of time or after a predetermined number of rings. Lastly, an incoming call may be redirected on demand in response to receiving a user input.

The call processing module 31 may be configured to support blind transfers and consultative transfers of a telephone call. To perform a blind transfer, the call processing to module 31 may be configured, for a telephone call between a first user of the first TCD and a second user of a second TCD, to instruct the second TCD to set-up a call with a third user of TCD. After instructing the second TCD, the first TCD will terminate the connection between the first TCD and the secondsulting with a user of the third

TCD.

For a consultative transfer, the first TCD will set-up a connection to the third TCD. The first user may then consult with talk to) a user of the third TCD, after which the first TCD may instruct the second TCD to set-up a call with the third TCD, or may instruct the third TCD to establish a connection with the second TCD.

For either a blind transfer or a consultative transfer, an application may moitor the progress of establishing the new connection using a call 109 including a ghost call control connection 111. The other TCD that was instructed by the first TCD to set-up the new telephone call that includes the new connection may send one or more call th rst TCD to p notify the tis i control messages to th first TCD to notify the first TCD of the status of the new connection. If for some reason, it is desired to monitor and/or record the status of the new connection, the ghost call control connection 111 may maintain this status information.

The call processing module 31 also may be configured to record routing information regarding one or more connections associaed with the telephone call. Such routing information may include the duration of a connctin as part of a telephone call, and this routing information maybe used for several purposes including billing.

The call processing module 31, in accordance with the call control protocol of a connection, also may support attaching to a call control protocol message non-call control protocol information,y suppor example, audio files, text files, applications, data files, control protocol information, for example, audio files, WO 01/31900 PCT/US00O/29576 -41and pointers to data files or applications, etc. For example, the call processing module 31 may be configured such that multi-part MIMEs (Multi-purpose Internet Mail Extensions) may be attached to a SIP message.

The call processing module 31 may be configured, in accordance with a call control protocol of a connection, to inform another TCD of the capabilities and/or additional features and functions supported by the first TCD. For example, the call processing module 31 may be configured to use fields of a SIP message to inform the other TCD of the capabilities and additional features of the first TCD, and may negotiate common capabilities to be used between the two TCDs.

The call processing module 31 may be configured to record the duration of a connection between the first TCD and another TCD. Further, call processing module 3 1 may be configured to send and/or receive a message to/from another TCD at predetermined intervals to indicate that the sender of the message is still participating in the telephone call. Sending such messages at a pre-determined interval prevents an error in determining the duration of a phone call when a call control message to tear down a telephone call is never received.

The call processing module 31 may be configured to support several different known methods of authentication, including basic and digest methods of authentication.

Further, the call processing module 31 may be configured to provide different known authentication on the first TCD including symmetric authentication along with another TCD, and proxy authentication, where an authentication is performed for another network resource.

Further, the call processing module 31 may be configured to re-invite a call participant back into a telephone call. Re-inviting may be desirable to change the encoding algorithm used for a connection in response to changes in available network bandwidth or in response to a change in the number of connections involved in a conference call.

The call processing module 31 may be configured to combine two telephone calls into a single telephone call. For example, call manager 105 may manage a first telephone call 109 including a first SIP call control connection 11 and a first H.323 call connection Ill, and a second telephony call 109, including a second SIP connection I I, where each call control connection 111 also has a corresponding media processing connection 1 17. To combine the two telephone calls, the call manager 105 may be •Ut'-UQ-LUUe UOUU3 (0 -42 configured to create a third connection on the first call 109 that represents the second SIP connection 111 and to create a corresponding media processing connection 117. After transferring all the information regarding the second call 109 and the second SIP connection 111, the call manager 105 may then drop the second call 109. As a result, the first call 109 remains, including two SIP call control connections 111, an 1H.323 call connection 111 and three media processing connections 117.

Returning to Fig. 2, the phone set management module 27, the media processing module 29 and the call processing module 31 are relatively low level modules including abstractions that capture telephony events and notify other abstractions of these events.

The notified abstractions may be abstractions defined by one of the other modules 27, 29 or 31 within the core telephone functions module 25, or may be abstractions from the telephony application objects (TAO) module 23.

1.4.3 Telephone Application Objects Module The TAO module 23 may include a plurality of telephone application abstractions such as, for example, a client abstraction, a server abstraction, a message abstraction, a transport abstraction to enable local and remote communications between telephony applications defined in the applications layer 3 and the core telephony functions defined by the core telephony function module 25 and abstractions corresponding to the telephony abstractions defined by JTAPI.

The TAO layer 23 may include logic enabling synchronous and asynchronous communications for handling request-response commands and event notifications, and abstractions defining interfaces to the core telephony functionality API layer 21 to enable remote function calls on abstractions of the core telephony functionality layer 21.

Thus, the TAO layer 23 allows layers 15, 13, 11, 33 and 31 to remain independent, logically and physically, from the remaining layers 21, 5 and 3.

Accordingly, layers 21, 5 and 3 may be embodied entirely within the first TCD, may be embodied entirely on a network resource external to the first TCD and invoke remote function calls on the abstractions of the core telephony functionality layer 9 to develop and execute telephony applications or may be embodied partially within the TCD and partially external to the first TCD. The TAO layer 23 may be programmed in an object-oriented programming language such as or JAVA, and may include abstractions corresponding to the abstractions defined by JTAPI.

AMENDED SHEET uL-u'--Vuu, uuu o/o -43- 1.4.4 Core Telephony Functionality API The core telephony functionality API 21 provides a programming interface to the core telephony functionality of the first TCD. The core telephony functionality API 21 may include several abstractions corresponding to the abstractions provided by JTAPI.

s For example, the core telephony functionality API 21 may include several abstractions written in that were patterned after the JAVA abstractions of JTAPI. The core telephony functionality API 21 may be implemented using the Pingtel Telephony API (PTAPI) available from Pingtel Corporation of Woburn, Massachusetts.

As described above, each abstraction of the core telephony functionality API 21 may have a well-defined state and a set of events that are triggered as a result of state transitions. Analogously to JTAPI, the core abstractions of the core telephony functionality API layer 21 may include abstractions for: a provider, an address, a terminal call, a connection, a terminal connection, a terminal and listeners. The core telephony functionality API layer 21 may be configured such that only privileged vendors have access to, and thus may manipulate, the core telephony functionality of the first TCD.

Telephony system architecture layers 9-15 provide the first TCD with core telephony functionality and a programming interface for privileged vendors to manipulate this core telephony functionality and add additional functionality to it. Thus, if the first TCD were deployed in the field with just layers 9-15, the telephony functionality of the first TCD could be expanded or modified only by vendors having privileged access.

Denying general access to certain core telephony functionality may be desirable so that the first TCD operates properly. For example, it may be desirable to limit access to abstractions defined in the core telephony layer that controls structuring a call set-up message to be in conformity with a particular call control protocol, for example, SIP.

Failure to limit such access may result in a third party vendor or user corrupting such abstractions such that the first TCD is incapable of sending messages onto the communications network in conformance with the SIP protocol.

On the other hand, it may be desirable to enable users and third party vendors to develop applications to be run on or in conjunction with the first TCD. Therefore, it may be desirable to have a telephony system architecture that is more open and extensible.

AMENDED SHEET UZ-U4-ZUUZ U.UUZ1b/t -44- Open API Layer Accordingly, the telephony system architecture 1 may include layer 5 to allow the telephony functionality of the first TCD to be expanded and modified after being deployed in the field.

The open API layer 5 includes abstractions that are the building blocks for applications developed for the application layer 3 by the API layer 5. For example, the open API layer 5 may include telephony framework classes written in the JAVA programming language and may include a JAVA virtual machine (JVM®) from Sun Microsystems, Inc.

The open API layer 5 provides open APIs for software developers to develop applications, including telephony applications and non-telephony applications, for the applications layer 3. To make the open API layer 5 open to software developers, the APIs of the open API layer, for example APIs 6, 7 and 8, and 10 may be distributed or made publicly available on the Internet. For example, one or more of APIs may be provided by the xpressa Development Kit T M available from Pingtel Corporation at http://www.pingtel.com.

The open API layer 5 may include one or more user interface APIs 6, one or more system APIs 7, one or more telephony APIs 8, and one or more media APIs 1.5.1 User Interface API A user interface API 6 assists a developer in developing a graphical user interface (GUI) for the first TCD. The user interface API 6 may provide a plurality of controls and forms for designing the GUI. For example, the user interface API may be the JAVA abstract window tool kit (AWT) or the xpressa Window Toolkit T M (xWT), an extension of Java AWT, available from Pingtel Corporation at http://www.pingtel.com.

1.5.2 Telephony API The telephony API 8 provides a plurality of abstractions for adding functionality to and for manipulating the functionality of the first TCD. The telephony API 6 may be JTAPI from Sun Microsystems, Inc., or an implementation thereof. The JTAPI specification is available at http://iava.sun.com/products/itapi/. Accordingly, the telephony API 6 may include a plurality of abstractions corresponding to JTAPI, including abstractions for: an address of the first TCD, telephone calls in which the first TCD is participating, connections included within these telephone calls, one or more AMENDED SHEET

PCT[USOO/

2 9 5 76 WO 01/31900 providers that provide telephony services corresponding to the first TCD, a terminal orrespondingders t the first TCD, etc. Other abstractions may include Observers, Listeners, Exceptions, events, states, methods associated therewith, or any other abstractions provided by JTAPI.

Other telephony APIs 8 may include simplified versions of JTAPI for more Other telephony APIs 8 may APIs 6 may include the simple streamlined and easier use. For example, the telephony As 6 may include the simple telephony API (STAPI) available from Pingtel Corporation at httM:/ ww.in el-.om In addition to event abstractions and listener interfaces, the telephony APIs may include hooks to evenhat allow application developers to affect certain time-critical behaviors include hooks that allow aPP o ev o p AV A method, that is invoked by t0 of the first TCD. A hook is a method, for example, a JA n astratio if a event of a sefed type occurs. For example, each of the telephony an abstraction if an event of a specified affect the processing of caller- APIs 6-8 may provide hooks that allow a developer to affect the processing of callerinformation, the redirecting or filtering of phone calls, and determining how the first TCD indicates to a user that a call is incoming. For example, the first TCD may indicate Is that a call is incoming visually, for example, by blinking a light, audibly, for example, by beeping, or by any combination thereof.

The open API layer 5 also may include a language interface to interface abstractions defined by the open API layer 5 with abstractions defined by the core telephony functionality layer 9, in particular, abstractions defined by the TAO module 23. For example, if the one or more APIs of the open API layer 5 are defined in Java, and the TAO object module is defined in the language interface may be the Java Native Interface

(JNI).

1.5.3 System API telephon system The system API 7 provides system-wide tools for the telephony system architecture 1. For example, the system API may include an application manager for starting, stopping, loading, unloading and monitoring applications running in the application layer 3. Further, the system API 7 may include an application arbitrator to application layer 3. Fur ,and to resolve connicts regulate applications, prevent conflicts between applications, and to resolve conflicts between applications. The system API may provided as part of the xprcssa Development Kit

T

1.5.3.1 Application Manager te ft The application manager may consist ofa web server residing that enables the loading and unloading of applications onto the first TCD. ccrdingly PCT/USOO/2 957 6 WO 01/31900 -46user may use a web browser to access the web server. This web browser may reside on a user may use a w eb b r owsertoac tes o such as a computer. For example, as the first TCD itself, or on another network resource such as a computer. For example, as described below in relation to Fig. 7, if the first TCD is embodied as a telephone, it may be desirable to install the web browser, and other tools, on a computer to provide an be desapplications developer or other person access to the computer's more extensive resources memory, video monitor, keyboard, mouse) to develop and upload applications.

To add an application to the applications layer 3 through the application manager web server, a user may specify a location and file name. For example, through the web browser, the user may specify a URL at which the executable file, for example, a JAVA browser, the user may specify a URL at to archive (.JAR) file, is located. lication manager web Depending upon the configuration ofthe first TCD, the application manager web server may store the specified file on the first TCD itself, store the specified file on another network resource and maintain a pointer to that location, or store a pointer to the URL specified by the user. application n e through To uninstall an application, a user maly enter the application name through the web browser, and the application manager web server will de-install the specified application.

The application manager may be implemented using other types of applications besides a web-based client/server application.

1.5.3.2 Application Arbitrator The applications arbitrator may be configured to provide two general functions, security and conflict resolution. for the first TCD by regulang The applications arbitrator may provide security for the first TCD by regulating the addition, modification and execution of applications. For example, the applications arbitrator may require an application being installed, or modified and re-installed, on the first TCD to meet certain criteria. For example, the application may have to register a list of first TCD resources, abstractions, that the application when executed is going use. The application arbitrator may be configured to reject the application if the application does not include such a list.

If the application does include a list, after inspecting the list, the applications arbitrator may reject the application, requiring the application to be modified to not use certain resources. Altcrnatively, the applications arbitrator may accept an application, PCT/US00/2 9 5 76 WO 01/31 9 00 47 The application ait may be and attach an indication of approval to the application, so that the application may be installed and executed on the first TCD.

The application arbitrator may be configured to accept or reject applications automatically, or may provide a user interface to allow a user, a systems administrator, to review the list of resources for each application and manually accept or reject the application.ed to appl on The applications arbitrator also may be configured to monitor the application during execution. If the application uses a resourc that it did nt register with the application arbitrator, the application arbitrator may prevent the application from to executing any further.

The other general function provided by tIe applications arbitrator is conflict resolution. On typical communications networks, conflicts may occur between telephony functions running on the communications network. Historically, PBX-based telephony networks have tested for possible conflicts and worked to provide appropriate Sbehavior if a conflict occurs. On a communications network having one or more TCDs behavior if a conflict occurs. each TCD may h a ve a u ue with modifiable and expandable functionality, however, each TCD may have a unique set of applications defined thereon and, consequently, a more diverse array of conflicts may occur. Therefore, it may be desirable to apply more proactive techniques for addressing these potential conflicts, including techniques to prevent conflicts between applications and techniques to identify and resolve conflicts if they do occur.

Accordingly, the application arbitrator may be configured to resolve conflicts between two or more applications residing or being executed on the TCD As discussed above, applications may communicate with abstractions of the core telephony functionality layer 9 to monitor telephony events. Specifically, applications may register to be notified as a result of an event occurring. To deal with conflicts between applications, first, for events for which two or more applications are registered to be notified, the application arbitrator may be configured to define an order in which the applications are to be notified. Second, the application arbitrator may be configured to define whether an application either a) handles and relays a telephony event, or b) consumes and does not relay a telephony event.

If an application handles an event, after the application executes functionality in accordance with the occurrence of the event, the application then notifies the next registered application of the occurrence of the event. If an application is defined to PCTIUS00129576 WO 01/31900 -48consume an event, then after the application executes functionality in accordance with the occurrence of the event, the application does not notify any further registered applications of the occurrence of the event.

For example, a call waiting application may be configured to monitor a current call event defined by the call processing module 31 for any state changes, and may monitor incoming call events from the network to determine if a new call is inoming. If the state of the current call has not changed the telephone call is still ongoing), then if an incoming call event occurs, the call waiting application may either handle the event which triggers call waiting and also passes information about the new incoming to call to any other applications that have registered for such notification; or consume the event, which triggers call waiting, but does not pass any information about the new call to any other applications, even those applications that are registered for automatic notification. For example, even though a call forwarding application may be registered to be notified when an incoming call occurs, if the call forwarding application comes after the call waiting application, and the call waiting application is defined to consume the incoming all event, then the call forward application will not be notified of the incoming call or receive any information regarding the incoming call. By preventing the call forwarding application from being notified about the incoming call, a conflict between the call waiting application and the call forwarding application has been avoided.

1.5.4 Media

API

Although the telephony API 8 enables a developer to develop a telephony application using well-defined relatively higher-level building blocks, abstractions provided by JTAPI, it may be desirable to design a more-specialized media processing application using lower-level media processing building blocks.

Accordingly, the media API 10 may provide tools to allow a developer to directly access and manipulate media abstractions of the media processing module 29, described in more detail above in relation to Figs. 3 and 4. A developer may develop a specialized media processing application to run on the first TCD by using the media AP[ 10 to define custom media functions, for example, by invoking methods of the media processing controller 115 to link, create and destroy media processing elements.

For example, the media API 10 may be used to create and combine various media processing elements of the media processing module 29 to develop an application that UU-'UU-LUU UUZU/b -49allows two or more participants in a conference call to conduct a side conference during the conference call, or an application that enables streaming audio conforming to a specific protocol, MP3, to be mixed into a telephone call, or an application implementing a customized voicemail system on the first TCD.

Telephony applications of the applications layer 3, and other higher-level abstractions, may use the media processing controller 115 to dynamically create media processing components 30, and to link media processing elements during a telephone call. Further, a telephony application may be defined to configure media processing elements in unique ways to create custom media processing abstractions for a particular l0 feature provided by the telephony application.

2. Telephone Implementation of a Telephony Communication Device Fig. 5 is a diagram illustrating an example embodiment of the first TCD as a telephone 200. The telephone 200 may be a desktop telephone having a connection to the network medium of the communications network. For example, the telephone 200 may be a desktop LAN-connected telephone such as the Pingtel xpressa T M by Pingtel Corporation of Woburn, Massachusetts, and may have an ornamental design as shown in U.S. Design Patent Application No. 29/120,479 entitled, "Telephone Base," by James A.

Batson, Jr. et al., filed March 20, 2000.

Alternatively, the first TCD may be implemented in a more compact form, for example, a battery-operated wireless telephone such as an analog mobile telephone, a Personal Communications Service (PCS) wireless telephone, or a third generation (3G) wireless telephone.

As shown in Fig. 5, the telephone 200 provides a user interface, including a telephone base 202 and a handset 204. The telephone base 202 may include: a display screen 206; a scroll wheel 208; context-specific buttons 210; more button 212; dialing buttons 214; volume buttons 216; telephony function buttons 218; and speaker phone button 220 corresponding to base speaker/microphone 222, and visual indicator 224.

The dialing buttons 214 may be used for dialing telephone numbers.

Alternatively, the telephone base 202 may include other interface controls, for example, a rotary dialer, for entering a telephone number.

Each of the telephony function buttons 218 may be used to perform a specific telephony function, for example, activating/de-activating the handset, transferring a call, muting the microphone base, conference call, and placing a call on hold. Further, each AMENDED SHEET PCTUSOO/2 95 76 WO 01/31900 button 218 may have an associated visual indicator that is lit while the button is active.

For example, for a hold button 218, an indicator associated with the button 218 may be lit if a call is on hold.

The visual indicator 224 may be used to indicate one or more telephony events, for example, that a user of the telephone 200 has voice messages or that a call is incoming. Other visual indicators may be induced on the telephone 200.

The display screen 206 may be a liquid crystal display (LCD) and may display data and other information supplied by an application. Further, the display screen 206 may be designed with logic to be touch-sensitive such that selections and entries may be entered on the display screen 206 by touch. User interface controls 208, 210 and 212 may be used to access the displayed data and information- The scroll wheel 208 may be integrated with the graphical user interface such that it may manipulate the position of information on the display screen 206, and may be used to select items displayed on the display screen 206. The scroll wheel 208 allows a user to interact with pages of content displayed on the display screen 206. A user may use the scroll wheel to change information displayed on the display screen 206 by scrolling or browsing down through the data, and then may select a specific item.

One or more applications may configure the scroll wheel to be application dependent. Such applications may provide multiple options for both the scrolling and selecting activities so that applications may be configured with a desirable combination of these activities.ved may determine foard or The direction in which the scroll heel 28 is moved may determine forward or reverse progress through the content displayed on the display screen 206. For example, a clockwise rotation may cause forward movement through the content, and a counter clockwise rotation may cause reverse movement through the content, or vice versa.

A detent is a device that checks motion. The scroll wheel 208 may use detents to provide feedback to the user. Each momentarY stop that occurs while the scroll wheel is turned indicates that a new position has been reached. Optionally, the scroll wheel 208 may be configured such that it may be turned continuously in either direction, each detent indicating a single forward or reverse movement, and the scrolling rate may be stable from detent to detent.

Alternatively, the scroll wheel 208 may be configured such that the extent to which the scroll wheel 28 may be turned is limited to a particular number, for example, -Uz-U4-_UUUZ UbUU29576 -51 three, detent positions in each direction, and increasing resistance may be provided as the wheel is turned. Further, as a result of a user releasing the scroll wheel 208, it may automatically return to a detent representing a rest position between the sets of directional detents.

The scroll wheel 208 may be configured such that users may select a particular scroll rate using the detents. Alternatively, scroll rates may be fixed or may be a combination of fixed and variable. Table 1 below illustrates various rate options for given scroll wheel positions with which the scroll wheel 208 may be configured.

Scroll wheel position Fixed rate option Fixed and Variable rate ______option rest 1 st detent fixed, slow rate fixed, slow rate 1 st 2 "d detent fixed, medium rate fixed, medium rate nd 3 rd detent fixed, fast rate accelerating, fast rate Table 1 For the combined fixed and variable rate option, an A-D converter may be used to sense the scroll wheel position.

The telephone 200 may be configured with a variety of GUI methods to select an item from the display screen 206. For example, the more button 212 may be configured to access advanced features such as menus, help and other applications. For example, the more button 212 may be configured such that, if it is pressed, the display screen 206 may present tabs for listing and launching applications installed on the first TCD, getting context-specific help, and listing functions provided by an application.

On every page of content that is presented on the display screen 206 as the user scrolls, one item may be highlighted. Such an item may be highlighted by a visual cue, for example, reverse video or other visual highlighting, or by an indicator positioned next to the item such as an arrow or icon.

Context-specific buttons 210 also may be provided. If an application is configured to use these buttons 210, then in accordance with the application, on each page of content displayed on the display screen 206 as the user scrolls, one or more items may be listed so that they align with the context-specific buttons 210. Pressing a context-specific button 210 corresponding to an item selects the corresponding item and allows the application to proceed. Optionally, the item corresponding to the pressed AMENDED SHEET PCTIUSO/29 5 76 WO 01/31900 52context-specific button 20 is selected for further application processing even if another item is currently highlighted by a visual cue such as reverse video.

Thus, the function of each button 210 depends on the content being displayed on the display screen 206. Specifically, each button 210 corresponds to a item of content s being displayed at a particular location on the display screen 206.

For example, referring to Fig. 6, the display screen 206 is displaying a list of applications. The buttons 210 along the left and right-hand side of the display screen 206 each correspond to a particular application item. If a user presses one of these buttons, the application corresponding to the button will be executed, which may result in the display screen 206 now displaying new content specific to that application The content-specific buttons 210 along the bottom of the display screen 206 may determine the body of content to be displayed on the display screen 206. For example, in Fig. 6, each button 210 corresponds to a tab at the bottom of the display screen 206, Fig. 6, each button 20of content to be displayed.

where each tab corresponds to a different body of content to be displayed.

A first application may configre the display screen 206 such that if th content, a list, to be displayed by a second application does not fit on the display screen, a slider may indicate on the display screen 206 a position of the content being displayed relative to the entire content to be displayed by the second application.

Figs. 5 and 6 illustrate example embodiments of a telephone and a user interface for implementing a TCD. These embodiments are for illustrative purpes as several other embodiments of telephones having any of a variety of configurations may be used to implement a TCD as described herein.

3. Communications Network The communications network on which the first TCD resides may have any of a variety of configurations. For example, the communications network may include merely a network medium and two or more TCDs. Although the communications merely a network medium and two or mobased network having wire (Le., network is primarily described herein as being a wire-based network having wire cable) as the network transmission medium, the communications network may be any of a variety of types of networks adhering to any of a variety of wireless protocl, e.g., protocols for PCS networks, protocols for 3G networks or the wireless Etheret protocol defined by IEEE 802.11, and having any of a variety of network transmission media, such as carrier waves and fiber optic cables. Further, as is described below in relation to Fig. 7, the communications network may include a plurality ofsub-networks or .UZU4_;UU;_ UUU~ b/b -53segments, where each sub-network may include any of a plurality of transmission mediums.

Fig. 7 is a block diagram illustrating an example embodiment of a communications network 300. The communications network 300 may include a network transmission medium 332 and a plurality of TCDs including 302 and 306. The communications network 300 may be configured such that no other network resources are necessary to conduct a telephone call between two or more of the TCDs. For example, each TCD may be configured such that all of the telephony applications to be executed on the TCD reside completely on the TCD. Further, each TCD may be configured such that all of the data necessary to set-up a telephone call, including the network address of each participant of the telephone call, and any data necessary to execute any applications, also are stored entirely on the TCD.

Alternatively, the communications network 300 may be more distributed, including one or more other network resources to store data applications and parts of applications, and to assist in performing one or more telephony applications.

Accordingly, the communications network 300 may include one or more companion devices, for example, companion devices 304 and 310, one or more directory databases, including directory database 308 and directory database 320, a TCD deployment server 314, one or more application servers 318, one or more call control servers 322, one or more network interfaces, for example, an IP/PSTN Gateway 326, and one or more management databases, for example, management database 316.

The communications network 300 may be divided into a plurality of subnetworks or segments. For example, network elements 302, 304, 308 and 310 may reside on a network transmission medium 334 separated from network transmission medium 332 by one or more network interface elements 312. The one or more network interface elements 312 may be routers, bridges, switches, media gateways, microwave transmitters/receivers, cellular PCS network elements, or any combination thereof that control the transmission of data between network transmission mediums 334 and 332.

For example, network elements 302, 304, 306, 308, 310 and 334 may be part of a customer network 340, and network elements 314, 318, 322, 326, 316, 320, 323 and 332 may be part of a service provider network 324.

The communications network 300 may include an IP/PSTN Gateway 326 for setting up a phone call between a TCD on the communications network 300, TCD AMENDED SHEET PCTIUS00/29 576 WO 01/31900 -54- 302, and a TCD on the PS1 for example, TCD 334. Depending on the configuration of communications network 300, a different type of gateway may be used to communicate with TCD 334 on the PSTN.d call control messages conforming The IP/PSTN Gateway 326 converts media and ca on mese k 3 00 ono to one or more IP protocols and received from th om municos netwo 3 to media and call control messages conforming to PSTN protocols o be on PSTN. Converselythe IPPSTN gateway may be configured to also convert PSTN m edia and call control messages from the PSTN into IP media and call control messages media and call control messages o e to be transmitted onto the communications network 300.

As described above, a TCD 302 may be any of a plurality of devices including a As described above, ae r TCD 302 may be any o i s a telephone, for example, the telephone 200 of Fig. 5, or a computer. If the first TCD is a telephone, it may desirable to provide a companion device to provide additional resources for the telephone, including additional telephony functionality, data storage, and an environment for developing telephony applications.

For example, at a user's home or office, a user may have a TCD embodied as a telephone for participating in telephone calls, and may have a general purpose computer for a variety. of other tasks. Although the user's telephone may have more desirable ergonomic features for participating in the telephone call, the general purpose computer may have a purality of features more desirable for developing applications and storing, retrieving, and manipulating data- For example, a general purpose computer may include peripherals such as a video monitor, a keyboard and a mouse that the telephone embodiment of the TCD lacks. Further, the general purpose computer may have more extensive memory for storing data and applications and for running applications.

To develop applications for a TCD, a companion device may include a plurality of APIs, including the APIs described above in relation to the open API layer and the core telephony functionality API layer 21. To load these applications onto a TCD, and unload applications from the TCD, a companion device may include an applications manager such as that described above in relation to the system API 7.

A companion device also may be loadedwith management software for managing various aspects of the communications network 300. For communicating and sharing data with other network resources, particularly TCDs, a companion device may sharing da ,h oherp tocs including the Simple be configured to communicate using a number of protocols, including the Simple Network Management Protocol (SNMP), the Hypertext Transport Protocol (HlTTP), PCT/US00/2 9 57 6 WO 01/31900 55 Remote Method Invocation (RMI), the Hypertext Mark-up Language (HTML), and the File Transfer Protocol (FTP).infoation about other users, The directory database 308 may store a variety f i o ot o user TCDs, other network resources, or the communications network 300 itself. Thus, a user TCDs, other network resources, to reach another user to set-up a telephone s may access this information to determine how to a or ur to erial diteleory call. For example, the directory database 308 may Sore le from Microsoft Corporation or phonebook product such as Microsoft Outlook avilable r icr o ion or Lotus Notes® available from Lotus Development Corporation. These commercial software products may reside on the TCD itself or on a companion device to the TCD and may be configured to access the directory database 308 for information- da Other directory databases, such as the director database 320, may store data for one or more directory servers 323, as is described below in more detail.

As described above in relation to Fig. 1, one or more telephon applications may be stored and executed entirely on a TCD, one or more applications may be distributed such that at least part of the application is toed on another network resource, and one or more applications may be stored remotely from the TCD on another network resource, where the TCD maintains pointers to the remote applications. The one or more application servers 318 may serve as network resources that store one or more applications and parts of at least one or more applications.r For example, an application server 38 may inclde a voicemail application or more the server side of a client/server application, where the client side resides on e o more TCDs. Further, although a TCD may support confrence bridging, as described above in relation to Figs. 3 and 4, if the number of connections involved in the conference call becomes too great, it may be more efficient to perform the conference bridging with a conference bridging application resident on an application server 318 that has more resources, or resources more dedicated to conference bridging.

The communications network 300 may include one or more directory servers 323 for directing calls between TCDs. Each directory server 323 may include a pluralitY of directories or indexes that map a user identifier such as a telephone number, logical name or extension name to a network address, for example, an IP address. This network address may be the network address of a TCD assigned to the user, or may be an address of another directory server that may store the network address of the TCD assigned to the user, or may be the network address of an IP/PSTN Gateway, for example,

IP/PSTN

PCT/USOO/2 9 576 WO 01/31900 -56- Gateway 326. One or more of these directories may be stored on the directory database 320 that is accessible by the directory server 323.

For example, a first network address directory may include a plurality of entries, each entry corresponding to a telephone number, for example, 123-456-7890. Each entry S may store a network address, for example, 10.20.30.40, corresponding to the telephone number. receiving a telephone number, As a result of the first network address directory eceivig a telephone number lookup and access the entry in the directory the first network address directory may ookup and aess the eI address contained server corresponding to the telephone number and re the addr ne therein. A first network address directory, as well as the second and third network address directories described below, may be configured to use this retrieved IP address in any of a variety of ways, as described in more detail below.

The directory server 323 or the directory database 320 may also include a second network address directory, where each entry of the a second network address directory corresponds to a logical name, 'ismith cmecom, of a user of the communications network 300. Each entry may store an IP address associated with the logical name.

Upon receiving a logical name, the directory server 323 may lookup and access the entry corresponding to the logical name and retrieve the IP address stored therein.

The directory server 323 or directory database 320 also may include a third Snetwork address directory se where each entry corresponds to an extension, for example, x1234@acme.com. Each entry may include an IP address associated with the extension Upon receiving an extension, the directory server 323 may look up and access the entry Upon receiving an e on,t P address stored therein.

corresponding to the extension and retrieve the address stored therein.

Although the network address directories have been described above as separate entities, any combination of these network address directories may be combined to form one or more directories. h d a t As described above, a TCD may store or have direct access to one or more network addresses corresponding to one or more TCDs, respectively. If a first TCD stores or has direct access to the network address ofa second TCD, the first TCD may set-up a call with the second TCD directly by using a peer ee potocol such as SIP or H.323. A h, directlv by sending a SIP set-up For example, TCD 302 may contact i-D 302 to infm TD message to TCD 306, and TCD 306 may reply directly to TCD u* -u-Luu, U5UU2, /b -57that it is willing to participate in the telephone call. Lastly, TCD 302 may send an acknowledgement message to TCD 306 to acknowledge that it received the response message from TCD 306. An analogous method may be applied to establish a telephone call between TCD 302 and TCD 334, except that the IP/PSTN Gateway 326 would serve as a network interface between communications network 300 and the PSTN.

Alternatively, TCD 302 may not store or have direct access to the network address of TCD 306. The TCD 302, however, may store or have direct access to other user identifiers of the TCD 306, for example, a telephone number, logical name or extension of TCD 306. Accordingly, the TCD 302 may communicate with a directory server 323 to determine the IP address corresponding to one or these indicators, as described above.

If TCD 302 sends the user identifier to the directory server 323, the directory server 323 retrieves the network address corresponding to the TCD 306. Depending upon the configuration of the directory server 323 and the TCD 302, the directory server 323 may take any other plurality of actions. For example, if the directory server 323 is configured similar to a SIP proxy server, the directory server 323 may forward a call setup message to TCD 306, which would respond to the directory server 323, which would then forward the response message to TCD 302.

Alternatively, if the directory server 323 is configured similar to a SIP redirect server, the directory server 323 may send the determined network address back to TCD 306, which would then send a call set-up message to the determined network address.

As discussed above, however, each entry of a directory server 323 also may include an IP address of another network resource another directory server. The directory server 323 may be configured to send the received identifier to the other network resource to perform further look-ups to determine the network address of the user. If the network address retrieved is the network address of another directory server, and the directory server 323 is configured similar to a SIP proxy server, the directory server 323 may forward the call set-up message to the other directory server, and repeat the lookup process. Such communications between directory servers, and the lookups performed thereon, may be repeated until the network address of the user is determined.

If the network address retrieved by the directory server 323 is the network address of another directory server, and the directory server 323 is configured similar to a SIP redirect server, the directory server 323 may send the retrieved network address to AMENDED SHEET PCT/US00/2 9 5 76 WO 01/31900 -58the TCD 302. The TCD 302 then may access the other directory server, and repeat the lookup process. Such communications between directory servers and the TCD 302, and the corresponding lookup process, may be repeated until the network address of the user is determined.

Further, an entry in the directory server may include multiple network addresses corresponding to a single identifier. For example, for a customer service telephone number, the customer service telephone number may map to a plurality of network addresses. Consequently, the directory server 323 may include logic to determine which network address to contact, and either send a call set-up message to the determined to address, or send the determined address to the TCD 302.

As described above, for telephone numbers corresponding to a TCD that reside on the PSTN, for example TCD 334, the directory server 323 may retrieve an IP address of an P/PSTN Gateway,for example, the IP/PSTN Gateway 326. The network address retrieved by the directory server 323 may determine a network address of an IPIPSTN Gateway, for example, the network address of IP/PSTN Gateway 326 that is located most closely geographically to TCD 334. Depending on the configuration of the director server 323, th directory server 323 may either forward a call set-up message to another network resource that will forward the message along to the appropriate IP/PSTN gateway, or may send the network address to the TCD 302 and allow the TCD S302 to contact the appropriate IP/PSTN Gateway 326 on its own.

20 the TCD 302 is configured to use a master/slave call control protocol to set-up telephone calls, then, to set-up a telephone call, the TCD 302 may send a call set-up message to a masterlave controller322. The master/slave control 322 then may set-up the telephone call using the directory server 323 and directory database 320 using analogous techniques to those techniques described above with respect to a TCD 302 configured to use a peer-to-peer protocol. he 0 0 Similarly, for telephone calls coming into the communications network 300, for example, by IP/PSTN Gateway 326 or by a network switching element such as a switch, router, bridge or hub, the directory server 323 may be contacted to determine a network address of a call recipient For example, ifTCD 334 attempts to set-up a call with

TCD

302, the IP/PSTN Gateway 326 will convert the set-up message to a set-up message conforming to a default call control protocol being used by the communications network WO 01/31900 PCT/US00/295 76 -59- 300. The IP/PSTN Gateway 326 will then forward the call set-up message including the user identifier to the directory server 323 to determine the network address of TCD 302.

Several other techniques may be used to direct telephone calls to the appropriate user and TCD.

A TCD that the TCD 302 is trying to set-up a call with may be configured to setup calls using a call control protocol different than the call control protocol of the TCD 302. For example, the TCD 302 may be configured to use the SIP protocol and TCD 306 may be configured to use the H.323 protocol. Accordingly, the directory server 323 may be configured to determine the call control protocol that a network address supports and 0o send this information to the TCD 302, or the TCD 302 may be configured to determine that a network address returned by the directory server 323 corresponds to a certain call control protocol.

If the TCD 302 is configured to be able to communicate using the H.323 protocol, then TCD 302 may communicate with TCD 306 using the H.323 protocol. If, however, TCD 302 is not configured to set-up a telephone call using H.323, then TCD 302 may send the SIP message to an H.323/SIP signaling gateway. The H.323/SIP signaling gateway may convert the SIP message to an H.323 message. Accordingly, the H.323/SIP signaling gateway can send the generated H.323 message to TCD 306, and when TCD 306 responds with an H.323 message, the H.323/SIP signaling gateway may convert this H.323 message to a SIP message and send the SIP message to TCD 302.

In an embodiment of the communications network 300, the network 300 may be configured to identify a call agent for each call that comes in to the network. For inbound calls, the associated call agent may be a SIP proxy server, an MGCP call agent, an H.323 gatekeeper, or an agent used by another call signaling protocol.

As a number of TCDs 302 on the communications network 300 grows, it may be desirable to delegate telephony applications that may be provided by TCDs themselves to other network resources, for example, TCD deployment server 314. The TCD deployment server 312 may be configured with a plurality of telephony applications that also may be configured on a TCD. The TCD deployment server 314 may include applications to configure and manage TCDs, perform software upgrades on TCDs, determine which applications should be installed on which TCDs, configure a plurality oFTCDs into hierarchical groups that may have multiple tiers of hierarchy, for example: geographical region, metropolitan region, business division, business department, PCT(USOO/2 95 76 WO 01/31900 building, floor, and group, down to a user. The TCD deployment server also may provide several other services to a TCD.

The TCD deployment server 314 also may maintain personal TCD configuration information specific to a user of the communications network 300. Accordingly, inforegardless of where on the network a user uses a TCD, the user may indicate a unique identifier to the TCD deployment server 314, and the TCD deployment server 314 may configure the TCD that the user is using according to the personal configuration information of the user.

informaThe TCD deployment server 314 may store the applications and data described The TCD deploymenbserve3 maman e database 316 may be any of a I0 above in a management database 316. The management database 316 may be any of a plurality of types of databases including an object-oriented database, a relational database, or a flat file database. Further, the TCD deployment server 314 may be configured to access the management database 316 using a plurality of techniques, including Open DataBase Connectivity (ODBC) techniques or Java DataBase Connectivity (JDBC) techniques. Further, to communicate with other network resources, including one or more TCDs and companion devices, the TCD deployment server 314 including one or more smber of protocls including SNMP, may be configured to communicate using a number of protocol including

SMP,

HTTP, RMI, HTML, and FTP.

The communications network 300 may be configured in any of a variety of ways, and the configuration of Fig. 7 is provided for illustrative purposes only. Several other network configurations may be used.

4. Telephony Applicationstem architecture As described above, the open and extensible telephony system architecture

I

provides the ability to develop applications using the core telephony functionality layer 9 and the open API layer 5, respectively. Accordingly, the plurality of applications now described may be implemented using the open API layer 5, the core telephony functionality layer 9 or any combination thereof. Further, such applications may be run on one or more TCDs, one or more other network resources, or a combination thereof.

Several of the applications described below define sending/receiving information, including media, audio or video, textual data, instructions, or other information to/from one or more TCDs either during a telephone call or to set-up a telephone call.

The information that is sent/received may depend on a state of the first TCD or the other PCT/USOO/2 9 57 6 WO 01/31900 -61- TCDs. Further, the action taken by a TCD as a result of receiving this information may depend on a state of the receiving TCD.

Further, each of the applications defined below may be configured such that the application may be added to the first TCD or modified after the first TCD has been deployed on the communications network, for example, by using one or more APIs of the open API layer 5, as described above.

Further each of the applications described below may be embodied as computer signals on any of a variety of computer-readable mediums, for example, a readable and writeable nonvolatile recording medium, such as a disk, a flash memory, a memory stick, to a PC Card or a tape. Such a disk may be removable, for example, a floppy disk or a read/write CD, or permanent, known as a hard drive.

Accordingly, the applications described below may access one or more abstractions of the core telephony functionality layer 9 to determine a state of a TCD or a telephone call on the TCD, and may control one or more media processing elements of the media processing component 30, described above, to process media in accordance with the application.

Awfirst telephony application may be configured to permit a caller from a TCD to have control over the sound that plays on the callee's TCD to indicate an incoming call from the caller. The sound may be played from an audio file accessible by the callee, for example, an audio file stored on audio storage medium 60, may be coded within the tone generator 69 of the callee's TCD, or the sound itself may be sent from the caller's TCD to the callee's TCD. The sound may be a ring, a voice announcement, or any sound that will be meaningful to the person being called. The sound may play intermittently until canceled by the callee, and may be broadcast over multiple TCDs on the communications network, for example multiple customer service TCDs. Such an application also may be used by the caller to "page" another TCD, but not set-up an actual telephone call.

The sound to be played may be pre-recorded, for example, by capturing the sound through the phone mouthpiece or through a direct electrical audio signal capture jack on the phone, and then storing the sound on the TCD itself or on an accessible network resource. Both the callee's and caller's TCD may be configured to control the manner by which the sound is played, for example, by a programmer of the telephony application or by the caller or callee through user parameters provided by the telephony application.

WO 01/3190 0 PCT/US00/2957 6 -62- Fig. 8 is a flowchart illustrating an example embodiment of a method of indicating an incoming call to at least a second user of a second TCD. Such a method may be defined by one or more telephony applications.

In Act 452, a dialing instruction corresponding to a network address of the second TCD is received. Next, in Act 454, the first user is identified from a dialing instruction, and in Act 456, a sound to be played is selected based on the identification.

In a following Act 458, a call set-up message is sent to the second TCD at the network address. The call set-up message includes information to cause the second

TCD

to produce the selected sound. The information included in the call set-up message may io include information representing the selected sound or instructions to play the selected sound. Further, the information may include a location from which to play the selected sound, for example, a URL.

Another telephony application may enable multiple audio inputs received during a conference call between TCDs to be selectively mixed or muted, as described above in relation to the local call bridge 51 of Fig. 3. Accordingly, a user of the first TCD participating in a conference call may selectively mute or enable the audio streams of other conference call participants. Further, such an application may be configured to permit a user on a second TCD that is not controlling the conference call to send a communication to the first TCD instructing the first TCD to selectively mix audio received from and/or sent to the second TCD. As a result, announcements can be made to a selected subset of participants and questions directed to another subset, or the comments of specific individuals screened out of the conference temporarily.

Although selectively mixing and muting audio signals has been described herein primarily in connection to bridged conference calls, similar techniques may be used to selectively mix and mute audio for fully-meshed conference calls, where each TCD maintains a representation of every connection included in the conference call. Although such a fully-meshed conferencing configuration reduces the load on a single TCD the TCD that would otherwise provide the bridging), this configuration creates more network connections thus increasing network traffic and also makes controlling the conference call more complicated as now multiple TCDs are involved.

Further, to implement selective muting and mixing during a telephone call, one or more specialized versions of a TCD may be provided, each containing extra signal processing power for mixing/muting.

IWO 01/31900 PCT/US00/29576 -63- Fig. 9 is a flowchart illustrating an example embodiment of a method 460 of selectively transmitting media during a conference call including a first user input for receiving media from the first user and two or more connections between the first TCD and two or more second TCDs, respectively. Each second TCD corresponds to a second user. Such a method may be defined by one or more telephony applications.

In Act 462, a user selection is received that identifies one or more third users to include in receiving media from one or more fourth users. Each third user and fourth user is either the first user or one of the second users.

In a next Act 464, during the conference call, one or more media inputs are received from one or more of the fourth users. In a following Act 466, during the conference call, the one or more third users are permitted to receive media produced from the one or more media inputs.

Fig. 10 is a flowchart illustrating another example embodiment of a method 470 of selectively transmitting media during a conference call that includes a first user input for receiving media from the first user and two or more connections between the first TCD and two or more second TCDs, respectively. Each second TCD corresponds to a second user. Such a method may be defined by one or more telephony applications.

In Act 472, a user selection is received that identifies one or more third users to exclude from receiving media from one or more fourth users. Each third and fourth user is either the first user or one of the second users.

In a next Act 474, during the conference call, one or more media inputs are received from one or more of the fourth users. In a following Act 476, during the conference call, the one or more third users are prevented from receiving any media produced from the one or more media inputs.

In both methods 460 and 470, the media produced from the one or more media inputs may be media mixed in any of the variety of ways described above. Further, for both methods 460 and 470, the one or more third users may be permitted or prevented from, respectively, receiving media by using the local call bridge 51 of Fig. 3 as described above. Also, for both methods 460 and 470, the received user selection may be received from the first user of the first TCD or from one of the second users.

Another telephony application may define a method of communicating, as part of a telephone call, textual information from a first user of the first TCD to a second user of a second TCD connected to the first TCD by a first connection. Specifically, during the WO 01/31900 PCT/US00/29576 -64telephone call, textual data defining text may be received on the first connection from the second TCD. The first TCD may then display the text defined by the textual data, for example, on display screen 206 of Fig. 5 described above. Such textual data may be any of a variety of data, for example, information about the second TCD or a user of the second TCD.

A scheduling application may be defined to allow a user to schedule a telephone call, for example, a conference call. Using a user interface as described above in relation to Figs. 5 and 6, or another network resource such as a companion device 304 of Fig. 7 described above, a user can schedule a telephone call by inputting telephone numbers of each of the telephone call participants and the date and time of the call. Further, if a remote conference bridge, not the local call bridge 51, is be used to perform the telephone call, the user may configure the scheduling application to call the remote conference bridge to set-up the conference call.

Such a scheduling application may interface with and access data from a database such as that provided by Microsoft Outlook® or Lotus Notes®, and may be configured to use the Internet Calendar and Scheduling Protocol (ICalendar) for communicating between the first TCD and any other TCDs or network resources involved in scheduling the conference call.

Such a scheduling application may be configured such that after all the telephone call information, including the identifications of the participants and the date and time of the call, has been entered, the application automatically notifies the other participants about the scheduled call. This notification may provide a variety of information to the other participants, including the date and time of the call, and the identities and information regarding the other call participants.

The scheduling application may be configured to notify the otfier participants in the telephone call by sending an electronic mail (email) message, for example, an e-mail message conforming to the Simple Mail Transfer Protocol (SMTP).

Fig. II is a flowchart illustrating an example embodiment of a method 480 of scheduling and performing a telephone call between a first user of the first 'TCD and one or more second users of second TCDs. In Act 482, one or more user identifiers are received, where each user identifier identifies one of the second users. Such a method may be defined by one or more telephony applications.

WO 01/31900 PCT/US00/29576 In a next Act 484, date and time information is received that specifies a future date and time to conduct the call, and in Act 486, the user identifiers and date and time information may be stored. The identifiers and date and time information may be stored locally on the first TCD or on a remote network resource accessible by the first TCD.

In a following Act 488, at the date and time specified by the date and time information, the user identifiers are accessed. Next, in Act 490, a telephone call may be initiated between the first TCD and the one or more second TCDs.

Method 480 also may include acts of receiving a conference bridge identifier identifying a conference bridge, wherein the act of initiating the conference call includes calling the conference bridge. Further, the method 480 may include notifying the one or more second users about the call before initiating the telephone call by sending a message including information about the call from the first TCD to the one or more second TCDs.

A web-based dialing application may provide web-based dialing by defining a web server embedded within the first TCD to set-up telephone calls. The web-based dialing application may be configured to allow a user to create a web page on the embedded web server that includes links to the URLs that represent one or more participants to include in a telephone call. A link may include a variety of information about a telephone call, including an identifier, a telephone number, for each participant and an identifier of a conference bridge.

Using a web browser application on the PC or other network resource, a user may access the web page on the first TCD and click on one or more URL links to cause the TCD to dial the selected number(s). The web-based dialing application may be configured to enable a user to dial one or more TCDs on different types of networks, including telephones on the PSTN and/or on a data network. Further, the web-based dialing application may define a call set-up HTML tag, "callto:<destination>", that operates similarly to the mailto:<destination> HTML tag, such that clicking the call set-up tag triggers the creation of a telephone call to the <destination>.

An example web-based dialing application may define a method of initiating a telephone call between a first user of the first TCD and one or more second users of second TCDs. This method may include receiving one or more URL selections made by the first user, where each URL selection corresponds to one of the second TCDs. Next, a telephone call between the first TCD and the one or more second TCDs may be initiated.

WO 01/31900 PCT/USOO/29576 -66- Such a web-based dialing application may use one or more network directories, as described above in relation to Fig. 7, to map a user of TCD identifier, URL, telephone number, extension, to determine a network address for which to set-up a telephone call. Further, such a web-based dialing application may use other network resources, an IP/PSTN gateway, to send a set-up message to a TCD located on another network, the PSTN, as described above in relation to Fig. 7.

Another telephony application may be defined to display text on a display screen of a first TCD, where the content of the text corresponds to the content of an audio signal being received on the first TCD. For example, such a telephony application may be configured to display options on a display screen, display screen 206 corresponding to options played by an Interactive Voice Response (IVR) system. For example, such a telephony application may be configured to indicate to a second TCD a TCD that is part of an IVR system) that the first TCD is capable of displaying text. In response, the second TCD may send, or control another resource to send, text content corresponding to the audio content to the first TCD.

The first TCD then may display the text content, for example, a list of choices, on the display screen, as the IVR message is being played. A user may then make a selection using a user interface corresponding to the display screen, the user interface described above in relation to Fig. 5, as opposed to waiting for the complete IVR message to be played on the first TCD.

If the second TCD is part of an IVR system, a customer service network, a central server may act as a proxy for the second TCD and other TCDs of the IVR system and may be the network resource that sends the text signal to the first TCD.

Fig. 12 is a flow chart illustrating an example method 500 of displaying text associated with media, audio or video, received on a first connection between the first TCD and a second TCD as part of a telephone call, where the first TCD includes a display screen, for example, display screen 206 of Fig. 5. Such a method may be defined by one or more telephony applications.

In Act 502, a media signal may be received on the first connection from the second TCD, where the media signal represents media content.

In Act 504, before or concurrently to receiving the media signal, a textual signal is received on the first connection. The textual signal represents text content corresponding to the media content.

WO 01/31900 PCT/US00/29576 -67- Next, in Act 506, the text content is displayed on the display screen. In a following Act 508, after or concurrently to displaying the text content, the media content may be played.

Other applications may be defined to send textual data in response to a call set-up message. For example, such an application may be configured such that upon receiving a call set-up message from another TCD, the first TCD responds with a textual message, where the textual message depends on a state of the first TCD. For example, the first TCD may be defined to have a "not in office" state. Accordingly, the application may be configured such that when the first TCD receives a call set-up message, the first TCD sends a list of other contact methods to the other TCD, for example, a cell phone number, a voice mail address, or a telephone number of another user.

Fig. 13 is a flow chart illustrating an example embodiment of a method 510 of communicating information in accordance with a state of the first TCD to a second TCD.

In Act 512, a call set-up message is sent to the second TCD to set-up the telephone call. Next, in Act 514, in response to the call set-up message, a textual signal is received from the second telephony communication device. The textual signal defines text content corresponding to a state of the second TCD.

In a following step 516, the text content is displayed on the display screen of the first TCD.

The text content may include one or more options corresponding to the state of second TCD, where each option indicates an action to be taken in response to the state of the second TCD. These one or more options may be displayed to the user of the first TCD. Accordingly, the method 510 also may include an act of receiving a selection of one of the options from the first user, and sending a selection signal representing this selection to the second TCD to perform the action indicated by the selection.

Fig. 14 is a flow chart illustrating an example embodiment of a method 520 of communicating information in accordance with a state of the first TCD to a second TCD.

In Act 522, a call set-up message to initiate a telephone call is received at the first TCD from the second TCD. Next, in Act 524, a state of the first TCD is determined.

In a following step 526, the first TCD transmits a textual signal representing the determined state to the second TCD for display.

As described above, the textual signal may include textual representations of one or more options for a user of the second TCD to be displayed on the second TCD. Each WO 01/31900 PCT/US00/29576 -68option may indicate an action to be taken in response to the state of the first TCD.

Accordingly, the method 520 may further include an act of receiving a selection signal from the second TCD, where the selection signal represents a selection of the one or more options by the user of the second TCD, and an act of performing the action indicated by the selection.

Another application may define a method of communicating an audible expression during a telephone call on the communications network, where an audible expression is a sound that has meaning to a user. Such an audible expression may express an emotional state or provide emphasis during a phone call. For example, an audible may be a sound of a bomb exploding, a popular expression, a bell gonging, or another sound that would have meaning to a user. These sounds may be encoded as part of the tone generator 69 or may be stored on a storage mediun accessible by the first TCD, audio, storage medium 60. The application may be configured to mix the audible expression and a user's voice on the first TCD such that another participant in a phone call will hear a mixed audible signal including the voice and the audible expression. Optionally, the audible expression can be mixed with a user's voice such that only the audible expression is heard.

Video or textual expressions also may be used in a similar manner to communicate during a telephone call.

One or more applications may be defined to play and stop media on the first TCD as part of a game. For example, a "whack-a-mole" style game may be defined such that a media, audio or video, plays on the first TCD until a user of the first TCD selects a particular key sequence or presses a particular button on the user interface of the first TCD. If a correct sequence is entered by the user within a set period of time, then the playing of the sound may be stopped and control of the game may be sent to another TCD to continue the game.

Further, an application may be configured such that a quote-of-the-day or fortune is received on the TCD at specified intervals, daily, weekly, hourly, as configured by a user or a network provider.

Other telephony applications may be defined to play text, media, or other information on the first TCD as part of an advertisement or as part of a screen saver that runs on a display screen of the tirst TCD.

WO 01/31900 PCT/USOO/29576 -69- Fig. 15 is a flow chart illustrating an example embodiment of a method 530 of communicating an audible expression during a telephone call.

In Act 532, a voice signal representing a voice of a first user of the first TCD is received. In a next Act 534, a selection signal representing a selection of an audible expression by the first user is received.

Next, in Act 536, the audible expression signal corresponding to the selection signal is generated, where the audible expression signal represents the audible expression. In a following Act 538, the audible expression signal and the voice signal are mixed to produce a mixed signal.

Next, in Act 540, the mixed signal is transmitted as part of the telephone call to one or more second users at one or more second TCDs.

A call screening application may be defined to screen incoming calls to the tirst TCD based on data associated with the incoming call, for example, a caller identification caller ID), the time of day, or other associated data. The screening application may define rules, or provide parameters by which a user may define rules, to determine how to respond to a call set-up message based on different criteria. For example, for a highly important call, the rules may be defined such that the first TCD tries a series of different phone numbers in an effort to contact a user of the first TCD. Further, the screening application may be defined such that, for less important calls, the first TCD may offer voicemail or other alternatives. Also, the screening application may be configured such that the caller may be queried to supply additional information before the call is filtered appropriately.

Fig. 16 is a flow chart illustrating an example embodiment of a method 550 of screening a telephone call based on information associated with the call.

In Act 552, a first call set-up message is received at the first TCD from a second TCD. Next, in Act 554, one or more call answering rules are accessed, where each call answering rule defines a condition and an action to be taken by the first TCD in response to receiving a call set-up message if the condition is satisfied.

In a following Act 556, for one or more of the call answering rules, it is determined whether the condition is satisfied. Next, in Act 558, the call set-up message is responded to in accordance with the determinations for the one or more call answering rules.

*UL-,-U-UUL UOUUYb/tb As described above, a first rule of the one or more rules may define an action to be taken on condition of a call set-up message being received during one or more time intervals. Accordingly, the method 550 also may include acts of determining a first time at which the call set-up message is received, and comparing the first time to the one or more time intervals to determine whether the first time is within one or more of the time intervals. If the first time is within one of the one or more time intervals, the act of responding to the call set-up message comprises responding to the call set-up message in accordance with the action defined by the first rule.

Further, as described above, a first rule of the one or more rules may define an action to be taken on condition of the call set-up message being from a particular user.

Accordingly, the act of receiving of method 550 may include receiving an identification signal corresponding to the call set-up message, where the identification signal identifies a user of the second communication device. Further, the act of determining may include identifying the user from the identification signal, and comparing the identification of the user to identifications of one or more particular users to determine if the user is one of the particular users. If the user is one of the particular users, the act of responding to the call set-up message may comprise responding to the call set-up message in accordance with the action defined by the first rule.

Further, one or more of the call answering rules may define forwarding the call set-up message to one or more other TCDs if a first condition is satisfied. Accordingly, the act of responding may include forwarding the call set-up message to the one or more other TCDs if the first condition is satisfied.

Further, the screening application may be configured such that one of the call answering rules define playing a sound if a first condition is satisfied. Accordingly, the act of responding may include playing such sound if the first condition is satisfied.

The screening application also may be configured such that one of the call answering rules defines prompting a user of a calling TCD for more information if a first condition is satisfied. Accordingly, the act of responding may include prompting the user for more information if the first condition is satisfied.

Another application may be configured to integrate e-mail with a telephone call.

Fig. 17 is a flow chart illustrating an example embodiment of a method 560 of playing content of an e-mail message as audio on the first TCD.

AMENDED SHEET WO 01/31900 PCT/US00129576 -71 In Act 562, the electronic e-mail message is controlled to be sent to a network resource that converts the textual content of the e-mail message to a voice signal.

Optionally, the first TCD may include a text-to-speech application, such that the first TCD is the network resource.

In the next Act 564, a call is set-up between the network resource and the first TCD. In a following step 566, the voice signal is controlled to be transmitted to the first TCD as part of the telephone call. This transmission may be controlled by the first T'CD.

Next, in Act 568, the voice signal is played on the first TCD.

Another telephony application may be configured to record a telephone call conversation and then send the recorded conversation to one or more audio-playing devices, one or more other TCDs. For example, such a telephony application may define a method of communicating, to one or more second users of one or more second TCDs, at least a first part of a telephone call between a first user of the first TCD and one or more third users of one or more third TCDs. Such a method may comprise an act of recording as an audio file at least the first part of the telephone call between the first user and the one or more third users, and sending the audio file to the one or more second TCDs. The audio file may be sent by attaching it to an e-mail message and sending the e-mail message to the one or more second TCDs, or by attaching the audio file to a call set-up message and sending the call set-up message to the one or more second TCDs.

Another telephony application may define a method of sending a graphical file as a message for a user of a TCD. Fig. 18 is a flow chart illustrating an example method 570 of sending a graphical message to a first user of a second TCD.

In Act 572, a call set-up message is sent from the first TCD to the second TCD.

Next, in Act 574, an indication is received from the second TCD that the first user is not answering the call set-up message.

In a following Act 576, a graphical file is sent from the first TCD to the second TCD to store as a message to the first user. The first user then may display the message on a display screen on the second TCD. Optionally, the second TCD may be configured such that only specific users can leave graphical messages on the second TCD.

Fig. 19 is a flow chart illustrating another example embodiment of a method 580 of communicating a graphical message to a user of a first TCD, where the first TCD includes a display screen.

ULU' UU U LUU4z (0 72 In act 582, a call set-up message is received from a second TCD. In a following step 584, an indication that the first user is not answering the call set-up message is sent.

Next, in act 586, in response to the sending of the indication, a graphical file is received from the second TCD as a message.

Next, in act 588, the graphical file is displayed on the display screen to communicate the message to the first user.

Method 580 also may include an act of storing the graphical file on a storage medium accessible by the first TCD, for example, a local storage medium on the first TCD or another storage medium located on another network resource.

Another telephony application may be configured to add a connection to a media source, for example, a media source on the Intemet, and feed the media from that media source to another TCD that is put on hold by the first TCD. Such media may be audio, video, or a combination thereof.

Fig. 20 is a flow chart illustrating an example embodiment of a method 590 of placing one or more connections on hold during a telephone call.

In Act 592, an instruction to place a telephone call on hold is received, and in Act 594, an indication of a location of a media file is received.

In Act 596, a connection to the location of the media file is created, and in Act 598, media signals from the media file are received.

In a following step 600, the media signals are sent to the one or more connections on hold.

Another telephony application may be defined such that personal information about a first user may be determined, including configuration information about how to configure a TCD for the first user, and information about usage habits of the first user.

Accordingly, when a first user uses any of a plurality of TCDs on the communication network, the first user may provide the first users identification and the personal information of the first user may be accessed and used to configure the TCD that the first user is using. Optionally, this personal information may be stored on a network resource accessible by any of the plurality of TCDs on the communications network. Further, a network resource, for example, the TCD deployment server 314 described above in relation to Fig. 7, may be configured to retrieve the personal information for any of the TCDs on the communications network.

AMENDED SHEET WO 01/31900 PCT/US00/29576 -73- Fig. 21 is a flowchart illustrating an example embodiment of a method 610 of dynamically configuring a telephony communication device for a first user.

In Act 612, a user identification identifying the first user may be received, and an Act 614, configuration information specific to the first user may be accessed.

In a following Act 616, the TCD may be configured in accordance with the configuration information.

Further, this personal information may be made available to callers whenever a call is made, or may be saved into and accessed from a personal information management application such as Microsoft Outlook' or Lotus Notes.

Also, select personal information may also be made available to a telephone call receiving IVR prompting. Accordingly, a telephone application may be configured such that, at each IVR prompt, the select personal information may be accessed, and a response to the IVR prompt automatically sent, or, if a security feature is enabled, sent after permission is granted.

Another telephony application may be configured to enable a TCD to distort, scramble or encrypt a media signal before sending the signal onto the communications networks.

Another telephony application may be configured to control the routing of a telephone call through specific service providers on the communications network based on pre-defined criteria, for example, rates. For example, if a call is to be set-up with a TCD from another network, such an application may be configured to query one or more IP/PSTN gateways or IP network-to-IP network service providers for rate information for such a call. Such an application may include logic to determine the IP/PSTN gateway or service provider through which to set-up the telephone call based on the rate information.

Another telephony application may be configured to provide hands-free call answering on a TCD. Such an application may be configured such that, when a call setup message is received, an audible ring) or visual signal blinking light) indicates to the user that a call is incoming, the call is accepted, a call is created on the TCD), and a speaker phone or other speaker is activated so that a user of the TCD instantly can begin a telephone conversation.

Another telephony application may be configured to apply voice stress analysis to a telephone call. Such an application may monitor the emotional state of a speaker using WO 01/31900 PCT/US00/29576 -74known techniques and assign an associated numerical stress level. The numerical stress level then may be displayed on a display screen to a user of the first TCD participating in the telephone call.

Another telephony application may provide voice-based dialing on the first TCD.

Such an application may include voice recognition logic to search a database of voice patterns corresponding to users' network addresses or other identifiers to search for a match to a name spoken by a user of the first TCD. Such a database may be located locally on the first TCD or remotely on another network resource. After a pattern match is made, the first TCD then automatically may set-up a call with the TCD corresponding i0 to the match. Such an application may provide a user of the first TCD with access to any telephone number available on the Internet or any other telephone directory accessible by the first TCD merely by speaking a name into the first TCD.

As described above, a first TCD may store either locally or remotely telephone extensions and telephone numbers. Accordingly, a telephony application may be configured to search these numbers as a user is entering digits to call another user, and provide a list of numbers and extensions, or the names of users corresponding to the extensions and telephone numbers, on a display screen of the first TCD that match the digits entered so far by the user. The user then may select a telephone number extension or name from the display screen using a user interface, as opposed to entering the entire number into the first TCD. As each new digit is entered by a user, the list of matching telephone numbers may be reduced, and this process may be repeated until the user makes a selection from the list or the extension or telephone number is completely entered.

As described above in relation to Figs. 5 and 6, another application may provide an on-demand help system on the first TCD. Such a help system may provide step-bystep information to a user of the first TCD about how to use the TCD and how to use particular applications. Such a help application may be configured to use media files to help a user. For example, ifa user is dialing an international telephone number, the help system may prompt the user for the name of the country that is being dialed. In response to the user's entry for the prompt, the help application may supply the associated country code and the expected digit length of the phone number. In another example, such a help application may provide a sequence of interactive text messages and audio clips that prompt a user through a new or infrequently used task.

-u-L-uu'v UOUUZd~ /1 75 A common problem in dialing a telephone number is incorrectly entering a digit, and having to hang up and redial the entire number. Accordingly, a telephony application may be configured to store all digits entered by a user locally before sending a set-up message to initiate a telephone call. Further, such an application may display the digits on a display screen as the user is dialing. Thus, such an application may enable a user who enters an incorrect digit to merely clear the digit from the screen and re-enter the correct digit before the telephone call is initiated. After the correct number is entered, the user may be enabled to hit a button or touch a location on the display screen to initiate the telephone call.

Another telephony application may be configured such that information about a user or TCD may be sent attached) along with communication messages as part of a telephone call. Accordingly, such an application or a related application may be configured to extract such information from a communication message as part of a telephone call. Such information may include a local time at the caller's location or more sophisticated information such as a pointer to a web-based mapping application that visually shows the caller's location. Further, data representing the map itself may be sent along with a communication message. A variety of other forms of information may be sent along with a communication message as part of a telephone call.

Another telephony application may be configured to control a TCD to repetitively send a call set-up message to a network address at set intervals until the telephone call is answered by a human voice. Such an application may be used if a telephone call is too urgent to merely leave a voice message. Further, such an application may configure the first TCD to terminate a telephone call if the recipient at the network address transfers the telephone call in response to the call set-up message.

A space-saving application may define a method for loading only certain applications, portions of applications and data onto the first TCD in response to the TCD being initially deployed on a communications network. By configuring the first TCD to dynamically load only certain applications, portions of applications and data, such a space-saving application limits the amount of memory consumed by applications on the first TCD, thereby conserving memory resources. This conserved memory then may be.

used for other purposes.

Another application may be defined to provide a method of resolving conflicts between a plurality of applications on the first telephony communication device. For AMENDED SHEET WO 01/31900 PCT/US00/29576 -76example, two or more applications may be defined to be notified of a same event.

Accordingly, if the event occurs, a conflict occurs as to which application should be notified of the event.

Accordingly, such an application may be defined to receive an indication that a first application and one or more second applications are defined to be notified if a first event occurs, and to assign notification priority to the first application such that, if the first event does occur, the first application is notified of the event and the one or more second applications are not notified of the event In other words, as described above in relation to the application arbitrator, the first application consumes the notification to prevent future conflicts with the one or more second applications.

This conflict resolution application may include a user interface to allow a user to make the selection and assign notification priority to an application. For example, the user interface may be implemented on a desktop PC or on a telephone such as the telephone described in relation to Figs. 5 and 6.

Another application may be defined, for a telephone call including a first user of a first telephony communication device and a plurality of second users of other telephony communication devices, a method of visually indicating to the first user that the voices of one or more third users of the plurality of second users are currently being played on the first telephony communication device.

The method may include displaying a plurality of user identifiers, each user identifier indicating one of the second users. For example, these identifiers may be listed on a computer screen or on a display screen of a telephone, the display screen 206 described above in relation to Figs. 5 and 6.

Audio data may be received from one or more of the second users on connections corresponding to the one or more second users, respectively.

For each of the one or more third users, voice data may be detected in the audio data received from the third user using known DSP techniques. The application may configure one or more of the media processing elements described above in relation to the media processing module 29 to perform the known DSP techniques to detect ifa voice is received on a connection.

Next, the voice data of the third users may be mixed, for example, by the local bridge 51 of Fig. 3, to produce mixed audio data. In a following act, the mixed audio P.\OPERKL253166 spal .do-27103/04 77data may be played on the first telephony communication device, for example, on a handset speaker, a headset speaker or base speaker.

To indicate to the first user that the voices of the one or more third users are currently being heard by the first user, for each of the one or more third users, a visual indicator may be displayed next to the identifier identifying the third user. For example, an icon may appear on the display screen next to the names of each second user for whom voice data was detected on the second user's connection. Other methods of indication may be used.

The performance of the DSP, including receiving the audio data, detecting the voice data, and mixing the audio data may performed on a different device than the device that displays the indicators described above. For example, a first TCD may perform the DSP and a companion device may display the indicators, or a remote server may perform the DSP, and the first TCD may display the indicators.

Further, a first device performing the DSP may communicate the voice detection, for example, as part of an RTCP message, to a second device that displays the indicators.

Alternatively, the DSP and displaying may occur on a same device, for example, on the first TCD.

Having now described some illustrative embodiments, it should be apparent to those skilled in the art that the foregoing is merely illustrative and not limiting, having been presented by way of example only. Numerous modifications and other illustrative embodiments are within the scope of one of ordinary skill in the art and are contemplated as falling within the scope of the invention. In particular, although many of the examples presented herein involve specific combinations of method acts or apparatus elements, it should be understood that those acts and those elements may be combined in other ways to i 25 accomplish the same objectives. Acts, elements and features discussed only in connection with one embodiment are not intended to be excluded from a similar role in other embodiments.

The reference to any prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that that prior art forms part of the common general knowledge in Australia.

Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or group of integers or steps.

Claims

1. A telephony communication device that is part of a communications network that comprises a transmission medium, the telephony communication device comprising a call processing module adapted for representing and controlling at least a first telephone call that includes one or more connections to other users, each user corresponding to another telephony communication device on the communications network, the telephony communication device CHARACTERIZED IN THAT: for at least a first of the one or more connections, the call processing module is adapted for selecting a first call control protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like available on the first telephony communication device, and adapted for controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol.

2. The telephony communication device of claim 1, wherein the call processing module is adapted for controlling communications on the telephony device corresponding to a second of the one or more connections using a second call control protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like, different than the first call control protocol, concurrently to controlling the communications corresponding to the first connection.

3. The telephony communications device of claim 1, wherein the call processing module is adapted for representing and controlling a second telephone call that represents at least a second connection, wherein the call processing module is adapted for controlling communications corresponding to the second connection on the telephony communication device using a second call control protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like, different than the first call control protocol, concurrently to controlling communications corresponding to the first connection. AMENDED SHEET Uf.- J-t jV UOUU (0/D -79-

4. The telephony communication device of claim 1, wherein the first call control protocol is the Session Initiation Protocol. The telephony communication device of claim 1, wherein the first call control protocol is the H.323 protocol.

6. The telephony communication device of claim 1, wherein the first call control protocol is the Media Gateway Control Protocol.

7. The telephony communication device of claim 1, wherein the first call control is protocol the Megaco/H.248 Protocol

8. The telephony communication device of claim 1, wherein the first call control is protocol the Skinny Station Protocol.

9. The telephony communication device of claim 1, further CHARACTERIZED IN THAT: the telephony communications device has an open telephony system architecture, including means for accessing and modifying a telephony application on the telephony communication device after the first telephony communication device is deployed on the communications network. The telephony communication device of claim 9, wherein the open telephony system architecture includes an open application programming interface to modify the telephony application.

11. The telephony communication device of claim 9, wherein the open telephony system architecture includes: at least a part of a non-telephony application defining a telephony function to be performed independently of a telephone call. AMENDED SHEET UL-VL" uV U3UUZ/)/

12. The telephony communication device of claim 9, wherein the telephony application is written in a general purpose programming language.

13. The telephony communication device of claim 12, wherein the general purpose programming language is Java.

14. The telephony communication device of claim 9, wherein the open telephony system architecture further includes: an operating system; and an operating system interface adapted for interfacing communications between the operating system and telephony applications of the open telephony system architecture such that the telephony applications are independent of the operating system. The telephony communication device of claim 9, wherein the open telephony system architecture further includes: an application programming interface to develop applications for the telephony communication device, wherein the application programming interface is generic to SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like.

16. The telephony communication device of claim 9, wherein the open telephony system architecture further includes: a media processing module comprising, for each telephone call, a corresponding media processing component adapted for representing digital audio processing of the telephone call, and for each connection of the telephone call, the media processing component comprising a corresponding media processing connection, wherein, for each telephone call, to control the media processing of the telephone call, the call processing module is adapted for controlling the media processing component corresponding to the telephone call, and, for each connection of the telephone call, to control the media processing of the connection, the call processing module is adapted for controlling the corresponding media processing connection. AMENDED SHEET U-V'V'VVL UOUUL 0 -81

17. The telephony communication device of claim 9, wherein the open telephony system architecture further includes: a media processing module, the media processing module comprising media processing elements adapted for defining media processing functions; wherein, to implement a media processing function, the telephony application is adapted for dynamically configuring one or more combinations of the media processing elements during execution of the telephony application.

18. The telephony communication device of claim 9, wherein the open telephony system architecture further includes a pointer to a location on the communications network of an application remotely executable by the telephony communication device.

19. The telephony communication device of claim 9, wherein the open telephony system architecture defines a remote user interface for another network resource on the communications network. The telephony device of claim 9, wherein the open telephony system architecture further comprises: a core telephony functionality layer adapted for defining core telephony functions associated with a phone call such that only privileged vendors having privileged access are capable of modifying or expanding the core telephony functions.

21. The telephony communication device of claim 1, wherein the telephony communication device has an extensible telephony system architecture adapted for adding at least a part of a telephony application to the telephony communication device after the telephony communication device is deployed on the communications network.

22. The telephony communication device of claim 21, wherein the telephony application was developed independently from a vendor that created the telephony communication device. AMENDED SHEET -82-

23. The telephony communication device of claim 21, wherein the telephony application was developed independently from creation of the extensible telephony system architecture.

24. The telephony communication device of claim 21, wherein the extensible telephony system architecture further includes an open application programming interface adapted for adding the at least part of the telephony application. The telephony communication device of claim 21, wherein the extensible telephony system architecture further includes: at least a part of a non-telephony application defining a non-telephony function to be performed independently of a telephone call.

26. The telephony communication device of claim 21, wherein the telephony application is written in a general purpose programming language.

27. The telephony communication device of claim 26, wherein the general purpose programming language is Java. °28. The telephony communication device of claim 21, wherein the extensible telephony system architecture further includes: an operating system; and an operating system interface adapted for interfacing communications between the operating system and telephony applications of the extensible telephony system architecture such that the telephony applications are independent of the operating system. =t •o .29. The telephony communication device of claim 21, wherein the extensible -telephony system architecture further includes: an application programming interface to develop applications for the telephony communication device, wherein the application programming interface is generic to SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like. l-r-- r U, U- -83- The telephony communication device of claim 21, wherein the extensible telephony system architecture further includes: a media processing module comprising, for each telephone call, a corresponding media processing component adapted for representing digital audio processing of the telephone call, and for each connection of the telephone call, the media processing component comprises a corresponding media processing connection, wherein, for each telephone call, to control the media processing of the telephone call, the call processing module is adapted for controlling the media processing component corresponding to the telephone call, and, for each connection of the telephone call, to control the media processing of the connection, the call processing module is adapted for controlling the corresponding media processing connection.

31. The telephony communication device of claim 21, wherein the extensible telephony system architecture further includes: a media processing module comprising media processing elements to define media processing functions; wherein, to implement a media processing function, the telephony application is adapted for dynamically configuring one or more combinations of the media processing elements during execution of the telephony application.

32. The telephony communication device of claim 21, wherein the extensible telephony system architecture further comprises a pointer to a location on the communications network of an application remotely executable by the telephony communication device.

33. The telephony communication device of claim 21, wherein the extensible telephony system architecture defines a remote user interface for another network resource on the communications network.

34. The telephony communication device of claim 1, wherein the call processing module is adapted for communicating with one or more other network resources on the communications network to control the one or more telephone calls. AMENDED SHEET -84- The telephony communication device of claim 34, wherein another telephony communication device is connected to the communications network through a Public Switched Telephone Network and an IP/PSTN gateway, and wherein the call processing module is adapted for communicating with the IP/PSTN gateway to control, during the telephone call, communications between the telephony communication device and the other telephony communication device.

36. The telephony communication device of claim 1, wherein the telephony communication device is a telephone.

37. A method of controlling one or more telephone calls on a telephony communication device connected to a communications network, a first telephone call including one or more connections to other users, each user corresponding to another telephony communication device on the communications network, the method CHARACTERIZED IN THAT it comprises, for at least a first of the one or more connections, acts of: selecting a first call control protocol from amongst SIP, H.323. MGCP, Megaco/H.248, the Skinny Station protocol and the like available on the telephony communication device; and controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol.

38. The method of claim 37, the method further comprising an act of: concurrently to controlling the communications corresponding to the first connection, controlling ••go communications on the telephony device corresponding to a second of the one or more connections using a second call control protocol from amongst SIP, H.323. MGCP, Megaco/H.248, the Skinny Station protocol and the like different than the first call control protocol.

39. The method of claim 37, wherein a second telephone call includes at least a second connection, the method further comprising: concurrently to controlling communications corresponding to the first connection, controlling communications corresponding to the second connection on the telephony communication device using a second call control protocol from amongst SIP, H.323. MGCP, Megaco/H.248, the Skinny Station protocol and the like different than the first call control protocol. The method of claim 37, further CHARACTERIZED IN THAT it comprises an act of: configuring the telephony communications device with an open telephony system architecture for accessing and modifying a telephony application on the telephony communication device after the telephony communication device is deployed on the communications network.

41. The method of claim 37 further CHARACTERIZED IN THAT it comprises an act of: configuring the telephony communication device with an extensible telephony system architecture for adding at least a part of a telephony application to the telephony communication device after the telephony communication device is deployed on the communications network.

42. A computer program for controlling a first telephone call on a telephony communication device connected to a communications network, the telephone call including one or more connections to other users, each user corresponding to another telephony communication device on the communications network, the computer program including computer-readable signals tangibly embodied on a computer-readable medium that define a method CHARACTERIZED IN THAT it comprises, for at least a first of the one or more connections, acts of: selecting a first call control protocol from amongst SIP, H.323, MGCP, Megaco/H.248, the Skinny Station protocol and the like available on the first telephony communication device; and controlling communications corresponding to the first connection on the telephony communication device using the first call control protocol. AMENDED SHEET -86-

43. The computer program of claim 42, wherein the method is further CHARACTERIZED IN THAT it comprises an act of: configuring the telephony communications device with an open telephony system architecture for accessing and modifying the telephony application on the telephony communication device after the telephony communication device is deployed on the communications network.

44. The computer program of claim 42, wherein the method is further CHARACTERIZED IN THAT it comprises an act of: configuring the software component with an extensible architecture for adding at least a part of a telephony application to the telephony software component after the telephony communication device is deployed on the communications network. The telephony communication device of claim 2 or 3, wherein the telephony communication device comprising a user input to receive audio input from a user of the V00 •telephony communication device, two or more connection inputs to receive voice data from the transmission medium on the first and second connections, an audio output to transmit audio to the first user, two or more connection outputs to transmit voice data to the transmission medium on the first and second connections, the telephony communication device further CHARACTERIZED IN THAT it comprises: a local conference call bridge including means for receiving user audio from the user input and connection audio from the two or more connection inputs, means for mixing the user audio and the connection audio to produce output user audio and output connection audio and means for transmitting the output user audio to the audio output 000and the output connection audio to the two or more connection outputs. oo o oooi P:OPER\KL\253166 spl l.doc-27/004 -87-

46. Telephony communication device, substantially as hereinbefore described with reference to the drawings and/or Examples.

47. A method of controlling one or more telephone calls, substantially as hereinbefore described with reference to the drawings and/or Examples.

48. A computer program for controlling a first telephone call on a communication device, substantially as hereinbefore described with reference to the drawings and/or Examples. DATED 27 August 2004 PINGTEL CORP. By DAVIES COLLISON CAVE Patent Attorneys for the applicant e