Establishing a collect call through a packet based network

CA 02454504 2009-04-28

ESTABLISHING A COLLECT CALL THROUGH A PACKET BASED NETWORK

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to the field of telecommunications and, in particular to a method and apparatus for establishing a call by way of an electronic message originated through a packet based network.

2. Background of the Invention

In recent years, information technology including personal computer, telecommunication, and television technologies have begun to converge, whereby clear demarcations that once separated the various technologies have blurred. This convergence” may be attributed, at least in part, to the explosive growth of the Internet.

Internet based voice communication is one advance in the telecommunications industry that has been made possible through the growth of the Internet. For example, calls that were once required to be managed by the public switched telephone network (PSTN) that assigns a dedicated communication line or circuit for each user to complete a telephone call, may now be connected through the shared medium of the Internet by breaking the voice data into varying sized packages or packets,” and transmitting them over the shared medium of the Internet.

The Internet Protocol (IP) is utilized throughout the Internet to interleave and transmit data packets so as to best utilize the available bandwidth at any given time. Voice over IP (VoIP) is a term used to describe a set of services for managing the delivery of voice information using the Internet protocol. Various software products on the market provide VoIP services that enable two parties (e.g., caller and callee) to communicate with each other through the Internet. In order to do so, however, each of the parties to the VoIP call are typically required to communicate through

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 hardware utilizing compatible voice encoders or “CODECs.” Although emerging standards such as the International Telecommunication Union’s (ITU) H.323 standard attempts to alleviate the CODEC compatibility issue, the parties to the call are nonetheless each required to communicate through a computer system or appliance equipped to place and/or receive VoIP calls. Unfortunately, however, not everyone has access to such VoIP equipped hardware. In fact, given the wide availability of PSTN handsets and their associated ease of use, even those who have access to such VoIP equipped hardware may nonetheless prefer to communicate via the more commonplace PSTN handsets.

U.S. Patent number 6,026,087, titled “Method and Apparatus for Establishing a Voice Call to a PSTN Extension for a Network Client Computer” addresses the need for bridging the Internet and packet based devices with conventional PSTN handsets. Accordingly, a user of a networked computer can place a voice call to a PSTN extension (equipped with merely a conventional handset) rather than being limited to placing a voice call to only VoIP equipped hardware. Although this goes a long way towards integrating the VoIP functionality of the Internet with the PSTN, further integration remains desirable.

More specifically, despite the progress made to date in integrating the two communication networks, some desirable features currently available through traditional telephone communication networks remain conspicuously absent from Internet telephony. Once such feature missing from Internet telephony is the ability for a calling party to initiate an Internet based call to a callee with the callee being assessed any communication charges associated with such a call.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is illustrated by way of exemplary, and not by way of limitation in the figures of the accompanying drawings in which like reference numerals refer to similar elements, and in which.

Page 2

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

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

Figure 2 is a flow diagram illustrating one embodiment of a method for establishing a voice communication session between two parties by way of an electronic mail message;

Figure 3 illustrates an operational flow of a VoIP to PSTN collect call in accordance with one embodiment of present invention;

Figures 4(A-B) illustrate various exemplary graphical dialogs that may be presented by a web server to solicit call-related information from a caller including information reflecting the type of call to be established as well as the identity of the callee and the caller;

Figure 5 is an operational flow diagram illustrating the preauthorization aspect of the present invention, in accordance with one embodiment in which a PSTN to PSTN collect call is to be established;

Figure 6 illustrates an exemplary graphical dialog through which a callee may provide billing information against which the costs of a preauthorized communication session may be charged;

Figure 7 illustrates an exemplary computer system suitable for use as client computer 108 and/or web server 128;

Figure 8 illustrates one embodiment of an operational flow of the present invention in which a PSTN to PSTN collect call is to be established;

Figures 9 (A-G) are graphical illustrations, each representing various data input dialogs presented to an offeror in association with generation of one or more of the tokens according to one embodiment of the present invention;

Figures 10 (A-B) are a graphical representation illustrating one embodiment of how an electronic token generated in accordance with the . teachings of the present invention may be displayed in association with an electronic mail message;

Figure 11 illustrates an exemplary computer system suitable for use as a web server and/or one or more of client computers incorporating the teachings of the present invention;

Page 3

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

Figure 12 is a flow diagram illustrating a method for establishing a voice communication session between an offeree and a destination party based upon a conditional offer in accordance with one embodiment of the present invention; and

Figure 13 illustrates two examples of an XML data structure each representing an electronic token according to one embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

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 invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without these specific details. In some instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention. In other instances, well known features are omitted or simplified in order not to obscure the present invention. 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. Furthermore, reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.

In Figure 1, a block diagram is presented illustrating an exemplary communication system 100 incorporating the teachings of one embodiment of the present invention. While the present invention will be described in the context of this exemplary communication system, based on the descriptions to follow, those skilled in the art will appreciate that the present invention is not limited to this embodiment. Referring now to Figure 1, client 108, handsets

Page 4

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

117 and 142, web server 128, and bridge servers (hereinafter “bridgeports”) 162 and 165 are communicatively coupled to each other by way of PSTN 140 and Internet 150 as shown.

Client 108 is intended to represent a broad category of internet telephony enabled devices such as a computer system, palm sized personal digital assistants (PDA), Internet appliance, set-top box, and so forth. Figure 7 (described below) illustrates an exemplary computer system that may be used as client 108. As illustrated in Figure 1, client 108 is communicatively coupled to ISP 112 via network connection 110. In turn, ISP 112 is coupled to Internet 150 via direct connection 114, and is coupled to PSTN 140 via PSTN extension 115 and communication line 113. Accordingly, client 108 may communicate with a variety of devices coupled to PSTN 140 and/or Internet 150 by way of ISP 112. Client 108 may further be coupled to PSTN 140 and/or Internet 150 through connections unrelated to ISP 112. For example, client 108 may be coupled to PSTN 140 by way of PSTN extension 119 and communication line 121 as shown. Similarly, client 108 may be coupled to Internet 150 by way of one or more other direct or indirect connections (not shown).

Handsets 117 and 142 are intended to represent a broad category of conventional telephone handsets known in the art, including but not limited to desktop handsets, cordless handsets and wireless handsets. Handset 142 is coupled to PSTN 140 through PSTN extension 143 and communication line 144, whereas handset 117 is coupled to PSTN 140 through shared PSTN extension 119 and communication line 121. In the illustrated embodiment, handset 117 is associated with client 108. That is handset 117 and client 108 are considered to be collocated and may even be coupled to one another (through e.g. a MODEM).

Communication lines 113, 114, 144, and 121 may simply be plain old telephone service (POTS) communication lines, although other types of communication lines may be used. For example, communication line 121

Page 5

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 may be an integrated service digital network (ISDN) line, whereas communication line 113 may be a T1 (1.533 Mbps) or an E1 (2.0488 Mbps) trunk line. Each of communication lines 144 and 121 may further be a wireless cellular connection, a Personal Communication Services (PCS) connection, and the like.

Internet 150 includes a number of local and/or global networks interconnected by routers to communicatively couple the various client computers, web servers and bridgeports of Figure 1 together. PSTN 140 on the other hand, includes a number of Service Switching Points (SSP), Signal Transfer Ponts (STP), and Service Control Points (SCP) coupled to each other (not shown). PSTN extension 143 is coupled to a “local” SSP of PSTN 140 through communication line 144. The “local” SSP in turn is coupled to a number of other “local” PSTN extensions, including for example, PSTN extension 115 assuming ISP 112 is a “local” ISP served by the same SSP. In addition, the “local” SSP is also coupled to an associated STP, which in turn is coupled to other “remote” SSPs. Each of the “remote” SSPs is coupled to a number of “remote” PSTN extensions, including for example, extension 119 assuming handset 117 is a “remote” handset served by a “remote” SSP.

Bridgeports 162 and 165 are coupled to Internet 150 through network connections 164 and 167 respectively, and to PSTN 140 through communication lines 163 and 166 respectively. In accordance with one embodiment, each of bridgeports 162 and 165 represent a bridge sever to bridge voice calls between two endpoints. In one embodiment, at least one of bridgeports 162 and 165 facilitate establishment of a voice call between two PSTN extensions, whereas in another embodiment, at least one of bridgeports 162 and 165 operate to facilitate establishment of a voice call between a COIP equipped device (e.g. client 108) and a PSTN extension (e.g. handset 142). In accordance with one embodiment of the invention, each of bridgeports 162 and 164 further include services to determine an appropriate one of the community of Internet/PSTN changeover servers (e.g. bridgeports 162 and 165) to bridge the voice calls. Additional details

Page 6

CA 02454504 2009-04-28 regarding the functionality of bridgeports 162 and 165 may be found in U.S. patent number 5,889,774, titled Method and Apparatus for Selecting an Internet/PSTN Changeover Server for a Packet Based Phone Call (having a common assignee with the present application).

Web server 128 is coupled to Internet 150 through connection 130, but may also be coupled to PSTN 140 by way of additional connections (not illustrated). In one embodiment, web server 128 is an Internet portal. In alternate embodiments, web server 128 may be a e-commerce site or a corporate presence web server. Web server 128 includes services to generate an electronic collect calling button, whose selection would cause at least one of bridgeports 162 and 165 to establish and facilitate a voice communication session between two parties based at least in part upon data provided by one of the parties (e.g. client 108). Further, at least a subset of the costs associated with one or more voice communication sessions established between a call-initiating party (i.e. caller) and a designated call-receiving party (i.e. callee) will be charged to the callee rather than the caller. Typically, the electronic collect call button is disposed in a content page of web server 128. The services in support of the inclusion of the electronic collect call button is executed on web server 128, whereas the services in support of the communication with bridgeports 162 and 165 to facilitate the establishment of the collect call is embedded with the content page and executed on the caller's computing device. However, in alternate embodiments, the services in support of the communication with bridgeports 162 and 165 to facilitate the establishment of the collect call may be executed on web server 128 instead. For the purpose of this discussion, the party that causes a collect calling token to be generated is referred to as the caller/offeror, whereas the party that is charged with costs associated with the collect call is referred to as a callee/offeree.

In one embodiment, the embedded services (or hosted services on web server 128) generate a collect calling token based at least in part upon

Page 7

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 calling information provided by the caller. Each collect calling token may contain various amounts of contact information. In one embodiment, the collect calling token is self-describing in that it has encoded within it, ail contact information necessary to facilitate a call between two parties, such as a caller and a callee. Such contact information may include PSTN extensions and/or IP addresses of the callers, the callee, and the bridgeport used to bridge the two calls. In the case of a self-describing electronic token, the bridgeport need not be notified of the electronic token’s existence except upon the collect calling token becoming activated. In an alternative embodiment, the collect calling token had encoded within itself less than all necessary contact information. For example, in a basic implementation, the collect calling token may only include a bridgeport address and a call identifier identifying the callee. The bridgeport, whose address is encoded within the collect calling token, stores the remaining contact information in association with the call identifier. When the collect calling token is activated, the identified bridgeport is contacted and the bridgeport performs a lookup to correlate the stored contact information with the call identifier. A collect calling token may be activated by e.g. a user selecting or “clicking” on graphical representation of the token with a user input device such as a mouse. In one embodiment of the invention, the electronic token is implemented as an extended markup language (XML) data structure, however, the electronic token may also be implemented as a standard generalized markup language (SGML) data structure, or in other embodiments, other programming languages may be used.

In the event the collect calling token is generated by e.g. hosted services of web server 128, the collect calling token may be transmitted by web server 128 to the caller for subsequent activation by the caller, or the collect calling token may be transmitted to a bridgeport, which utilizes the calling token to automatically (i.e. without further human intervention) initiate the requested collect call upon its receipt. In an embodiment where web server 128 additionally includes bridgeport functionality, web server 128 may

Page 8

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 automatically initiate the requested collect call upon generation of the collect calling token.

Figure 2 illustrates one embodiment of an operational flow of the present invention in which a PSTN to PSTN collect call is to be established. The process begins at block 202 where an offeror client computer, such as client 108, connects to Internet 150 (via e.g. ISP 112) and accesses one or more web pages presented by web server 128 (e.g. as shown in Figures 4(AB)). In accordance with the teachings of the present invention, web server 128 presents one or more “web pages” to client 108 to facilitate the provision of call related data by client 108. For example, web server 128 may project one or more web pages including one or more hypertext elements, such as text boxes, radio buttons, drop-down menus and so forth, including in particular, the earlier described electronic collect call button, through which client 108 may interact to provide call-related information.

At block 203, client 108 identifies such call related information to facilitate generation of the collect calling token of the present invention. The call related information might include information identifying the party to be called (i.e. callee), the calling party (i.e. caller), as well as the type of call to be placed. In one embodiment, the called is identified by the PSTN extension (or other alphanumeric identifier) associated with the callee. In another embodiment, the callee is identified from a list of possible callee candidates presented to the caller. In the illustrated embodiment (i.e. involving a PSTN to PSTN based voice call), client 108 identifies both a PSTN extension associated with the callee to be called and a PSTN extension associated with the caller (i.e. client 108) to web server 128.

Once client 108 has indicated the various call information, the embedded services (or hosted services on web server 128) generates the collect calling token representing the indicated information for transmission across e.g. Internet 150, block 204. In one embodiment, the collect calling token is generated as an extended markup language (XML) based data

Page 9

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 structure utilizing encoded representations of the calling information indicated by the callee. Next, the collect calling token is transmitted to an identified bridgeport, block 206. In one embodiment, the bridgeport is identified by client 108, whereas in another embodiment, the bridgeport is identified by web server 128 based upon the identity of the callee as provided e.g. by the caller. For example, web server 128 may identify the bridgeport as being best equipped amongst a plurality of bridgeports to bridge a call between the caller and the callee. Such a determination may be made based upon the PSTN extension associated with the callee, the PSTN extension associated with the caller, or the geographic location of the caller and/or callee, for example.

Upon receiving the collect calling token, the bridgeport places a first voice call to the PSTN extension of the identified callee, block 208. The PSTN extension of the callee may be encoded within the collect calling token, or the bridgeport may perform a lookup to determine the appropriate PSTN extension of the callee. In the event the callee answers the call, the bridgeport further queries the callee as to whether they wish to accept costs associated with the voice communication session to be established between the caller and the callee, block 210. For example, upon the callee answering the call from the bridgeport, the bridgeport may announce a message to the callee such as “Bob is attempting to make a collect call. If you wish to accept the costs associated with completing this call press or say ‘T. If you do not whish to accept the costs, press or say ‘2’.” Thus, the callee may agree or disagree to accept the charges as they so desire. In accordance with the illustrated embodiment, if the callee does not agree to accept the charges (block 212), the bridgeport notifies the caller that the callee did not accept the charges, block 214. Such a non-acceptance notification may be transmitted directly to client 108 in the form of an audio, text and/or graphical representation (using e.g. the IP address of client 108). However, if the callee manifests their intent to accept the charges (block 212), the bridgeport server places a voice call to the PSTN extension associated with the caller (e.g. as stipulated by the collect calling token) and bridges that call with the voice link established between the bridgeport and the callee, block 216.

Page 10

CA 02454504 2004-01-20

WO 03/009550

PCT/US02/22980

Figure 3 illustrates an operational flow of a VOIP to PSTN collect call in accordance with one embodiment of present invention. As was described above with respect to Figure 2, the process depicted in Figure 3 also begins with a client connecting to Internet 150 and accessing one or more web pages presented by the web server, block 302. At block 304, the client indicates call related information to the web server through e.g. one or more graphical dialogs such as those shown below in Figures 4(A-B). Once the indicated call information is provided, web server 128 generates a collect calling token, block 306. In the illustrated embodiment, once the collect calling token is generated, it is transmitted to the client (block 308) rather than to the bridgeport as was the case in the process flow of Figure 2. In one embodiment, the token is linked to a graphical “button” displayed as one component of a web page projected to the client (i.e. via HTTP) by the web server. In an alternative embodiment, the collect calling token may be emailed to the client (i.e. via SMTP) for subsequent activation.

Upon the client activating the collect calling token, a data collection is established between the client and the bridgeport identified by the token (i.e. via the bridgeport’s IP address), block 310. Once the bridgeport has been contacted by the client, the bridgeport establishes a voice call to the callee also indicated by the token, block 312. In the event the callee answers the call, the bridgeport server further queries the callee as to whether they wish to accept any costs associated with the communication session to be established between the caller and the callee, block 313. In accordance with the illustrated embodiment, if the callee does not agree to accept the costs (block 314), the bridgeport returns a message to the caller indicating that the callee did not accept the costs, block 316. However, if the callee agrees to accept the costs (block 314), the bridgeport server bridges the voice link established between the bridgeport and the callee with the data link established between the bridgeport and the client to place the client and the callee in voice communication with each other, block 320.

Page 11

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

Figures 4(A-B) illustrate various exemplary graphical dialogs that may be presented by a web server to solicit call-related information from a caller including information reflecting the type of call to be established as well as the identity of the callee and the caller. More specifically, Figure 4A illustrates a graphical dialog that may be presented by a web server such as web server 128, to enable a caller to select the type of call to be established. In the illustrated embodiment, the caller may choose from a VOIP to PSTN based call and a PSTN to PSTN based call.

Figure 4B illustrates a graphical dialog that solicits call information related to the identity of the callee, and optionally the identity of the caller. As described above, the callee may be identified through provision of an alphanumeric identifier, such as a PSTN extension known to be associated with the callee, or by way of the callee’s name. In one embodiment, the web server hosting the illustrated dialog presents a list of potential callees to the caller as maintained e.g. in a database. The list of callees may be provided by the hosting web server as part of a subscription based service in which subscribing callees register their names along with one or more associated PSTN extensions. The dialog depicted in Figure 4B additionally illustrates a data entry mechanism whereby the caller may provide an identifier representing e.g. a PSTN extension they wish to have called when establishing a PSTN to PSTN based voice call.

Although the previously illustrated embodiments describe a process whereby the callee is queried before accepting costs associated with a voice communication session, there may be times when it is not convenient for the callee to be queried as such. Therefore, in accordance with one embodiment of the invention, the callee is provided with the ability to preauthorize costs associated with one or more voice communication sessions to be established between one or more callers and the given callee. Accordingly, the callee need not be queried each time a preauthorized caller or a caller associated with a preauthorized PSTN extension initiates a call with the callee.

Page 12

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

Figure 5 is an operational flow diagram illustrating the preauthorization aspect of the present invention, in accordance with one embodiment in which a PSTN to PSTN collect call is to be established. The process is similar to that described above with respect to Figure 2 and begins with a client connecting to Internet 150 and accessing one or more web pages presented by the web server, block 502. Through the web pages, the client indicates call related information to the web server (block 503), which is then used to generate a collect calling token, block 504. Once the web server has generated the collect calling token, the web server transmits the collect calling token to an identified bridgeport, block 506, which then places a first voice call to an indicated PSTN extension of the callee, block 508.

Once the bridgeport has placed the first call to the callee, the bridgeport determines if the callee has preauthorized (i.e. authorized in advance) costs associated with the voice communication session to be established between the indicated caller and the callee be charged to the callee, block 511. In one embodiment, the callee preauthorizes such charges through one or more graphical dialogs presented to the callee by web server 128. An indication of the callee’s preauthorization may then be encoded within the collect calling token in the form of a tag generated by the web server. Figure 6 illustrates an exemplary graphical dialog through which a callee may provide billing information such as an account name and password (i.e. for a subscription based service), or credit card information against which the costs ofa preauthorized communication session should be charged.

Continuing with Figure 5, if at block 511 it is determined e.g. by examination of the collect calling token that the callee has preauthorized the costs associated with the pending voice communication session, the bridgeport server places a voice call to the PSTN extension associated with the caller and bridges that call with the voice already established between the bridgeport and the caller, block 516. However, if the callee has not preauthorized the charges associated with the communication session to be established, the bridgeport queries the callee as to whether they wish to

Page 13

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 accept the costs associated with the voice communication session to be established between the caller and the callee, block 510. If the callee then accepts the responsibility for paying the charges, the bridgeport bridges the respective calls to place the two parties in voice communication with each other (block 516). However, if the callee does not accept the responsibility to pay the costs, the caller is notified accordingly, block 514.

Although the present invention finds wide applicability with respect to domestic communication sessions, the present invention also proves advantageous to international communication sessions where a caller is based in one country and a callee is based in another country. This especially may be the case if the caller is located in a country where VOIP communications are deemed illegal or are otherwise not allowed. That is, by activating a collect calling token of the present invention, a caller located in one country may effectively initiate, via a packet based network, a collect PSTN to PSTN based call to a callee located in another country, while the costs of the call are billed to the callee at the (presumably) lower rates of the callee’s country.

For example, in accordance with the teachings of the present invention, a caller located in a fist country such as India would be able to gain access, by way of a local Internet service provider (ISP), to a web server projecting a collect calling token of the present invention. The caller could then activate the collect calling token, which would initiate an HTTP based connection to a bridgeport that is located in a second country such as the U.S. The bridgeport would either provide the caller with the bridgeport’s own IP address such that a TCP/IP connection could be established between the caller and that bridgeport, or the bridgeport would provide the caller with the IP address of a second bridgeport, such that a TCP/IP connection could be established between the caller and the second bridgeport. In accordance with one embodiment of the invention, the first bridgeport identifies a second bridgeport that is most proximate the first country without actually being located in the first country. For example, a first bridgeport located in the U.S. may identify

Page 14

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 and contact a second bridgeport that is located just outside (i.e. neighboring) the country of the caller.

Assuming the bridgeport returned its own IP address to the caller, the bridgeport would proceed to place a first PSTN based call to the callee in order to ascertain whether the caller wishes to accept the costs associated with the pending communication session with the caller. If the callee accepts the costs, the bridgeport would then place a second PSTN based call to the caller and subsequently bridge the two parties. However, assuming that the bridgeport returned the IP address of the second bridgeport, the second bridgeport would proceed to place a first PSTN based call to the callee in order to ascertain whether the callee wishes to accept the costs associated with the pending communication session with the caller. If the callee accepts the costs, the second bridgeport would then place a second PSTN based call to the caller and subsequently bridge the two parties. Whether the first bridgeport or the second bridgeport ultimately bridges the first and second calls, the result is that both calls are initiated from the second country (e.g. U.S.). Thus, the rates charged in association with the communication session will be determined as if it were a call that was initiated from the second country. Furthermore, since the bridgeport places the PSTN call into the first country, there are no regulatory concerns with the communication session being treated as a VOIP call originating from the first country even though the voice calls were initiated in the first country via a packet based network.

Figure 7 illustrates an example computer system suitable for use as client computer 108 and/or web server 128. As shown, system 700 includes one or more general purpose or special purpose processors 702, and system memory 706. Additionally, computer system 700 includes mass storage device(s) 707 (such as diskette, hard drive, CDROM and so forth), input/output devices 708 (such as keyboard, cursor control and so forth) and communication interface(s) 712 (such as network interface cards, modems and so forth). The elements are coupled to each other via system bus 714, which represents one or more buses. In the event that system bus 714

Page 15

CA 02454504 2009-04-28 represents multiple buses, the buses are bridged by one or more bus bridges (not shown). System memory 706 and mass storage device(s) 707 are employed to respectively store a working copy and a permanent copy of the programming instructions implementing the collect calling services of the present invention. Additionally, system memory 706 includes an operating system 715 with internetworking communication and socket services, and one or more telephony applications 716.

Figure 8 is a flow diagram illustrating one embodiment of a method for establishing a voice communication session between two parties by way of an electronic token of the present invention. In accordance with the illustrated embodiment, an offeror (i.e., client computer 102) causes web server 128 to generate an electronic token representing an offer to participate in a voice all (block 802). In an alternative embodiment, client 102 includes programming instructions that when executed, cause client computer 102 to generate the electronic token. Once the token representing the offer to participate in a voice call has been generated, the offeror such as client computer 102 transmits the generated token to an offeree such as client computer 116, in association with an electronic mail message (block 804). Upon receiving the electronic token from the offeror (block 806), the offeree activates the token by, for example, selecting a graphical icon representing the token with a user input device such as a mouse (block 808). Upon activation of the electronic token, a bridgeport designated by the electronic token is contacted. In one embodiment, the contacted Bridgeport places a first voice call to the designated offeree (block 810), and places a second voice all to the designated destination pally (block 812). In an alternative embodiment, as described in U.S. patent 5,889,774, the contacted Bridgeport is one of a community of bridgeports (i.e. bridgeports 162 and 165) that determine among themselves how best to complete the first and second calls. Once the respective voice calls have been placed to the designated offeree and destination party, the calls arc bridged by, for example at least one of bridgeports 162 and 165, so as to place the designated offeree and destination party in voice communication with each other (block 814). In

Page 16

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 one embodiment, the designated party is the offeror, however, the offeror need not necessarily be the destination party.

For example, a mother and father acting as offerors as well as the identified destination party, could generate or cause to have generated an electronic token that would be transmitted in association with an electronic mail message to their child who is away at college. Upon receiving the electronic token that has been either embedded within or attached to an email message from the parents, the child could activate the token by, for example, selecting a graphical representation of the token with a computer mouse. Upon activating the token, a first voice call would be placed from a bridgeport (e.g., bridgeport 162 and/or 165) to the child, and a second voice call would be placed from a bridgeport (e.g., bridgeport 162 and/or 165) to the parents. Thereafter, the two calls would be bridged to place the parents and the child in voice communication with one another.

Thus, in accordance with the teachings of the present invention, the token essentially functions as a preprogrammed virtual calling card that can be delivered from a first party to a second party for use by the second party in establishing a voice communication session with a designated destination party. Although the offeror and the destination party may be one of the same as in the parent/child example above, there are times when the destination party may not be the offeror, but rather a third party. For example, a mother and father may wish to deliver an electronic call token to their child, that when activated would place the child in voice communication with a grandparent, a family member, a friend, and so on. Similarly, the electronic calling token of the present invention could be used to place an offeree in voice communication with one or more designated business contacts, such as a family doctor, attorney, insurance agent, and so forth.

Although at times it may prove convenient for an offeror to designate the destination party that the offeree will be connected to upon activation of the token, it may also prove convenient for the offeror not to designate a

Page 17

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 destination party during token generation. In one embodiment of the invention, upon activation of the electronic call token, the offeree is given the option of providing an alphanumeric identified of a destination party to be called. Because the offeror may not wish to grant the offeree full control over destination party designation, the offeror may choose to restrict who the offeree may select as a destination party, while still providing the offeree with some level of control. In one embodiment, the offeror may identify a group of one or more eligible parties that the offeree may designate as a destination party. For example, an offeror mother and father may provide to an offeree child, an electronic calling token that does not identify a specific destination party, but instead identifies a group of potential destination party candidates such as family members. When the child activates the token, the child is presented with a list of such destination party candidates from which the child may select the desired destination party. An offeror may identify a group of one or more eligible destination parties by name, however, an offeror may likewise identify a group of one or more eligible destination parties by one or more alphanumeric identifiers such as a PSTN extension.

In addition to an offeror being able to control (i.e. limit) the designation of a destination party, the offeror may likewise control or place conditions on other aspects of a voice communication session to be initiated via the electronic calling token of the present invention. For example, an offeror may stipulate (i.e. via the token) conditions that are required to be met before a communication session may be established between an offeree and a destination party. That is, the electronic call token functions as a conditional offer to participate in one or more voice calls with a designated destination party. For example, an offeror may stipulate the dates and times at which a communication session may be established between an offeree and a destination party, one or more geographic locations within which the destination party may be located, the maximum duration of a communication session to be established, and so forth. In one embodiment, such conditions are encoded within an XML data structure representing the electronic call token (see e.g. Figure 13).

Page 18

CA 02454504 2004-01-20

WO 03/009550

PCT/US02/22980

In one embodiment, services executing locally on an offeree client verify that the stipulated calling conditions specified by an offeror have been satisfied prior to initiating a PSTN based call to the designated destination party. In another embodiment, services executing on a web server verify that the calling conditions specified by an offeror have been satisfied prior to completing a PSTN based call to the designated.

In accordance with one embodiment of the invention, the electronic token is generated based at least in part upon data supplied by the offeror. Figures 9(A-G) are graphical illustrations, each representing various data input dialogs presented to an offeror in association with generation of one or more the tokens according to one embodiment of the present invention. The dialogs may be generated by a web server, such as web server 128, or be generated by a local application executing on a client computer, such as client computer 102. If a web server generates the dialogs, the dialogs may be displayed as part of one or more web pages transmitted to the offeror via the hypertext transfer protocol (HTTP), for example. If the dialogs are generated by a locally executing application, however, the dialogs may appear as one or more windows upon the offeror’s desktop and may be accessible to the offeror through one or more menu selections or buttons upon the offeror’s desktop.

Figure 9A represents one embodiment of a “call-type” data input dialog in which an offeror may select the type of voice call to be placed upon activation of the electronic token by an offeree. According to the illustrated embodiment, an offeror may choose to have the electronic token represent a VolP-to-VolP call, VolP-to-PSTN call, a PSTN-to-VolP call, or a PSTN-toPSTN call. By selecting the VolP-to-VolP call option, for example, the offeror indicates that VoIP based calls should be placed to both the offeree and the destination party, whereas by selecting the VolP-to-PSTN call option, the offeror indicates that a VoIP based call should be placed to the offeree and a PSTN based call should be placed to the destination party. Similarly, the

Page 19

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

PSTN-to-VolP call option places a first PSTN based call to the offeree and a second VoIP based call to the destination party, whereas the PSTN-to-PSTN call option places first and second PSTN based calls to both the offeree and the destination party. In the illustrated embodiment, each of the call selections correspond to a check box, however, radio buttons, image maps and other graphical and text based selection methods known in the art may likewise be used.

Figures 9(B-E) each represent an embodiment of a data input dialog for an offeror to designate an offeree and a destination party to be placed in voice communication with each other. In each of Figures 9(B-E) the offeror is presented with a first drop-down selection list for designating an offeree and a second drop-down selection list for designating a destination party. Although drop-down lists are shown, other data entry techniques known in the art may be utilized. Depending upon the type of call selected (e.g. through the dialog of Figure 9A), the offeror may designate an offeree and a destination party by name, IP address, and/or PSTN extension. For example, in Figure 9B, the offeree is designated by IP address, whereas in Figure 9E, the offeree is designated by a PSTN identifier (i.e. telephone number). Some or all of the designated information, such as destination party name, IP address, and phone number may be retained in and accessed from a private/public address book of the offeror client.

Figure 9F represents one embodiment of a “billing” data input dialog by which an offeror may enter billing-specific data to facilitate payment of a fee to a third party. The offeror may, for example, select to pay for the services provided by the third party by way a credit card, or the offeror may choose to have the fee billed to the offeror’s preexisting account. If the offeror selects to pay using a credit card, the offeror’s ability to pay for such services is verified by an independent credit agency prior to generation of the token or call placement. In one embodiment, the offeror may choose to have the cost of the electronic token generation and/or call placement services billed to the offeree. Conceptually, this may function much like a “1-900” number, wherein

Page 20

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 a caller pays a fee to a service provider in order to receive some phone-based service. In this example, the offeror would function as both the service provider and the destination party. In one embodiment, the token is distributed to the offeree by way of solicited or unsolicited email from an advertising or telemarketing offeror. Upon activating the electronic token, the offeree may be presented with various billing options, such as those illustrated in Figure 9F.

Figure 9G represents one embodiment of a data input dialog by which an offeror may specify call controls to conditionally limit an offer to participate in a voice communication session. As described above with respect to Figure 12, the call token may be generated so as to include numerous conditional statements limiting the performance of the communication session. For example, as illustrated in Figure 9G, an offeror may specify the valid period of time within which a voice communication session may be established with a destination party. Similarly, the offeror may limit the date(s) according to which the voice communication session may be established, and the areas that the offeree may attempt to call. In one embodiment, the call area limitation is only presented to an offeror when a destination party is not designated through e.g. an input dialog such as that illustrated in Figures 9(BE).

As alluded to previously, the electronic token generation and call placement services of the present invention may also be used to provide anonymous voice communication between an offeree and a destination party, wherein neither of the parties to the call have knowledge of the other’s identity. For example, an Internet dating service could provide the electronic token generation service of the present invention. A user of the dating service

I would log into a web server, such as web server 128, and browse through one or more web pages linked to a database to provide the user with various levels of information related to individuals the user may wish to date. Once the user selects one of the potential candidates from the database, web server 128 would generate the electronic token using obfuscated or encrypted

Page 21

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 code in place of each user’s personal contact information, such as PSTN extension or IP number for example. The dating service would then email the generated electronic token to the selected offeree.

Once the offeree receives the electronic token representing an offer to participate in a voice call with the offeror, the offeree may activate the token to be placed in voice communication with the offeror (i.e. as the destination party). In one embodiment, activating the electronic token causes an HTTP post to be transmitted to a remote server, such as web server 128 or bridgeport 162 or 167, which recognizes this as a token activation by the offeree. The remote server then performs a lookup in a database to correlate the contact information with the appropriate PSTN and/or IP connection information. In one embodiment, the remote server (e.g. web server 128) uses this connection information to place the offeree and destination party in voice communication with one another, whereas in another embodiment, remote server forwards this connection information to another server (e.g. bridgeports 162 and 165) to place the offeree and destination party in voice communication with one another. Nevertheless, the identity of the offeree and the offeror/destination party are not revealed to either party.

Figure 10A is a graphical representation illustrating one embodiment of an email application in accordance with the teachings of the present invention. Email application 1000 is shown including window title bar 1002, window menu bar 1004, action buttons 1006, email message 1008, and offer icon 1010. Email application 1000 represents any of the various electronic mail applications known in the art including, but not limited to Outlook, available from Microsoft Corp., and Notes, available from IBM Corp., of Armonk, New York, whereas email message 1008 represents a text-based message generated by email application 1000. Alternatively, email message 1008 may be generated by a web-based email account accessed through a generic web-browser.

Page 22

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

Except for the teachings of the present invention, window title bar 1002, window menu bar 1004, and action buttons 1006 are WINDOWS™ operating system features known in the art. In one embodiment of the invention, email application 1000 includes one or more application specific menu bar entries, and/or one or more application specific action buttons, to facilitate generation of the electronic token. For example, selecting “call-me” menu entry 1012, or activating “call-me” button 1013 may cause one or more data input dialogs, such as those described above with respect to Figures 9 (A-F), to be displayed. Additional ones of action buttons 1006 may provide further functionality with respect to the electronic token generation and call placement services of the present invention. For example, when activated, address button 1014 causes an address book to be displayed on the desktop. In one embodiment, the address book is stored locally on the client computer, whereas in an alternative embodiment, the address book is stored on a remote server, such as web server 128. In one embodiment, address data and contact information displayed in association with action buttons 1006 and/or menu bar 1004 is used in the generation of the electronic token of the present invention.

Email application 1000 also includes email message 1008 and offer icon 1010. Email message 1008 represents an electronic mail message including address information to route email message 1008 to its designated destination as well as message text. Offer icon 1010 is a graphical representation of an offer to participate in a voice call that has been attached to email message 1008 by, for example, an offeror, such as the mother and father of the previous example. In an alternative embodiment, offer icon 1010 is a text-based representation, such as uniform resource locater (URL), rather than a graphical representation.

Figure 10B is a graphical representation illustrating one embodiment of how a received electronic mail message may be displayed in accordance with the teachings of the present invention. Email message 1050 is shown including window title bar 1052 window menu bar 1054, action buttons 1056,

Page 23

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980 message body 1058, and offer icon 1010. Except for the teachings of the present invention, window title bar 1052, and window menu bar 1054 are features of the WINDOWS™ operating system. Action buttons 1056 represent graphical images that are each linked to a generic email feature or function depending upon the specific email application utilized. In one embodiment, action buttons 056 include a button that when selected by a user, cause one or more data input dialogs to be presented, such as those described above with respect to Figures 9(A-F).

Figure 11 illustrates an example computer system suitable for use as one or more of client computers 102, 108 and 116 and/or web server 128. As shown, system 1100 includes one or more processors 1102, such as a PENTIUM™ processor manufactured by Intel Corporation of Santa Clara, California; System memory 1106, including both operating system 1115, such as WINDOWS™ 95, 98 or 2000 with internetworking communication and socket services, and one or more applications 1116; mass storage devices 1107, such as a diskette drive, hard drive, CDROM and so forth; GPIO 1108 for interfacing with I/O devices such as a keyboard and cursor control devices, and for inputting, digitizing and compressing outbound audio, and for decompressing and rendering inbound audio; and communication interfaces 1112, such as MODEMS, network interface cards, and so forth for sending and receiving various data packets (including audio data packets) in accordance with certain standard communication protocols. The elements of system 1100 are coupled to each other via system bus 1114, which may represent multiple buses bridged by one or more bus bridges (not shown). Except for the teachings of the present invention, each of the elements of system 1100 performs its conventional functions known in the art. In particular, system memory 1104 and mass storage 1106 are employed to store a working copy and a permanent copy of the programming instructions implementing the token generation and/or call placement services of the present invention.

Page 24

CA 02454504 2004-01-20

WO 03/009550 PCT/US02/22980

Figure 12 is a flow diagram illustrating a method for establishing a voice communication session between an offeree and a destination party based upon a conditional offer in accordance with one embodiment of the present invention. First, the offeror generates a conditional call token including various call limitations, (block 1202). As described above, such limitations may include but are not limited to identification of a destination party, allowance geographical location(s) for the destination party, when (e.g. time and/or date) an offeree may initiate a voice communication session, and the duration of each voice communication session. Once the token is generated, whether by services executing on the client or on a server, the token is emailed (e.g. via SMTP) to the offeree, (block 1204). Once the offeree activates the call token (block 1206), a determination is made whether at least a subset of the conditions have been satisfied, (block 1208). If the call token is generated by services executing on the client, the client may make such a determination. However, if the call token is generated by services executing on a remote device such as a web server or bridgeport, the respective server may make such a determination, if it is determined that the requisite conditions have not been met, the offeree is notified and the call process ends (block 1210). However, if it is determined that the requisite conditions have been satisfied, an identified one of bridgeports 162 and 165 are then contacted (block 1212). Thereafter, a first voice call is placed by the bridgeport to the offeree (block 1214), a second voice call is placed by the bridgeport to the destination party (block 1216), and the two voice calls are then bridged (block 1218). Thus, the electronic call token of the present invention functions as a virtual calling card that can be personalized through the inclusion of offeree-specific call controls.

In the foregoing specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modification and changes can be made thereto without departing from the broad scope and spirit of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative, rather than restrictive, sense.

Page 25