WO1998036551A1

WO1998036551A1 - Method and apparatus for connecting an incoming call to a computer system that is already engaged in a communication session

Info

Publication number: WO1998036551A1
Application number: PCT/US1998/001679
Authority: WO
Inventors: George L. Taylor; Keith A. Pirkl; Ajit B. Pendse; Kenneth L. Keeler; Mojtaba Mirashrafi
Original assignee: Efusion, Inc.
Priority date: 1997-02-14
Filing date: 1998-02-03
Publication date: 1998-08-20
Also published as: SE9902820D0; EP1016262A4; EP1016262A1; AU6254598A; CA2281479C; CA2281479A1; SE9902820L; FI19991727A

Abstract

A server (112) is configured to connect an incoming call to a client computer (102), wherein the call is generated by a telephone handset (140) and destined for a local PSTN extension (106) that is already in use by the client computer (102) communicating with the server (112) for another purpose. In accordance with one embodiment of the invention, the server (112) is comprised of a storage medium and an execution unit. The storage medium having stored therein a plurality of programming instructions for implementing communication services for facilitating the connection of the incoming phone call on behalf of the client computer (102) and interleavingly delivering the incoming call signals to the client computer (102), and accepting interleaved outbound call signals from the client computer (102) and transmitting outbound call signals on behalf of the client computer (102) to the telephone handset (140). The execution unit, coupled to the storage medium, is responsible for executing the programming instructions.

Description

METHOD AND APPARATUS FOR CONNECTING AN INCOMING CALL TO A COMPUTER SYSTEM THAT IS ALREADY ENGAGED IN A COMMUNICATION SESSION.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the field of telecommunications and, in particular, to a method and apparatus for connecting an incoming call to a computer system that is already engaged in a communication session, such as an Internet session.

2. Background Information

Numerous advances have been made in recent years in the field of

telecommunications. In particular, the field of internet telephony has been evolving at an increasing rate. Evidence of the evolution of internet telephony is best characterized by the number of products now available in the open market. Products such as CoolTalk by Netscape Communications Corporation of Mountain View, California; Internet Connection

Phone by International Business Machines of Amonk, New York; Intel Internet Phone

(IPhone) by Intel Corporation of Santa Clara, California; NetMeeting by Microsoft Corporation, Redmond, Washington; Quarterdeck WebTalk by Quarterdeck Corporation of Marina Del Rey, California; TeleVox by Voxware Incorporated of Princeton, New Jersey; and WebPhone by Netspeak Corporation of Boca Raton, Florida.

Each of these products offers internet based voice communications with a telephone motif, between two users each using the same (or compatible) product on either end of the internet connection. That is, the internet provides the "switching" architecture for the system,

while the computer acts as the "handset", or the audio interface. One reason for the

proliferation of these applications is a desire to push the technology of the internet to provide

a total communications tool. The appeal to users is that, currently, the use of the internet is free of toll charges. Therefore, a user of an internet phone product may communicate with

another user located anywhere else in the world without having to pay the long distance charges associated with making a telephone call using the public switched telephone network (PSTN).

However, consumers expecting to completely eliminate their long-distance telephone bills are in for a disappointment. As they shall soon discover, although innovative in their own right, the current applications identified above have a number of limitations which retard

their acceptance as a primary communications tool. One such limitation is that each of the applications identified above requires that both users have installed the same software package, or compatible packages and, therefore, provide a relatively low level of

interoperability. One reason for the lack of interoperability between the applications is that the developers of these products have incorporated different voice encoders (commonly referred to as a "voice codec", or simply a "codec") in the products. Accordingly, because of

the different codecs used, different applications will generally not recognize speech encoded

by a codec of a disimilar application.

Another limitation associated with these products is that they are tied to the internet,

often requiring all users to access a common server in order to maintain a directory of available users in which to call. That is to say, the applications identified above do not

integrate the packet switched network of the internet with the circuit switched public switched

telephone network (PSTN). Therefore, although a computer connected to the internet through an internet service provider (ISP) may communicate with another user on the internet,

assuming they are both using a common software application (or at least applications with

compatible codecs), these applications do not support communication with a user of a

telephone handset.

The reason for this limitation is readily understood by those who appreciate the complexity of the two networks. As alluded to above, the internet is a packet switched network. That is to say, communication over the internet is accomplished by "breaking" the

transmitted data into varying-sized packages (or "packets"), based primarily on communication content, and interleaving the various-sized packages to best utilize the

bandwidth available at any given time on the internet. When the packets reach their intended destination, they must be reassembled into the originally transmitted data. Loss of packets,

and thus data, occur frequently in such a network, and the ability of the network to succesfully

transmit information from one point in the network to another determines the quality of the

network. For inter-computer communication transactions involving data, the ability to transmit packets and retransmit any packets that are perceived to have been dropped is not a severe limitation and may not even be perceived by the user of the system. However, in a

voice communication transaction, the delay required to retransmit even one data packet may

be perceived by a user. At best, such delays are an annoying inconvenience. In contrast to the packet switched network of the internet, the public switched

telephone network (PSTN) is a circuit switched network. That is to say that the PSTN assigns a dedicated communication line to a user with which to complete the telephone call, wherein

the user can utilize the assigned resource of the PSTN in any way they choose, with the

understanding that the user is paying for the use of the dedicated resource of the PSTN.

While the circuit switched approach of the PSTN system is not necessarily the most efficient

system in terms of call traffic (i.e., it does not make use of the "dead space" common in a conversation), it is relatively easy to ensure that information destined for a particular user is

delivered, it simply provides a dedicated line to complete the transaction.

Nonetheless, despite these engineering challanges, a few products are now offered

which purport to integrate the PSTN to the internet. Products such as Net2Phone by IDT Corporation of Hackensack, New Jersey, claim to provide a computer user with the ability to place and receive a phone call to/from a PSTN extension. Unfortunately, none of these

products completely solve the problem of offering seamless integration of the two networks.

The lack of seamless integration is a limitation keeping prior art internet telephony applications from becoming viable communication tools. An example of such a limitation is

associated with the initiation of a call from a remote PSTN extension to a computer system user engaged on the internet. The applications identified above require that, in order to make a phone call from remote PSTN extension to a computer system user via the internet, the user of the remote PSTN extension will have to dial a local internet phone access number, wherein the user will then be asked to dial the internet protocol (IP) address associated with the

computer running the internet telephony software to which they are attempting to access.

Although providing an easy technological solution (for the software developers of the application), requiring the typical consumer to remember and dial an IP address is impractical

for a number of reasons. First, home based computer users, relying on a dial-in internet

service provider (ISP), are dynamically assigned a different IP address each time they login to the ISP server. The reason for the dynamic IP address assignment being that the ISP server

has a limited number of IP addresses available, the number of IP addresses defined by the

number of ports supported by the server. Therefore, as each new user logs into the ISP, the ISP assigns the user an IP address associated with the port they are currently occupying. Thus, unless a user happens to log into the same port each time, an option generally not within the discretion of the user, the user will not be assigned the same IP address.

Another problem resulting from the technical limitations of the prior art is that a home

based computer system user, engaged on the internet from the only local PSTN extension within the home, cannot receive phone calls while the computer system is utilizing the PSTN

extension. Heavy internet users have taken the only recourse currently available: the costly addition of another local PSTN extension within the home, wherein one of the extensions is primarily used for the computer system and the other primarily used for voice

communications. It will be appreciated by those skilled in the art, however, that the technical hurdle

faced by the developers of the internet telephony applications is not trivial. To solve the

problems associated with the prior art, an application will be required to seamlessly integrate the packet switched network of the internet with the circuit switched network of the PSTN, a

large undertaking which requires expertise in both the world of telecommunications and the

Internet. Just such a solution is presented in the context of the present invention.

Thus a need exists for a method and apparatus for connecting an incoming call to a computer system that is already engaged in a communication session.

SUMMARY OF THE INVENTION

In accordance with the teachings of the present invention, method and apparatus for connecting an incoming call to a computer system already engaged in an on-line communication session is disclosed. As illustrated in a first embodiment, a server is configured to connect an incoming call to a client computer, wherein a call generated by a telephone handset destined for a local PSTN extension that is already in use by the client computer communicating with the server for another purpose, is connected to the client computer. The server comprises a storage medium having stored therein a plurality of programming instructions for implementing communication services for facilitating the connection of the incoming call to the client computer, and an execution unit coupled to the storage medium for executing the programming instructions. The communication services include services for answering the incoming phone call on behalf of the client computer and interleavingly delivering incoming call signals to the client computer, as well as accepting interleaved outbound call signals from the client computer and transmitting outbound call signals on behalf of the client computer to the telephone handset. As a result, a user of a client computer may still receive incoming telephone calls even though the local PSTN extension is already in use by the client computer for another communication purpose.

In addition to the above, different embodiments of the present invention may also beneficially include services for providing the user with supplemental information associated with the inbound call, and for providing the user of the client computer a number of alternate routing options. In particular, the present invention anticipates providing the user of client computer the ability to dynamically route the inbound call to a voice mail system, resident locally or within the PSTN, or to route the call to an alternative PSTN extension.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:

Figure 1 is a block diagram illustrating an exemplary communication system incorporating the teachings of the present invention;

Figures 2 and 3 are flow charts illustrating a method for connecting a phone call to a client computer already engaged in another communication session, in accordance with one embodiment of the present invention;

Figure 4 is a block diagram illustrating an adjunct processor incorporating the teachings of the present invention suitable for incorporation in the exemplary communication system of Figure 1; s

Figure 5 is a block diagram illustrating the key software components of the adjunct processor of Figure 4, in accordance with one embodiment of the present invention;

Figure 6 is a block diagram of an alternate embodiment of a communication system incorporating the teachings of the present invention; and

Figure 7 is a flow chart illustrating the method steps for connecting a phone call to a client computer already engaged in another communication session, in accordance with an alternate embodiment of the present invention.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the specific details. In other instances, well known features are omitted or simplified in order not to obscure the present invention. Furthermore, for ease of understanding, certain method steps are delineated as separate steps, however, these separately delineated steps should not be construed as necessarily order dependent in their performance.

Referring now to Figure 1, a block diagram is presented illustrating an exemplary communication system 100 incorporating the teachings of the present invention for connecting an incoming call to a computer system that is already engaged in a communication session. As depicted, communication system 100 is shown comprising Adjunct Processor (AP) 112 and Internet Service Provider (ISP) 120 incorporated with the teachings of the present invention, internet telephony enabled client computer 102 and handset 140. As will 1 be described in more detail below, AP 112 and ISP 120 facilitate access by client computer 102 to one or more coφorate presence servers (CPS) such as, for example CPS 155, 156, 157 and 159, via Internet 150 and Public Switched Telephone Network (PSTN) 170 incoφorated with the teachings of the present invention. In other words, ISP 120 and client computer 102 are engaged in a data communication session over communication lines 122 and 106. Nevertheless, in accordance with the teaching of the present invention, ISP 120 and AP 112 make it possible for handset 140 to call internet telephony enabled client computer 102, allowing a user of handset 140 and a user of client computer 102 to converse with each other, while client computer 102 remains connected to Internet 150, and without requiring an additional communication line besides communication line 106.

As illustrated, PSTN 170 is shown comprising Service Switching Points (SSP) 108 and 136, Signal Transfer Points (STP) 126 and 130, Signal Control Point (SCP) 134, Adjunct Processor (AP) 112 and Internet Service Provider (ISP) 120 incoφorated with the teachings of the present invention, coupled together as shown. In particular, client computer 102 communicates via PSTN 170 with a modulation/demodulation (MODEM) device coupled to PSTN extension 104, as is well known in the art. PSTN extension 104 is coupled to SSP 108 with communication line 106. As shown, SSP 108 may well be coupled to other handsets such as handset 142 via communication line 143. In addition, SSP 108 is also coupled to STP 126 via trunk line 124, and to AP 112 and ISP 120 via trunk lines 110 and 122, respectively. Continuing, STP 126 is coupled to STP 130 via trunk line 128, while STP 130 is coupled to SCP 134 and SSP 136 with control line 132 and trunk line 135, respectively. As was the case with SSP 108, SSP 136 is depicted as supporting a plurality of telephone handsets such as handset 140 and 144 via communication lines 138 and 145, respectively.

As illustrated in Figure 1, handset 140 is intended to represent a broad category of conventional handsets known in the art. No special features are required of telephone handset 140 for it to call and be "connected" to client computer 102. Additionally, in the embodiment of Figure 1 communication line 138 connecting handset 140 to SSP 136 may simply be a plain old telephone service (POTS) communication line, although other types of communication lines may be used. Although the present invention is presented within the context of a PSTN communications system, those skilled in the art will appreciate that this is by example only, and that the teachings of the present invention may well be practiced in a wireless communication system such as, for example, cellular communication systems, Personal Communications Services (PCS) systems, and the like.

Client computer 102 is also intended to represent a broad category of internet telephony enabled computer systems known in the art. An example of such a computer system is a desktop computer system equipped with a high performance microprocessor, such as the Pentium® processor manufactured by Intel Coφoration of Santa Clara, CA, a number of audio input and output peripherals/interface for inputting, digitizing and compressing outbound audio, and for decompressing and rendering inbound audio, a communication interface for sending and receiving various data packets (including audio data packets) in accordance with certain standard communication protocol, such as a V.42bis compliant modem, a windows-based operating system, such as Windows™ 95 developed by Microsoft Coφoration of Redmond, WA, a web communications tool such as Navigator™, developed by Netscape Communications of Mountain View, CA, and an internet telephony application, such as the above described IPhone developed by Intel Coφoration. Similarly, communication line 106 connecting client computer 102 to PSTN 170 may also be simply a POTS line, although other types of communication lines may also be used.

In addition to communication with AP 112 via control line 118, ISP 120 is further coupled to SSP 108 via a plurality of other communication lines 123. Communication line 122 typically is of the same type as communication line 106, e.g., POTS or integrated services / I digital network (ISDN) lines. Communication lines 123 are intended to represent communication lines of various types, such as Tl (1.533 Mbps) trunk lines, or El (2.0488

Mbps) trunk lines which may be configured to serve client computers with higher data rate requirements, or to service a number of individual communication lines.

One skilled in the art of, for example, telecommunications, will appreciate that PSTN 170 is significantly more complex than what is depicted in Figure 1. For example, each SSP services thousands of extensions, and there are numerous SSPs, STPs and SCPs. However, Figure 1 does capture a number of the more relevant components of PSTN 170 necessary to illustrate the interrelationship between PSTN 170, client computer 102, handset 104 and ISP 108, such that one skilled in the art may practice the present invention. The functions performed by SSP 108 and 136, STP 126 and 130 and SCP 134, as well as their constitutions are well known. Accordingly, PSTN 170 will not be further described.

Similarly, it should be noted that while for ease of explanation, only a handful of CPS 155-159 are shown to be connected to Internet 150, there are actually numerous CPSs connected to Internet 150, as well appreciated by those skilled in the art. In addition, there are government presence severs (not shown) as well as education presence servers (not shown) coupled to Internet 150 as is well known in the art, wherein each of these servers may be directly connected to Internet 150 as illustrated, or indirectly through an ISP such as ISP 158. Also, while the present invention is being described in the context of client computer 102 being engaged in data communication with ISP 120, as will be readily apparent from the description to follow, the present invention may be practiced with any client computer 102 engaged in data communication with any server.

Turning now to Figures 2 and 3, a flow chart illustrating the method steps of the present invention for connecting a call from handset 140 to client computer 102 is shown. As depicted, the method begins at step 204 when a user of telephone handset 140 initiates a telephone call by dialing PSTN extension 104. As described earlier, the call is established via communication line 138 through SSP 136, STPs 130 and 126 to SSP 108. In particular, as the call is placed from telephone handset 140 via SSP 136, SSP 136 will encode Automatic Number ID (ANI) information associated with telephone handset 140 and Destination Number ID Service (DNIS) information associated with the call destination (i.e., PSTN extension 104) in the prompt signal from SSP 136 to SSP 108, in an attempt to initiate the telephone call. In step 206, SSP 108 detects the inbound call destined for PSTN extension 104 from telephone handset 140 via SSP 136, and determines that PSTN extension 104 is currently in use. Accordingly, in step 208, SSP 108 queries AP 112 via trunk line 110 to determine the calling features associated with PSTN extension 104 to determine possible alternate call routing options for the inbound call. To determine the calling features associated with PSTN extension 104, AP 112 accesses database 114 which maintains a list of calling features associated with all PSTN extensions serviced by SSP 108. One such feature, in accordance with the teachings of the present invention, is feature indicating that a particular PSTN extension is internet telephony enabled. Accordingly, in step 210, a determination is made by AP 112 as to whether PSTN extension 104 is an internet telephony enabled PSTN extension.

If in step 210, it is determined that PSTN extension 104 is not an internet telephony enabled extension, AP 112 continues down the calling feature hierarchy associated with PSTN extension 104, in step 212, to determine how to best route the call. Examples of such alternative calling features may include call waiting, or voice mail, to name but a few. In step 214, based on input from AP 112, SSP 108 routes the inbound call in accordance with the calling features associated with PSTN extension 104, as appropriate, and the method ends in step 216. / 3

If, however, in step 210, it is determined that PSTN extension 104 is, in fact, internet telephony enabled, SSP 108 queries ISP 120 to determine if ISP 120 has the capacity available to accept and route the inbound call to PSTN extension 104. In step 220, a determination is made by ISP 120 as to whether ISP 120 can route the call to PSTN extension 104. In making the determination of step 220, ISP 120 first determines whether it is currently engaged in a data communication session with client computer 102 via PSTN extension 104, and also whether there are available communication ports with which to accept the incoming call. If, in step 220, it is determined that ISP 120 cannot accept and route the inbound call, then the method continues with step 212, wherein AP 112 continues down the calling feature hierarchy associated with PSTN extension 104 to determine how to route the call.

If, alternatively, it is determined in step 220 that ISP 120 has the resources available to accept and route the inbound call, ISP 120 instructs SSP 108 to forward the inbound call to ISP 120 via an available communication line 123, in step 302. In step 304, ISP 120 signals client computer 102 via communication line 122, SSP 108 and communication line 106 supporting the data communication session with Internet 150, of the inbound call and providing additional information associated with the origin (ANI), format and any toll charges associated with accepting and completing the inbound call, and queries the user of client computer 102 whether or not to accept the inbound call. In step 306, the user of client computer 102 responds to ISP 120 via the data communication session with Internet 150 (i.e., supported by communication line 106, SSP 108 and communication line 122). If, in step 306, the user of client computer 102 chooses not to accept the inbound call, or if the prompt from ISP 120 goes unanswered for a predetermined period of time, the method continues with step 211, wherein one embodiment control transfers back from ISP 120 to AP 112, which continues down the calling feature hierarchy associated with PSTN extension 104 to determine how best to route the inbound call. ι

If, however, in step 306 the user of client computer 102 signals ISP 120 to accept and route the inbound call, ISP 120 completes a communication connection between communication line 123 and communication line 122 acting as a "bridge" between handset 140 and internet telephony enabled client computer 102, in step 308. In particular, ISP 120 digitizes and compresses inbound call signals received from handset 140 on communication line 123 and interleavingly delivers the encoded call signals to client computer 102 via communication line 122, SSP 108 and communication line 106, or, in other words, via the previously established data connection. The compressed inbound call signals will be decompressed by the communication interface of client computer 102 and rendered by the internet telephony application. Likewise, outbound call signals emanating from client computer 102 will be digitized by the audio interface and compressed by the communication interface of client computer 102 and interleavingly delivered to ISP 120 wherein they will be decompressed and rendered for the benefit of the user of telephone handset 140. In other words, ISP 120 converts the voice information between PSTN and IP protocols and interleaving delivers call signals to/from telephone handset 140 and client computer 102 until call completion, and the method ends in step 310.

Jumping ahead to Figure 7, a flow chart illustrating the method steps of an alternate embodiment of the present invention for connecting a call from handset 140 to client computer 102 is shown. As depicted, the method begins with step 702, wherein the user of client computer 102, in anticipation of beginning an internet data communication session via PSTN extension 104, actively enables a call forwarding feature with the switch of SSP 108 by entering a feature_enable key sequence (e.g., *71) using the keypad of the telephone connected to PSTN extension 104. In response, the switch of SSP 108 prompts the user of PSTN extension 104 to enter the telephone number to which calls are to be forwarded, wherein the user enters an access number corresponding to ISP 120 using the telephone keypad, for example. In an alternate embodiment the feature_enable key sequence and entry of the access number for ISP 120 may be performed automatically, as part of a modem initialization script at the onset of a data communications session. In the context of the present example implementation, the user of client computer 102 then dials ISP 120 to establish a data connection with a server (e.g., CPS 156) through Internet 150.

Having actively enabled the call forwarding feature in step 702, PSTN extension 104 is now enabled to receive inbound calls via ISP 120. In step 704, a user of telephone handset 140 initiates a telephone call by dialing PSTN extension 104. As described earlier, the call is established via communication line 138 through SSP 136, STPs 130 and 126 to SSP 108. In particular, as the call is placed from telephone handset 140 via SSP 136, SSP 136 will encode Automatic Number ID (ANI) information associated with telephone handset 140 and Destination Number ID Service (DNIS) information associated with the call destination (i.e., PSTN extension 104) in the prompt signal from SSP 136 to SSP 108, in an attempt to initiate the telephone call. In step 706, SSP 108 receives the incoming call request from SSP 136, determines that PSTN extension 104 denoted by DNIS has forwarded all incoming calls to an access number corresponding to ISP 120. Accordingly, SSP 108 attempts to forward the call to ISP 120. In one embodiment, the original DNIS corresponding to PSTN extension 104 becomes the ANI for the forwarded call, while the access number corresponding to ISP 120 becomes the new DNIS for the forwarded call. In an alternate embodiment, all three numbers (i.e., the original ANI, the original DNIS, and the access number corresponding to ISP 120) may be retained. If, in step 708, it is determined that ISP 120 does not have the necessary resources (or, capacity) available to route the incoming call to PSTN extension 104, ISP 120 rejects the incoming call from SSP 108, and SSP 108 continues down the calling feature hierarchy associated with PSTN extension 104 to route the call, or simply generates a "busy" tone, in step 710. If, however, in step 708 it is determined that ISP 120 has the resources available to accept and route the incoming call to PSTN extension 104, ISP 120 determines that the ANI information received corresponds to a particular client computer (e.g., client computer 102), using one of a number of methods known in the art (e.g., caller ID services), and signals client computer 102 of the incoming call. In so doing, ISP 120 prompts the user of client computer 102 with associated call information and queries the user whether to accept the incoming call, in step 714. If, in step 716, the user denies the incoming call, ISP 120 rejects the incoming call from SSP 108, and SSP 108 continues down the calling feature hierarchy associated with PSTN extension 104 to route the call, or simply generates a "busy" tone, in step 710.

Alternatively, if the user of client computer 102 chooses to accept the call in step 716, ISP 120 completes a communication connection between communication line 123 and communication line 122 acting as a "bridge" between handset 140 and internet telephony enabled client computer 102, in step 718. In particular, ISP 120 digitizes and compresses inbound call signals received from handset 140 on communication line 123 and interleavingly delivers the encoded call signals to client computer 102 via communication line 122, SSP 108 and communication line 106, or, in other words, via the previously established data connection. The compressed inbound call signals will be decompressed by the communication interface of client computer 102 and rendered by the internet telephony application. Likewise, outbound call signals emanating from client computer 102 will be digitized by the audio interface and compressed by the communication interface of client computer 102 and interleavingly delivered to ISP 120 wherein they will be decompressed and rendered for the benefit of the user of telephone handset 140. That is to say, ISP 120 converts the voice information between PSTN and IP protocols and interleaving delivers call signals to/from telephone handset 140 and client computer 102 until call completion, and the method ends in step 720. Once the internet data connection is completed, the user of client computer 102 enters a feature_disable key sequence (e.g., *72) using the telephone handset connected to PSTN extension 104 disabling the call forwarding feature at the switch of SSP 108, thereby enabling PSTN extension 104 to receive telephone calls as normal. In alternate embodiments, the feature_disable key sequence may also be implemented as part of a modem disconnection sequence, thereby relieving the user of client computer 102 with having to remember to disable the call forwarding feature.

Thus, for the illustrated embodiment of Figure 1, ISP 120 enables a user of handset 140 to call the user of client computer 102 by dialing the telephone number for extension 104, and converse with the user of client computer 102, even when user of client computer 102 is already using extension 104 to support a data connection with Internet 150. In addition to allowing the user of client computer 102 to receive incoming calls from a remote telephone handset (e.g., handset 140), the present invention contemplates that ISP 120 may also incoφorate a number of additional value added features such as voice mail, caller identification (via ANI) and the ability to recognize and display the originator of the incoming call (e.g., from within a PBX system) as well as the call type (i.e., voice, fax, video, etc.) with the ability to route the call to an alternate location that is best-suited to handle the incoming call.

In addition, it will be recognized by those skilled in the art that the number of calls received by the user of client computer 102 is limited only by the number of extensions connected to communication lines 123, and the bandwidth available on the communication connection between client computer 102 and ISP 120. Therefore, if client computer 102 employs a 28.8 kbps modem to support the data connection to ISP 120, and a full duplex voice connection typically consumes between 5 and 10 kbps, it is possible to support multiple voice connections within the 28.8 kbps bandwidth constraint imposed by the modem, for example. Thus, in one embodiment of the present invention, ISP 120 may support several simultaneous (e.g., conferencing) voice connections to the user of client computer 102 within the bandwidth constraint of the modem, wherein the user of client computer 102 may simultaneously communicate with all of the callers (provided that the internet telephony application resident on client computer 102 supports such a conferencing feature). In alternate embodiments, where the available bandwidth or internet telephony software resident on client computer 102 cannot not support multiple simultaneous voice connections, ISP 120 may receive and support multiple calls to the user of client computer 102, where the user of client computer 102 must selectively communicate with individual calls by placing the other(s) on hold.

Jumping back to Figures 4 and 5, two block diagrams illustrating the hardware and software elements of exemplary computer server 400, suitable for use as ISP 120 (or, in alternate embodiments, an AP/1SP combination) are shown. As illustrated in Figure 4, exemplary computer server 400 is comprised of multiple processors 402a - 402n and memory subsystem 408 coupled to processor bus 404 as depicted. Additionally, computer server 400 is comprised of a second bus 412 and a third bus 410. In one embodiment of the present invention bus 412 is a Peripheral Component Interconnect (PCI) bus 412, while bus 410 is an Industry Standard Architecture (ISA) bus 410. PCI bus 412 and ISA bus 410 are bridged to processor bus 404 by I O controller 406. Coupled to ISA bus 410 are display 414, keyboard and cursor control device 424 and mass storage device 422 (e.g., hard drive). Additionally, exemplary computer server 400 is shown comprising PSTN interface 416 and Signaling System 7 (SS7) Interface 418.

As depicted in Figure 4, PSTN interface 416 provides the necessary hardware to interface exemplary computer server 400 to a plurality of PSTN communication lines (e.g., l ^c\

Tl, El or POTS), wherein the actual number of PSTN communication lines interfaced will be implementation dependent. Additionally, PSTN interface 416 provides advanced DSP-based voice, dual-tone multiple frequency (DTMF) and call progress functionality, which allows for downloadable DSP protocol and voice processing algorithms, thereby providing CODEC support locally on the interface. Examples of supported codecs include the Global System for Mobile Communications (GSM) codec and the ITU-T G.723.1 protocol codecs, the specification for which are commonly available from the GSM consortium and the International Telecommunications Union, respectively. Similarly, SS7 interface 418 provides the hardware necessary to interface exemplary computer server 400 with PSTN trunk lines (e.g., ISDN) supporting the out-of-band communication protocol (e.g., Signaling System 7 (SS7)) used between PSTN network elements (i.e., SSP-SSP, SSP-STP, STP-SCP, etc.). In one embodiment of the present invention PSTN interface 416 is preferably an AG-T1™ (for U.S. implementations, while an AG-E1 may be seamlessly substituted for European implementations), while SS7 interface 418 is preferably the TX3000™, both of which, along with their accompanying software drivers, are manufactured by and commonly available from Natural MicroSystems of Natick, Massachusetts. Otherwise, all other elements, processors 402, memory system 408 and so forth perform their conventional functions known in the art. Insofar as their constitutions are generally well known to those skilled in the art, they need not be further described.

From a software perspective, Figure 5 illustrates the software elements of exemplary computer server 400. In particular, exemplary computer server 400 is shown comprising an application layer consisting of Hop-on driver 502 and interapplication manager (Management Driver) 504. Hop-on driver 502 and Management Driver 504 implements the method steps of Figures 2 and 3 as well as Figure 7 that are the responsibility of ISP 120 using services abstracted through SAL 506. The Service Abstraction Layer (SAL) 506 is shown comprising Signaling System 7 (SS7) Services 508, Telephony Services 510, Streaming Services 512, Connection Services 514 and Data Services 516. The interface layer is shown comprising Telephony Application Programming Interface (API) 520, PSTN Data interface 522 and Connection/Compatibility Interface 524. The driver layer is shown comprising SS7 driver 518, PSTN driver 526 and Winsock/2 standard drivers (e.g., TCP/IP, etc.) 528, all of which exchange information in the fashion depicted in Figure 5.

Within the context of the present invention, one puφose of SAL 506 is to provide and Application Programming Interface (API) for all the available services in exemplary computer server 400. The API will abstract out the actual modules used for providing services such as connection establishment (514), streaming and data exchange services (512, 516). Additionally, SAL 506 provides the common operation tools such as queue management, statistics management, state management and the necessary interface between the plug-in services (i.e., drivers in the driver layer). SAL 506 is also responsible for loading and unloading the appropriate drivers as appropriate.

Streaming service 512 is responsible for interfacing with the components that provide the real-time streaming functionality for the multimedia data. Once the connection has been established between the connection points (i.e., PSTN, H.323 or Wave files), streaming service 512 will take over the management and streaming of data between the two connected parties, until the connection is terminated. Similarly, data service layer 516 is responsible for providing non real-time peer to peer (i.e., computer-computer) messaging and data exchange between exemplary computer server 400 and other Internet and perhaps PSTN based applications. Sending messages to exemplary to computer server end-points (i.e., other similarly equipped ISPs on the Internet) or other servers within the PSTN is accomplished via data service layer 516. Connection service 514 works in conjunction with streaming services 512 and data services 516. In particular, connection service 514 includes a connection establishment and tear-down mechanism facilitating the interconnection to the PSTN. Additionally, for the illustrated embodiment, connection service 514 employs connection and compatibility services 524 which facilitate interoperation between communication equipment that support industry standards, thereby allowing a variety of communication equipment manufactured by different vendors to be benefited from the present invention. Connection and compatibility services 524 include, in particular, services for supporting standard video telephony, such as ITU-T's H.323 video telephony, and standard data communication, such as ITU-T's T.120 data communication protocol. Examples of the connection establishment and tear-down mechanisms supported by connection service layer 514 include opening and starting PSTN ports, call control, DTMF collection, and tone generation, to name but a few.

As alluded to with respect to Figure 4, SS7 driver 518 and PSTN driver 526 serve to integrate SS7 interface 418 and PSTN interface 416 with the other features and functions of exemplary computer server 400. As illustrated in Figure 5, SS7 driver 518 communicates with SS7 service layer 508, while PSTN driver 526 communicates with telephony API 520 and PSTN data API 522.

Telephony services 510 service all communications with client computers, such as client computer 102 using telephony API 520 and PSTN driver 526. Telephony services 510 include in particular services for handling computer telephony 506, and automatic call distribution (ACD) necessary for Private Branch Exchange (PBX) based systems. PSTN driver 526 is equipped to facilitate the above described compression and transmission of inbound call signals from handset 140 as well as decompression and transmission of outbound call signals from client computer 102. PSTN driver 526 supports these functions with the necessary interfaces to accommodate both trunk line and POTS communication line interfaces common to SSP 108. Implementation of these services, as described above, is well within the ability of those skilled in the art of, for example, telecommunications.

Although depicted as separate entities in Figure 1, those skilled in the art will appreciate that AP 112 and ISP 120 are both, essentially, computer servers and may, in one embodiment be the same computer server. In such an embodiment, communication line 118 represents a communication bus internal to the combined AP/ISP server. Alternatively, AP 112 and ISP 120 may be co-located in a local office of PSTN 170 as part of a common Local Area Network (LAN), where in such an embodiment communication line 118 represents a LAN communication path such as, for example, an Ethernet communication line. In yet another alternative embodiment, AP 112 may be located in a local office (not shown) of PSTN 170, while ISP 120 is remotely located, wherein such instance communication line 118 represents a digital control line to AP 112 allowing for out-of-band signaling communication. An example of such a communication system architecture is illustrated in Figure 6.

In particular, Figure 6 illustrates a block diagram of an alternative communication system architecture incoφorating the teachings of the present invention. As illustrated, the elements of communication system 600 are much the same as the architecture depicted in exemplary communication system 100, with the primary distinction arising from the remote placement of ISP 120. In particular, in communication system 600, ISP 120 and AP 112 are incoφorated with the teachings of the present invention, however, communication between these network elements must occur via a PSTN trunk line 602. An example of a trunk line suitable for use as trunk line 602 is a primary rate ISDN (PRISDN) line, well known to those skilled in the art. Except for the location of ISP 120 relative to AP 112, the operation of the present invention is much the same as that previously described. Thus, a method and apparatus for connecting an incoming call to a computer system that is already engaged in a communication session has been described. While the internet telephony call feature of the present invention has been described in terms of the above illustrated embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments so described. For example, the Public Switched Telephone Network and the Internet are complex communication systems and, therefore, a number of alternative variations of the present invention may be practiced without deviating from the spirit and scope of the present invention. Further, although the exemplary embodiments were presented in the context of the PSTN, one skilled in the art will appreciate that the spirit and scope of the present invention lends itself equally well to the world of wireless communications. For example, the present invention anticipates that the originator of the telephone call could be call from a cellular telephone; or that the client computer could be coupled to a wireless communications network via a wireless communications modem over a wireless communication channel, in which case, in accordance with the present invention, the telecomputing session would not necessarily prohibit the receipt of incoming cellular calls to the wireless handset. Thus, the present invention may be practiced with modification and alteration within the spirit and scope of the appended claims. Accordingly, the description is to be regarded as illustrative instead of restrictive on the present invention.

Claims

CLAIMS A ╬«We claim:

1. A server configured to connect an incoming call to a client computer, wherein the call is generated by a telephone handset destined for a local PSTN extension that is already in use by the client computer communicating with the server for another pu╧åose, the server comprising: a storage medium having stored therein a plurality of programming instructions for implementing communication services for facilitating the connection of the incoming call to the client computer, wherein the communication services include services for answering the incoming phone call on behalf of the client computer and interleavingly delivering incoming call signals to the client computer, and accepting interleaved outbound call signals from the client computer and transmitting outbound call signals on behalf of the client computer to the telephone handset; and an execution unit, coupled to the storage medium, for executing the programming instructions.

2. The server of claim 1 , wherein the communication services further include services for communicating with a Service Switching Point (SSP) of the PSTN to route any call destined for a local PSTN extension to the server when the local PSTN extension is already in use by the client computer communicating with the server for another pu╧åose.

3. The server of claim 2, wherein the communication services further include services for informing the user of client computer of the incoming call and providing the user with alternate delivery options. A

4. The server of claim 3, wherein the communication services include accepting the call on behalf of the client computer and providing a communications interface between the user of the client computer and the remote PSTN extension.

5. The server of claim 3, wherein the delivery options include sending the incoming call to voice mail.

6. The server of claim 3, wherein the delivery options include sending the incoming call to an alternate PSTN extension.

7. The server of claim 1 , further comprising an audio interface codec for encoding incoming call signals destined for the client computer, and for decoding outbound call signals destined for the remote PSTN extension.

8. The server of claim 7, wherein the audio interface codec is a Global System for Mobile Communication (GSM) standard codec.

9. The server of claim 7, wherein the audio interface codec is an ITU-T G.723.1 compatible codec.

10. The server of claim 7, wherein the audio interface codec is compatible with the audio interface codec utilized in the client computer.

11. The server of claim 1 , wherein the communication services include services for requesting a caller identification from the PSTN.

12. The server of claim 1, wherein the communication services further include services for packing the incoming call signals into packets for delivery to the client computer, and unpacking the outbound call signals for transmission to the remote telephone handset.

13. A method for connecting an incoming call to a client computer, wherein the call is generated by a telephone handset destined for a local PSTN extension that is already in use by the client computer communicating with a server for another pu╧åose, the method comprising the steps of:

(a) detecting the incoming call destined for the PSTN extension at the service switching point (SSP) determining whether to route the call to the server;

(b) signaling the client computer from the server of the incoming call and providing the user with a plurality of delivery options from which to select; and

(c) answering the incoming call at the server on behalf of the client computer and interleavingly delivering incoming call signals to the client computer, and accepting interleaved outbound call signals from the client computer and transmitting the outbound call signals to the telephone handset on behalf of the client computer, based on the delivery option selected.

14. The method of claim 13, wherein the SSP accesses a database of communication features to determine whether the PSTN extension is internet telephony enabled, and communicating with server to determine whether server has communication ports available through which the incoming call may be received.

15. The method of claim 14, wherein the communication between the SSP and the server occurs via an out-of-band signaling protocol.

16. The method of claim 15, wherein the out-of-band signaling protocol is Signaling System 7 (SS7).

17. The method of claim 13, wherein plurality of delivery options includes routing the incoming call to a PSTN-based voice mail server.

18. The method of claim 13, wherein the plurality of deliver options includes routing the incoming call to an alternate PSTN extension.

19. The method of claim 13, wherein the step of signaling the client computer of the incoming call further includes providing the user with information regarding the incoming call.

20. The method of claim 19, wherein the information regarding the incoming call includes an identification of the origination of the incoming call.

21. The method of claim 19, wherein the information regarding the incoming call includes an identification of call type.

22. The method of claim 21 , wherein the call type is a voice type call.

23. The method of claim 21 , wherein the call type is a facsimile type call.

24. The method of claim 13, wherein multiple incoming calls are received and simultaneously supported through the server.

25. An apparatus configured to connect an incoming call from a remote telephone handset to a user of a client computer already engaged in a data communication session with a server through a local PSTN extension, the apparatus comprising: a plurality of interface ports including a signaling port configured to support out-of- band signaling between the apparatus and a Service Switching Point (SSP) of the PSTN; a storage medium having stored therein a plurality of programming instructions for implementing communication services for facilitating the connection of the incoming call to the client computer, wherein the communication services include services for answering the incoming call on behalf of the client computer and interleavingly delivering incoming call signals to the client computer, and accepting interleaved outbound call signals from the client computer and transmitting the outbound call signals on behalf of the client computer to the remote telephone handset; and an execution unit, coupled to the storage medium and the plurality of interface ports, for executing the programming instructions and supporting the interface with the PSTN.

26. An Adjunct Processor (AP), coupled to a Service Switching Point (SSP) in a public switched telephone network (PSTN), is configured to connect an incoming call to a client computer, wherein the incoming call is initiated by a telephone handset bound for a PSTN extension, wherein the PSTN extension is currently engaged by a client computer in a data communication session with a server on a public computer network, the AP comprising: a storage medium having stored therein a plurality of programming instructions for implementing communication services for facilitating the connection of the incoming call to the client computer, wherein the communication services include services for answering the incoming call on behalf of the client computer and interleavingly delivering incoming call signals to the client computer, and accepting interleaved outbound call signals from the client computer and transmitting the outbound call signals on behalf of the client computer to the telephone handset, as well as programming instructions integrating the AP with the public computer network; and an execution unit, coupled to the storage medium, for executing the programming instructions.

27. A method for connecting an incoming call, initiated by a telephone handset, bound for a public switched telephone network (PSTN) extension that is already engaged by a client computer for data communications with a server, the method comprising the steps of: a) detecting the incoming call bound for the PSTN extension at a service switching point (SSP) servicing the PSTN extension; b) reviewing the call feature hierarchy associated with the PSTN extension to determine if it has an internet telephony call feature; c) determining whether the server has capacity available with which to answer and route the incoming call to the client computer, based on the result of the call feature review; and d) forwarding the call to the server, which answers the telephone call on behalf of the PSTN extension and interleavingly delivers incoming call signals to the client computer, and accepts interleaved outbound call signals from the client computer and transmits the outbound call signals to the telephone handset on behalf of the client computer, based on the step of determining whether the server has available capacity.

28. The method of claim 27, wherein the step of determining whether the server has capacity available comprises the step of determining whether the server has available communication ports with which to answer and route the call to client computer.

29. The method of claim 27, wherein the step of determining whether the server has capacity available comprises out-of-band communication between the SSP and the server. 3

30. A method for connecting an incoming call, initiated by a telephone handset, bound for a public switched telephone network (PSTN) extension that is already engaged by a client computer for data communications with a server, the method comprising the steps of: a) enabling a call forwarding feature associated with the PSTN extension by a user of the client computer prior to commencement of data communications with the server, forwarding all incoming calls bound for the PSTN extension to the server; b) detecting the incoming call bound for the PSTN extension at a service switching point (SSP) servicing the PSTN extension; c) determining whether the server has capacity available with which to answer and route the incoming call to the client computer, based on the result of the call feature review; and d) forwarding the call to the server, which answers the telephone call on behalf of the PSTN extension and interleavingly delivers incoming call signals to the client computer, and accepts interleaved outbound call signals from the client computer and transmits the outbound call signals to the telephone handset on behalf of the client computer, based on the step of determining whether the server has available capacity.

31. The method of claim 30, further comprising step: e) disabling the call forwarding feature upon completion of data communications with the server.

32. The method of claim 30, wherein the step of enabling the call forwarding feature at the SSP comprises the step of entering an feature_enable key sequence at the PSTN extension and received by the SSP, for configuring the SSP to forward incoming calls bound for the PSTN extension to the server.