WO2001072023A1

WO2001072023A1 - System and method for internet service tokens

Info

Publication number: WO2001072023A1
Application number: PCT/US2001/008673
Authority: WO
Inventors: Eric K. Klaussmann, Iii
Original assignee: Direkt Communications Llc
Priority date: 2000-03-17
Filing date: 2001-03-19
Publication date: 2001-09-27
Also published as: AU2001249254A1

Abstract

A system and method (20) for creating, distributing and redeeming service tokens (4000) enables an entity to associate a token (4000) with certain services which may be used by another. A service token (4000) of the present invention comprises both authentication information (4100) and service provision (4200) and is transferable. In one embodiment of the invention, the system and method are directed to facilitating a telephone call between a first and second party.

Description

SYSTEM AND METHOD FOR INTERNET SERVICE TOKENS

RELATED APPLICATIONS

The present application claims priority to U.S. Provisional Application No. 60/189,964 filed March 17, 2000, whose contents are incorporated by reference.

FIELD OF THE INVENTION The present invention is directed to a system and method for creating, distributing and using object-based call tokens for internet-based services.

BACKGROUND OF THE INVENTION

As is known to those skilled in the art, the internet has increasingly been used for communications between computers which operate in a client-server relationship. Over 100 million people and organizations in the US alone carry on a staggering volume of commercial and personal communications, advertising, collaborating, e-chat, e-mail, etc. The internet represents a vast and rapidly emerging market opportunity due to the ability to(l) employ the Internet as the gateway to personalize and manage switched voice calling, and to (2) link and integrate the ubiquitous use of switched voice calling into the Internet communications process. This potential is further extended with the rapid, recent introduction of Wireless Application Protocol (WAP), Internet enabled cellular phone and personal digital assistant (PDA), and Internet access through Cable TV.

FIG. 1 shows a simplified schematic of an overall architecture in which the internet 100 is the centerpiece of a data communications network. In this context, at least one server computer 102 is connected to the internet in a known manner, as is at least one client computer 104.

The server computer 102 illustratively comprises a processor, a disk drive, a memory such as a semiconductor memory, and runs an operating system such as Windows-NT or Linux. The server computer 100 is additionally equipped with a data communications device such as a network card or gateway to connect to the internet 100. In general, the connection to the internet 100 can be established via an Internet Service Provider (ISP) or a direct connection. In a preferred embodiment, the server computer 100 is connected to the Internet 100 via a high-speed connection such as a Digital Subscriber Line connection or a TI connection, or the like, in order to receive and service numerous requests at a high data rate. In addition, the server computer 100 is configured to function as a web server. The web server is typically a general purpose computer such as the server computer running software such as Common Gateway Interface (CGI) programs. The CGI programs provide for communication and interaction between a client computer 104 and the server computer 102 via the Internet 100. These CGI programs, coupled with data communications software programs, are configured to receive packets of messages from computers connected to the internet 100, decipher the information in the packets, and act according to instructions provided in the packets within the constraints imposed by an administrator managing the server computer 102. Commercial suppliers such as Netscape Corporation market web server software. Additionally, such web server software can also be downloaded and configured free of charge from other sources. Persons skilled in the art understand how to write CGI programs in programming languages such as UNIX Shell script, Perl, C, C++, Java and others.

In addition to performing the tasks of receiving and sending packets of data to and from the computers connected to the internet, the CGI programs are configured to perform other tasks such as communicating with a database 106 coupled to the server computer 102, and extract or store information in the database according to the software instructions provided within the server computer 102 or in the packets received from the Internet 100. The server computer 102 is configured to receive request messages from a client computer 104 over the internet in the Hyper Text Transfer Protocol (HTTP), File Transfer Protocol (FTP) or any similar protocol used to transfer data, video, voice or a combination of these media. After analyzing the request messages, the server computer 102 is configured to transmit in response messages that include "web pages" that are programmed in Hyper Text Markup Language (HTML) or a similar language. Embedded in the web pages are components such as documents, scripts, objects, and frames that enable the server computer 102 to display colorful graphical images on a display device coupled to the client computer 104. Persons skilled in the art know how to make web pages using programming languages or tools such as HTML, Cold Fusion, Java, Java Script, Active Server Pages, Dynamic HTML, Extensible Markup Language (XML), etc.

Database 106 stores information using, for example, an Oracle Relational Database Management System. The information stored in such a database may be provided by the entity operating the server. The database, however, can also be used to store information and requests made by the client computer, among others.

The client computer 104 may be connected to the internet either directly, or via an internet service provider, as is known to those skilled in that art. The client computer may also belong to a network, such as a local area network having a gateway connection to the internet. Each client computer 104 illustratively comprises a microprocessor such as a Pentium III microprocessor, a magnetic, optical or other type of disk drive, a memory such as a semiconductor memory, a keyboard or other character input device, a mouse or other pointing device, and a display device such as a CRT or a flat panel display. In addition to operating system software, the client computer 104 also executes a program called a web browser, or simply, a browser. The browser is a computer program that provides access to the vast resources of the Internet. Typically, this is done by providing a "window" to the data located on other computers connected to the Internet. Examples of browser programs available are Netscape Navigator and Microsoft Internet Explorer.

SUMMARY OF THE INVENTION

The present invention is directed to a system and method for creating, distributing and redeeming call tokens.

In one aspect, the present invention is directed to a method of facilitating a telephone call. The method comprising the steps of transmitting, to a receiving party, a first transferrable call token comprising a first address and a first identification number; receiving, from an activating party, a first hypertext transfer protocol (HTTP) request including the first identification number; retrieving first information referenced by the first identification number; making a first call to a first party; making a second call to a second party; and merging the first and second calls.

In this aspect, the method may further comprise the steps of transmitting, to the activating party, a second HTTP request to enter a first telephone number, after the step of retrieving first information; and receiving, from the activating party, the first telephone number. It may also comprise the steps of transmitting, to the activating party, a third HTTP request to enter a second telephone number; and receiving, from the activating party, the second telephone number. It may further comprise the step of updating at least one record associated with said first identification number.

Also, in this method, the first address may comprise a uniform resource locator (URL) and the first identification number is embedded in the first address.

In another aspect, the present invention is directed to a method of initiating a telephone call. The method comprises the steps of receiving a first transferrable call token comprising a first address and a first identification number; transmitting a first hypertext transfer protocol (HTTP) request including said first identification number; and receiving a telephone call.

In this aspect, the method may further comprise the steps of receiving a second HTTP request to enter a first telephone number, after the step of transmitting the first HTTP request; and transmitting the first telephone number. It may also further comprise the steps of eceiving a third HTTP request to enter a second telephone number; and transmitting the second telephone number.

Also, in this method, the first address may comprise a uniform resource locator (URL) and the first identification number is embedded in the first address. In yet another aspect, the present invention is directed to a method of facilitating a service. The method comprises the steps of transmitting, to a receiving party, a first transferrable service token comprising a first address and a first identification number; receiving, from an activating party, a first hypertext transfer protocol (HTTP) request including said first identification number; retrieving first information referenced by said first identification number; and providing service to a party.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention can better be understood through the figures in which:

FIG. 1 presents a simplified schematic of a conventional data communications network including a client-server architecture using the internet;

FIG. 2 shows a schematic of one embodiment of a service provision network in accordance with the present invention;

FIG. 3 shows the major components of the management center (MC) in one embodiment according to the present invention;

FIG. 4a shows the major components of the management token (MT) in one embodiment according to the present invention; FIG. 4b illustrates the concept of one or more management tokens (MT) residing under one MT account;

FIG. 5 is a flow diagram showing the service management and service delivery over the service provision network according to one embodiment of the present invention; FIG. 6 shows the steps in a first preferred embodiment of the registration process of the present invention;

FIG. 7 shows the steps in a second preferred embodiment of the registration process of the present invention;

FIG. 8 shows the steps in a third preferred embodiment of the registration process of the present invention;

FIG. 9 illustrates the underlying procedure when a management token (MT) requests a service.

Figs. 10a- 10c show examples of message flows in accordance with the present invention; Figs. 1 la & 1 lb examples of recipient-controlled outbound calls;

FIG. 12 shows another example of the telephony services in one embodiment of the present invention;

Figs 13a-13c show more examples of the telephony services in one embodiment of the present invention; Figs. 14-18 show pages of a subscriber interface for using an embodiment of the invetion;

FIG. 19 is a flow diagram of the 3-step sequence in configuring the telephony service in one embodiment of the present invention;

Figs. 20-22 show the set-up of telephone number tables in configuring the telephony service in one embodiment of the present invention;

FIG. 23 shows a 'Marketing Account' interface page in accordance with the present invention;

FIG. 24 shows a 'Campaign Records' interface page in accordance with the present invention; FIG. 25 shows a 'Call File Records' interface page in accordance with the present invention;

FIG. 26 shows a 'Cell Center Agent Records' interface page in accordance with the present invention;

FIG. 27 shows a 'Campaign Agent Assignment' interface page in accordance with the present invention;

FIG. 28 shows a 'Campaign Call File Assignment' interface page in accordance with the present invention;

FIG. 29 shows a 'Button Settings' Control interface page in accordance with the present invention;

FIG. 30 shows a first 'Call Control' interface page in accordance with the present invention; FIG. 31 shows a second 'Call Control' interface page in accordance with the present invention;

FIG. 32 shows a third 'Call Control' interface page in accordance with the present invention;

FIG. 33 shows a 'Pre-Recorded Messages' interface page in accordance with the present invention;

FIG. 34 shows an on-line gift certificate distribution network in accordance with the present invention; and

FIG. 35 shows the major steps in creating and distributing an on-line gift certificate in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 2 shows a schematic of one embodiment of a service provision network in accordance with the present invention. As seen in FIG. 2, the service provision network 20 comprises management network ("MN" thereafter) 2000, service network ("SN" thereafter) 5000, at least one management center ("MC" thereafter) 1000, at least one management token ("MT" thereafter) 4000, and at least one device 3000. MC 1000 and device 3000 are connected to MN 2000. MC 1000 is also connected to SN 5000. Preferably, device 3000 is also connected to SN 5000. MT 4000 resides on device 3000. Overall, MC 1000 is operated by a service provider. MT 4000 is associated with services to be provided by MC 1000. A user activates MT 4000 at device 3000 to receive services provided by the service provider at MC 1000. MC 1000 provides services over SN 5000 to users and manages over MN 2000 the services associated with MT 4000.

In a preferred embodiment, the service provision network 20 is a telephony communications network and the services are telephony communications services. In this embodiment, SN 5000 is a network that is capable of providing telephony communications services. In another preferred embodiment, the service provision network 20 is an on-line gift distribution network and the services are the distribution of gift certificates. In this embodiment, SN 5000 is a network connected to department stores where on-line redemption of gift certificates is provided.

MN 2000 is a network over which users and service providers are connected and interact with each other for MC 1000 to manage services associated with MT 4000. In a preferred embodiment, MN 2000 is a wide area network (WAN), such as the Internet. In another preferred embodiment, MN 2000 is a local area network (LAN). In yet another preferred embodiment, MN 2000 is a wireless communication network. In still another preferred embodiment, MN 2000 is a combination of a WAN, a LAN, and a wireless network.

SN 5000 is a network over which services are delivered by MC 1000. In a preferred embodiment, SN 5000 is the same network as MN 2000. For example, MN 2000 is the Internet and SN 5000 is also the Internet. In another preferred embodiment, SN 5000 is a separate network from MN 2000. For example, MN 2000 is the Internet, while SN 5000 is a different network, such as a public switched telephone network (PSTN), an integrated services digital network (ISDN), a fiber distributed data interface (FDDI), a private telephone network (PBX), or a central office exchange service (Centrex).

Device 3000 is a communication device at the user-end. It is a programmable electronic device, such as a personnel computer (PC), a personnel digital assistant (PDA), a wireless network paging device (Pager), or a wireless telephone (Cellular Phone or Wireless Phone). It facilitates the communication between MT 4000 and MC 1000 for the management of the services associated with MT 4000.

MC 1000 is operated by a service provider. It provides services to users. It also manages the services associated with MT 4000. It is comprised in part of a series of digital systems referred to generally as digital computers, digital communications switches, digital voice recording storage and retrieval systems, and other peripheral digital or analog systems, which may accompany such systems as digital storage devices and digital signal processing devices. MC 1000 is also comprised in part of digital operating programs and digital software applications which are stored in the above noted digital systems and digital devices and serve to provide the instructions to and directing the operation of such systems and devices. Such instructions are generally referred to as computer programs or software applications. MC 5 1000 is connected to MN 2000 and SN 5000 through wired or wireless means. It is capable of receiving and transmitting analog and digital signals and information over MN 2000 and SN 5000.

FIG. 3 shows the major components of the MC 1000 in one embodiment according to the present invention. As shown in FIG. 3, MC 1000 comprises management network 0 manager 1010, session manager 1012, service manager 1014, service network manager 1016, billing manager 1020, and database 1018.

Management network manager 1010 supports the connection between MC 1000 and MN 2000. The connection is wired or wireless. Service manager 1014 interacts with users for setting up services. The interaction is enabled by management network manager 1010. The setting up of communication services includes service registration and service modification, which will be disclosed in detail below. Billing manager 1020 manages service pricing, accounting and billing, and reporting. Database 1018 stores information concerning service registration, service types, service instructions, and service limits associated with MT 4000. The service registration, service types, service instructions, and service limits associated with MT 4000 will be disclosed in detail below. Session manager 1012 interacts with users during a service activation. It receives service requests and authenticates each request according to the service registration information in database 1018. Also, when a certain registered service requires further information before the service can be delivered, session manager 1012 interacts with the user for such additional information. The interaction between a user and session manager 1012 is also enabled by management network manager 1010. Service network manager 1016 delivers services. It supports and is connected to SN 5000.

MT 4000 is a graphical object on or connected to the display of device 3000. For example and without limitations, it may be a button on a webpage displayed on a PC. A MT is associated with services. In the embodiment where the service provision network 20 is a telephony communications network, a MT is associated with telephony communications services. In the embodiment where the service provision network 20 is an on-line gift distribution network, a MT is associated with gift certificate distribution services.

As shown in FIG. 4a, a MT is a standalone and assignable "unit of property". It is integrated with a computer application running on device 3000. It contains an Identification Code ("IC" thereafter) 4100 and a digital computer program ("Token Application" thereafter) 4200. A MT is identified by the MT IC 4100 embedded in Token Application 4200 of the MT. Each MT has a unique IC. A MT IC may not be modified. Token Application 4200 functions in accordance with the limitations of the operating system programming logic or applications residing on device 3000. It also functions in accordance with the limitations of the network communications protocols of MN 2000. As shown in FIG. 4b. a copy of the IC of each MT is stored in database 1018 at MC

1000. At database 1018, a MT is stored under a MT account. There can reside more than one MT's in a MT account, with each MT having a unique IC. It is noted that it is the MT that is to be activated to have services delivered by MC 1000. On the other hand, a MT account is to be accessed by the user to manage the services registered at MC 1000. A MT can be registered by a user. A user who registers a MT becomes the owner of the MT. The user is also the owner of the MT account where the registered MT resides. Also, a user can register more than one MTs under a MT account.

In a preferred embodiment, a MT is created by a service provider at MC 1000. A user register a CM and therefore establishes a MT account associated with the register MT. In another preferred embodiment, a user establishes a MT account first. After establishing the MT account, the user creates new MT or registers an existing MT offered by MC 1000.

A MT owner can transfer a registered MT to another user. A user who receives a MT from a MT owner becomes the recipient of the MT. A MT can be activated to request services associated with the MT. The user who activates the MT can be the owner or the recipient of the MT. Upon receiving a service request from a MT, MC 1000 authenticates the MT IC before delivering service.

FIG. 5 is a flow diagram showing the service management and service delivery over the service provision network 20. As illustrated in FIG. 5, at step 1300, a service provider creates a MT at MC 1000. The MT can be pre-designed and/or imported. At step 1302, a user registers the MT and becomes the owner of the MT. He can download the MT from MC 1000. He can also leave the MT at MC 1000 for later access. He also gets an account with an access code ("AC", thereafter), such as a username and a password, associated with the MT account. In addition, the owner defines services to be associated with the MT. The services include service type, service instruction, and service limits and will be discussed further below.

Step 1304 is optional. In this step, the MT owner digitally transfers the MT to a recipient. The transfer may be in the form of a replication, a downloading, or an exchange and may be carried out between electronic devices either via physical digital storage medium or over an analog or digital network. For example and without limitation, the MT owner may send the MT to the recipient via e-mail.

The transfer of the MT does not alter the MT. It does not change the Token Application, the IC, or the services the MT owner defined at step 1302. After the transfer, the MT owner remains liable for any obligations agreed to between the MT owner and the service provider at MC 1000 defined at the registration in step 1302. It is noted that changes to the services associated with a MT is made without changing the MT as a property unit. Furthermore, changes to the services only affect the MT with which the services are associated.

Step 1306 is also optional. In this step, the MT owner modifies the services associated with a registered MT. The MT owner does so by accessing the MT account with the MT AC. Especially, the MT owner can do so after a registered MT has been transferred to a recipient. This way, the MT owner still remains in control of the transferred MT. Also, the services associated with a registered MT can be automatically modified or terminated by the service provider alone at MC 1000, according to the service instructions or at the occurrence of certain events, such as the failure on the owner's part to pay for the services.

At step 1308, a user activates the MT on device 3000. The user may be the owner or a recipient. In this step, the MT sends a service request to MC 1000 for the services associated with the MT. A MT is activated in different ways, including a keyboard input, a pointer click, a screen touch, and a voice input, provided by device 3000.

At step 1312, MC 1000 authenticates the MT. In a preferred embodiment, MC 1000 does so by examining the MT IC against the information stored in database 1018. MC 1000 ignores the service request or sends a denial message to the display of device 3000, if the authentication fails. Otherwise, if the authentication is successful, MC 1000 delivers the requested services automatically at step 1316 or requests more information at step 1314 before delivering service. It is noted that, although a MT is associated with a set of services, the MT places an IC to be authenticated by MC 1000 before any service is rendered. For example and without limitation, when taking the form of a button on a webpage, a MT does not merely pass a request for services. Rather, the activation of a MT passes an IC. MC 1000 confirms the ownership of a set of services associated with the MT IC before delivering service.

Step 1314 is optional. It is necessary only when MC 1000 needs to request more information before service can be delivered. Such a need arises from the service instructions, which will be discussed further below.

At step 1316, MC 1000 automatically delivers the services associated with the MT in accordance with the service type, service instruction, and service limits defined in step 1302. Thereafter, at step 1318, MC 1000 updates the information stored at database 1018 for bookkeeping and generating billing and reporting statements.

After step 1318, the process can loop back to step 1308 and a user can activate the MT again, if the MT is well maintained according to the defined services. Also, the process can loop back to step 1304 or step 1306 where the owner can transfer the MT or modify the services associated with the MT, respectively.

The registration of a MT, as in step 1302 of FIG. 5, concerns the state of a MT. Generally, a MT is maintained in one of two states: (1) registered (On) or (2) unregistered (Off). The default setting of each MT is unregistered. The state of each MT is set, controlled, and recorded at MC 1000. MC 1000 delivers services requested by a MT only if the MT has been set to the registered state.

A MT may be registered or set to the On state in various methods. FIG. 6 shows the steps in a first preferred embodiment of the registration process of the present invention. As shown in FIG. 6, at step 1402, a user accesses a MT at a display, such as the website of MC 1000, on device 3000. At step 1404, the user initiates a Registration Sub Program ("RSP" thereafter). The RSP is a program residing within the Token Application of a MT. At step 1406, the RSP displays a Registration Form ("RF" thereafter) on device 3000. The RF is preferably in the form of a credit application authorizing the service provider to debit the designated credit card or other financial account for the provided services. At step 1408. the user fills in the RF. Following the completion of the RF, the Token Application, at step 1410, initiates a communications session between device 3000 and MC 1000. At step 1412, the data provided in the RF are transmitted to and processed at MC 1000. At step 1414, MC 1000 will either approve or deny the user's registration request. Finally, at step 1416, a notice will be transmitted from MC 1000 to device 3000 which will display or announce such approval or denial.

In the steps in a second preferred embodiment of the registration process of the present invention, as shown in FIG. 7, a user accesses a MT at step 1420. The user initiates a communication session with MC 1000 at step 1422. At step 1424, MC 1000 transmits a RF to device 3000. At step 1426, the user fills in the RF and submits it from device 2000 to MC 1000. At step 1428, the data provided in the RF are processed at MC 1000. At step 1432, MC 1000 will either approve or deny the user's registration request. Finally, at step 1434, a notice will be transmitted from MC 1000 to device 3000 which will display or announce such approval or denial.

In the steps in a third preferred embodiment of the registration process of the present invention, as shown in FIG. 8, a user accesses a MT at step 1440. At step 1442, the user initiates a Call Back Sub Program ("CBSP" thereafter) in the Token Application of a MT. At step 1444, the CBSP requests the user to provide a valid telephone number where the user can be contacted either immediately or at a specified time. At step 1446, the Token Application initiates a communications session with MC 1000. At step 1448, MC 1000 initiates a voice call to the valid telephone number provided by the user. An agent of the service provider requests all data required of the RF. This call may be in the form of an automated voice response system ("VRU" thereafter) triggered by the CBSP. At step 1448, the data provided in the RF are processed at MC 1000. At step 1452, MC 1000 will either approve or deny the user's registration request. Finally, at step 1454, a notice will be transmitted from MC 1000 to device 3000 which will display or announce such approval or denial.

In the steps in a fourth preferred embodiment of the registration process of the present invention, a user places a voice call (toll free or otherwise) to an agent of the service provider. The agent requests all data required of the RF for a MT. The agent preferably make the requests in the form of a VRU responding to the user's call. The data provided for the RF are processed at MC 1000. MC 1000 will either approve or deny the user's registration request. Finally, a notice will be transmitted from MC 1000 to device 3000 which will display or announce such approval or denial.

The registration may also be carried out, as is obvious to one skilled in the art, by a combination of voice commands given by users either via the Token Application, as noted above in the steps of the first and second preferred embodiments of the registration process, an automated VRU triggered by a CBSP, as noted above in the steps of the third embodiment of the registration process, and an automated VRU responding to a direct voice call from the user, as noted above in the steps of the fourth preferred embodiment of the registration process.

After a user's application has been approved, MC 1000 establishes a MT account for the user and records the information on database 1018. As a final step in the registration process, MC 1000 notifies the user of the establishment of the account and issues an account AC (access code) to the user. The manner of issuance of the account AC is preferably dependent on the registration method employed by the user. After a successful registration, the user becomes the owner of the MT account and can access the account in a manner described above in the registration process.

The modification of the services associated with a MT, as in step 1306 of FIG. 5, is enabled by the establishment of the MT account. A MT account owner can access the MT account to select, modify or terminate the services associated with a MT registered in the account. The owner can also access the MT account to unregister a previously registered MT. A MT can be unregistered or set to the OFF state in various manners. In a first of such manners, the owner of a MT account initiates a communication session with MC 1000 from device 3000 to gain access to the account stored and maintained on database 1018. For example, the owner can initiate an internet communications session from a PC with an

Internet Browser with an Internet server of the service manager 1014 at MC 1000. The owner then enters the account AC, through physical input or voice command. The service manager 1014, upon authenticating the AC, provides access to the MT database 1018 and the MT account therein. The owner is then allowed to set a MT in the MT account to unregistered state. Upon such setting of the MT as unregistered, the services associated with the MT ceases to be available.

Alternatively, in a second manner, an owner of a MT account carries out the setting of a MT in the account to an unregistered state by making a voice call to an agent of the service provider or to the VRU of the service provider, followed by the same authentication and resetting sequence described in the first manner above. Still alternatively, in a third manner, the service provider sets a MT in a MT account to unregistered state directly at MC 1000, in accordance to the service instructions defined by the owner. When a user activates a MT, as in step 1308 of FIG. 5, the MT sends a service request to MC 1000. There are preferably three steps, as shown in FIG. 9. At step 1202, the MT locates the Universal Resource Locator ("URL") of MC 1000. At step 1204, the MT passes its IC to the MC URL. At step 1206, the MT passes its own URL to the MC URL. Thereafter, the MT waits for MC 1000 to authenticate.

The services associated with a MT in a MT account are defined by the owner of the account at the registration, as in step 1302 of FIG. 5, or modified at a time after the registration, as in step 1306 of FIG. 5, so long as the MT account remains registered.

In a preferred embodiment of the present invention, the services include computer integrated telephony service, which is provided by MC 1000 on behalf of the MT. In providing such services, MC 1000 initiates one or more outbound calls over SN 5000. These calls may be (1) data calls, (2) analog voice calls, or (3) digitized voice packet or voice over Internet protocol ("VOL?" thereafter) calls ("Call" or "Calls" thereafter). Also, MC 1000 receives one or more inbound Calls over SN 5000. In addition, MC 1000 both initiates outbound Calls and receives inbound Calls over SN 5000.

In the telephony services associated with a MT, all Calls are associated with a number or address which defines the origin or destination of a Call. For example, the number or address may be a telephone number or an internet address, respectively. A Called Number is a number or address that MC 1000 will initiate an outbound Call to. A Calling Number is a number or address from which MC 1000 receives an inbound Call.

The telephony services associated with a MT preferably also include functionality provided by MC 1000, which acts to connect, forward, store, transfer, or otherwise manage inbound Calls and outbound Calls ("Call Management") and forward, store, transfer, or otherwise manage analog stream, digital data, or information ("Call Content") that may be transmitted over SN 5000.

The telephony services are executed and recorded on an Call-by-Call ("Individual Call") basis. They are also modifiable and chargeable on an Call-by-Call basis. An individual Call may incorporate the execution of one or more services which can be executed simultaneously or sequentially. Also, the execution of one or more services during an individual Call can be continuous or the execution of each service can be conditioned on certain specified events or states. Also, an individual Call initiated by a MT or automatically executed by MC 1000 can be limited to a single instance or can be set to allow repetitive sequential instances.

Table 1 contains a list of telephony services associated with a MT, including the categories of owner controlled Calls and recipient controlled Calls, each category further including the subcategories of Automated Outbound Calls, Semi- Automated Outbound, Non-Automated Outbound Calls, Automated Inbound/Outbound Calls, and Semi- Automated Inbound/Outbound Calls.

Table 1 : Services included in a MT.

Owner Controlled Automated Outbound Calls are calls associated with Automated Called Numbers of a MT. The Automated Called Numbers are defined by the owner of the MT account, before the activation of the MT, as one or more telephone numbers and/or one or more Internet addresses to which MC 1000 will initiate a call upon the activation of the MT by a user. The owner defines one or more Automated Called Numbers and MC 1000 will call them simultaneously or sequentially. If they are called sequentially, they will be called in an order designated by the owner in the MT account. FIG. 10a shows an example of Owner Controlled Automated Outbound Calls. The telephony service in this example concerns the making of an outbound phone call by the MT owner. In this figure, and also in the following figures, an arrow indicates a process, preferably a communication process. The direction of the arrow indicates the direction of the communication. The numeral numbers associated with the arrows indicate the order of sequence in which the processes occur.

As shown in FIG. 10a, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, MN 2000 is the Internet, SN 5000 is PSTN, and the service associated with the MT is to make a phone call from the user's computer phone on device 3000 over SN 5000 to a called party 6000. To construct this service, the user provides the phone number of his computer phone and the phone number of the called party to MC 1000 at the registration. In process 2, the user, as the owner of the registered MT, activates the MT. The activation is from device 3000 and the MT locates MC 1000 over MN 2000. After proper authentication, in process 3, MC 1000 automatically makes a call to the user's computer phone, according to the computer phone number provided by the user at the registration. This call is made over SN 5000. At the same time, in process 4, MC 1000 automatically makes a call to the called party, according the phone number of the called party, also provided by the user at the registration. This call is also made over SN 5000. Thereafter, in process 5, MC 1000 merges the 2 calls, completing the service.

Owner Controlled Semi-Automated Outbound Calls, like Owner Controlled Automated Outbound Calls discussed above, are also calls associated with Automated Called Numbers defined by the owner of a MT. Here, however, MC 1000 will first request, upon the activation of the MT by a user, the input (keyed or voice) of one or more telephone numbers ("Input Called Numbers") from the user through a display on device 3000 or by an automated voice message (analog or digital). Thereafter, MC 1000 will initiate a call to the Automated Called Numbers and all Input Call Numbers either simultaneously or sequentially in the order designated by the owner of the Account.

FIG. 10b shows an example of Owner Controlled Semi-Automated Outbound Calls. The telephony service in this example also concerns the making of an outbound phone call by the MT owner. As shown in FIG. 10b, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, MN 2000 is the Internet, SN 5000 is PSTN, and the service associated with the MT is to make a phone call from the user's computer phone on device 3000 over SN 5000 to a called party 6000. To construct this service, the user provides the phone number of his computer phone to MC 1000 at the registration. However, the user does not provide the phone number of the called party to MC 1000 at the registration. This gives the user the flexibility to decide what number to call at the activation of the MT. In process 2, the user, as the owner of the registered MT, activates the MT. The activation is from device 3000 and the MT locates MC 1000 over MN 2000. After proper authentication, in process 3, MC 1000 transmits a display at device 3000 and requests the user to provide the phone number of the called party. In process 4, the user keys in the phone number of the called party. Thereafter, at process 5, MC 1000 makes a call to the user's computer phone, according to the computer phone number provided by the user at the registration. This call is made over SN 5000. At the same time, in process 6, MC 1000 makes a call to the called party, according the phone number of the called party keyed in by the user at the display. This call is also made over SN 5000. Thereafter, in process 7, MC 1000 merges the 2 calls, completing the service.

Owner Controlled Non- Automated Outbound Calls are calls associated with no Automated Call Numbers. The activation of a MT by a user will initiate a communication session with MC 1000 which will request, through a display on device 3000 or by an automated voice message (analog or digital), the input (keyed or voice) of two or more Input Called Numbers. MC 1000 will then initiate a call to the Input Call Numbers either simultaneously or sequentially in the order designated by the owner of the MT account.

FIG. 10c shows an example of Owner Controlled Non- Automated Outbound Calls. The telephony service in this example also concerns the making of an outbound phone call by the MT owner. As shown in FIG. 10c, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, MN 2000 is the Internet, SN 5000 is PSTN, and the service associated with the MT is to make a phone call from the user's computer phone on device 3000 over SN 5000 to a called party 6000. To construct this service, the user provides no phone numbers to MC 1000 at the registration. That is, the user provides either the phone number of his computer phone nor the phone number of the called party to MC 1000 at the registration. This gives the user the flexibility to decide where to call from and what number to call at the activation of the MT. In process 2, the user, as the owner of the registered MT, activates the MT. The activation is from device 3000 and the MT locates MC 1000 over MN 2000. After proper authentication, in process 3, MC 1000 transmits a display at device 3000 and requests the user to provide the phone number where the user can be reached. In process 4, the user keys in the phone number where he can be reached. In process 5, MC 1000 transmits another display at device 3000 and requests the user to provide the phone number of the called party. In process 6, the user keys in the phone number of the called party. Thereafter, at process 7, MC 1000 makes a call to the user's computer phone keyed in by the user at the first display. This call is made over SN 5000. At the same time, in process 8, MC 1000 makes a call to the called party according the phone number of the called party keyed in by the user at the second display. This call is also made over SN 5000. Thereafter, in process 9, MC 1000 merges the 2 calls, completing the service. It is noted that, in FIG. 10c, the pair of processes 3 and 4 can be processed after the pair of processes 5 and 6. That is, MC 1000 can first request for the phone number of the called party, before it secondly requests for the phone number of the user. Also, these two pairs can be processes together or combined. That is, MC 1000 can request for the phone number of the called party and the phone number of the user at the same time and in the same display. It is also noted that, after process 1 and before process 2, the owner can access the MT account and modify the service associated with the MT.

Recipient Controlled Automated Outbound Calls, like Owner Controlled Automated Outbound Calls, are also calls associated with Automated Called Numbers of a MT. However, the Automated Called Numbers are defined by a recipient, to whom the owner has granted the right to input Automated Called Numbers. At a first activation of the MT by the recipient, MC 1000 will request the recipient to input the Automated Called Numbers. Thereafter, subsequent activation of the MT will cause MC 1000 to initiate a call to the Automated Called Numbers either simultaneously or sequentially in the order designated by the recipient.

FIG. 11a shows an example of Recipient Controlled Automated Outbound Calls. As shown in FIG. 1 la, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, both MN 2000 and SN 5000 are the Internet and the service associated with the MT is to make a phone call over the Internet from anyone and to anyone. To construct this service, the user provides no phone number to MC 1000 at the registration. In process 2, the user, as the owner of the registered MT, transfers the MT to recipient 6000 by attaching the MT in an email to recipient 6000 via the Internet. After the transfer, the MT is moved to and in the possession of recipient 6000. In process 3, recipient 6000 initiates the MT and provides to MC 1000 his computer phone number and the phone number of a called party. In process 4, recipient 6000 activates the MT. The activation is from a device 3000 at the site of recipient 6000 and the MT locates MC 1000 over the Internet. After proper authentication, in process 5, MC 1000 makes a call to the recipient's computer phone, according the computer phone number provided by the recipient at the initiation. At the same time, in process 6, MC 1000 makes a call to the called party's computer phone, according the called party's phone number, also provided by the recipient at the initiation. Thereafter, in process 7, MC 1000 merges the 2 calls, completing the service.

Recipient Controlled Semi- Automated Outbound Calls, like Recipient Controlled Automated Outbound Calls, are also calls associated with Automated Called Numbers of a MT defined by a recipient, authorized by the MT owner, at a first activation of the MT. Here, however, further activation of the MT by a user will initiate a communication session with MC 1000 which will request, through a display on device 3000 or by an automated voice message (analog or digital), the input (keyed or voice) of two or more Input Called Numbers from the user. MC 1000 will then initiate a call to the Input Call Numbers either simultaneously or sequentially in the order designated by the recipient.

Recipient Controlled Non- Automated Outbound Calls are calls associated with no Automated Call Numbers. The activation of the MT by an authorized recipient will initiate a communication session with MC 1000 which will request from the recipient, through a display on device 3000 or by an automated voice message (analog or digital), the input (keyed or voice) two or more Input Called Numbers. MC 1000 will then initiate a call to the Input Call Numbers either simultaneously or sequentially in the order designated by the recipient. FIG. 1 lb shows an example of Recipient Controlled Non-Automated Outbound Calls. As shown in FIG. 1 lb, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, both MN 2000 and SN 5000 are the Internet and the service associated with the MT is to make a phone call over the Internet from anyone and to anyone. To construct this service, the user provides no phone number to MC 1000 at the registration. In process 2, the user, as the owner of the registered MT, transfers the MT to recipient 6000 by attaching the MT in an email to recipient 6000 via the Internet. After the transfer, the MT is moved to and in the possession of recipient 6000. In process 3, recipient 6000 activates the MT. The activation is from a device 3000 at the site of recipient 6000 and the MT locates MC 1000 over the Internet. After proper authentication, in process 4, MC 1000 transmits a display at the recipient's device, requesting a phone number where the recipient can be reached. In process 5, the recipient keys in his computer phone number. In process 6, MC 1000 transmits another display at the recipient's device, requesting the phone number to which the recipient wishes the call to be directed. In process 7, the recipient keys in the phone number of the computer phone of a called party 8000. In process 8, MC 1000 makes a call to the recipient's computer phone, according the computer phone number keyed in by the recipient. At the same time, in process 9, MC 1000 makes a call to the called party's computer phone, according the called party's computer phone number, also keyed in by the recipient. Thereafter, in process 10, MC 1000 merges the 2 calls, completing the service. It is noted that, in FIG. 12, the pair of processes 4 and 5 can be processed after the pair of processes 6 and 7. That is, MC 1000 can first request for the phone number to which the recipient wishes the call to be directed, before it secondly requests for the phone number of the recipient. Also, these two pairs can be processes together or combined. That is, MC 1000 can request for the phone number to which the recipient wishes the call to be directed and the phone number of the recipient at the same time and in the same display.

It is also noted that, after process 2 and before process 3, the owner can access the MT account and modify the service associated with the MT. For example, the owner can modify the service so that the MT can make calls only to a limited number of phone numbers. Owner Controlled Automated Inbound/Outbound Calls are calls associated with

Automated Calling Numbers and Automated Calling Numbers of a MT. The Automated Calling Numbers are defined by the MT owner as one or more telephone numbers and/or Internet addresses from which MC 1000 receives an inbound call. An inbound call will either be connected immediately or recorded in the way designated by the owner. FIG. 12 shows an example of Owner Controlled Automated Inbound/Outbound Calls.

As shown in FIG. 12, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, both MN 2000 and SN 5000 are the Internet and the service associated with the MT is to receive, at the user's computer phone on device 3000 and over the Internet, phone calls from one or more designated phone numbers or web addresses. To construct this service, the user provides the phone number of his computer phone and the designated calling phone numbers to MC 1000 at the registration. In process 2, a calling party 9000 initiates a call from a designated number to the user's computer phone. In process 3, MC 1000 makes a call to the calling party's phone number. At the same time and after proper authentication, in process 4, MC 1000 makes a call to the user's computer phone, according the user's computer phone number provided by the user at the registration. Thereafter, in process 5, MC 1000 merges the 2 calls, completing the service.

Owner Controlled Semi -Automated Inbound/Outbound Calls, like Owner Controlled Automated Inbound/Outbound Calls, are also calls associated with Automated Calling Numbers and Automated Calling Numbers of a MT. Here, upon the receipt of a call from an Automated Calling Number, MC 1000 will initiate a communication with the MT. MC 1000 will request, through a display on device 3000 or by an automated voice message (analog or digital), the input (keyed or voice) of one or more Input Called Numbers from the user of the MT. MC 1000 may (1) initiate a call to the Input Call Numbers immediately, thus connecting the Automated Calling Number with the party or service at the Input Called Numbers, or (2) store the Call Content of the inbound call, initiate a call at a later time to the Input Called Numbers subject to the response of the MT, and transfer the stored Call Content received from the Automated Calling Number to the Input Called Numbers.

Recipient Controlled Automated Inbound/Outbound Calls, like Owner Controlled Automated Inbound/Outbound Calls, are also calls associated with Automated Calling Numbers and Automated Calling Numbers of a MT. Here, however, the MT owner permits a recipient to activate the MT and to provide Automated Calling Numbers and Automated Called Numbers. An Inbound Call will be received from an Automated Calling Number and either be connected immediately to the Automated Called Numbers or stored for later transfer or retrieval.

Recipient Controlled Semi- Automated Inbound/Outbound Calls, like Recipient Controlled Automated Inbound/Outbound Calls, are also calls associated with Automated Calling Numbers and Automated Calling Numbers of a MT. Here, however, upon the receipt of a call from an Automated Calling Number, MC 1000 will initiate a communication with the MT. MC 1000 will request, through a display on device 3000 or by an automated voice message (analog or digital), the input (keyed or voice) of one or more Input Called Numbers from the user of the MT. Subsequently, the inbound Call will be either be connected immediately to the Input Called Numbers or stored for later transfer or retrieval.

In addition to the services listed in Table 1 , the telephony services can also be provided in other forms. For example, in the service of Recipient Controlled Automated Outbound Calls, discussed above in connection with Table 1 and FIG. 11a, the right for the recipient to initiate the MT can be omitted by the owner. That is, the owner can limit the services associated with the MT by designating the recipient's computer phone number as the number where calls are made from and the phone number of a called party as the number where calls are directed to. The owner also sets the MT in a way in which the recipient can not change the designation. In doing so, the owner defines the services in a way that the recipient can only use the MT to call from the recipient's computer phone number to the designated called party.

FIG. 13a shows such an example. As shown in FIG. 13a, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, both MN 2000 and SN 5000 are the Internet and the service associated with the MT is to make a phone call over the Internet from a designated recipient's computer phone number to the designated called party. To construct this service, the user provides the recipient's computer phone number and the phone number of a called party to MC 1000 at the registration. In process 2, the user, as the owner of the registered MT, transfers the MT to the recipient by attaching the MT in an email to recipient 6000 via the Internet. After the transfer, the MT is moved to and in the possession of recipient 6000. In process 3, the recipient activates the MT. The activation is from a device 3000 at the site of recipient 6000 and the MT locates MC 1000 over the Internet. After proper authentication, in process 4, MC 1000 makes a call to the recipient's computer phone, according the computer phone number provided by the owner at registration. At the same time, in process 5, MC 1000 makes a call to the called party's computer phone, according the called party's phone number, also provided by the owner at registration. Thereafter, in process 6, MC 1000 merges the 2 calls, completing the service.

FIG. 13b shows another example of the telephony service associated with a MT. This service concerns the transfer of the MT. As shown in FIG. 13b, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, both MN 2000 and SN 5000 are the Internet and the service associated with the MT is to make a phone call over the Internet from anyone to the user's computer phone on device 3000. To construct this service, the user provides the phone number of his computer phone to MC 1000 at the registration. In process 2, the user, as the owner of the registered MT, transfers the MT to recipient 6000, preferably by attaching the MT in an email to recipient 6000 via the Internet. After the transfer, the MT is moved to and in the possession of recipient 6000. In process 3, recipient 6000 activates the MT. The activation is from a device 3000 at the site of recipient 6000 and the MT locates MC 1000 over the Internet. After proper authentication, in process 4, MC 1000 transmits a display at the recipient's device, requesting a phone number where the recipient can be reached. In process 5, the recipient keys in his computer phone number. In process 6, MC 1000 makes a call to the recipient's computer phone, according the computer phone number keyed in by the recipient. At the same time, in process 7, MC 1000 makes a call to the owner's computer phone, according the owner's computer phone number provided by the owner at the registration. Thereafter, in process 8, MC 1000 merges the 2 calls, completing the service.

FIG. 13c shows yet another example of the service associated a MT. This service concerns the receiving of an inbound phone call. As shown in FIG. 13c, in process 1, a user at device 3000 registers a MT with MC 1000 over MN 2000. In this example, MN 2000 is the Internet, SN 5000 is PSTN, and the service associated with the MT is for the user's computer phone on device 3000 to receive a phone call over SN 5000 from a calling party 9000. To 5 construct this service, the user provides the phone number of his computer phone to MC 1000 at the registration. In process 2, the user, as the owner of the registered MT, activates the MT. The activation is from device 3000 and the MT locates MC 1000 over MN 2000. After proper authentication, in process 3, MC 1000 transmits a display at device 3000 for the email address of a calling party. In processs 4, the user keys in the email address of calling party

10 9000. In process 5, MC 1000 notifies calling party 9000 via an email, an instant messenger, or an alert and requests a phone number. In process 6, the calling party keys in a phone number where he can be reached. This is done at a device 3000 at the site of the calling party. In process 7, MC 1000 makes a call to the calling party according to the phone number keyed in by the calling party. At the same time, in process 8, MC 1000 makes a call to the owner

15 according to the computer phone number provided by the owner at the registration. Thereafter, in process 9, MC 1000 merges the 2 calls, completing the service.

It is noted that, in FIG. 13c, processes 3 and 4 can be omitted if the owner provides the email address of the calling to MC 1000 at the registration. This way, MC 1000 can skip from process 2 to process 5, directly notifying the calling party at the activation of the MT.

20 FIGs. 14-18 show an example of the interfacing for the service related to receiving an inbound call, illustrated above in connection with FIG. 13c. This example is from the service provider of Direct Connect, which is a MC embodied according the present invention. In Direct Connect, a MT is also called a "button".

FIG. 14 shows a login page. This page comprises trade name 2010 and authentication

25 2012. Trade name 2010 indicates the trade name of the service provider, which is "Direct Connect". Authentication 2012 further comprises loginname 2016, password 2018, and login 2014. A user obtains an MT account AC (username and password) at the registration. Thereafter, he can access the MT account by entering the username in the field of loginname 2016, entering the password in the field of password 2018, and clicking login 2014.

30 FIG. 15 is an account page displaying the status of the MTs associated with the services of receiving inbound calls. This page comprises trade name 2020, welcome 2022, create new button 2024, and current buttons 2032. Welcome 2022 displays a welcome sign to the user. In this example, the user's username is Igor Ulis.

Create new button 2024 comprises button name 2026, telephone 2028, and add 2030. A user can create a new MT associated with services of receiving inbound calls by naming the new MT in the field of button name 2026, keying the phone number that receives inbound calls in the field of telephone 2028, and clicking add 2030.

Current buttons 2032 shows the status of the MTs associated with the services of receiving inbound calls. It contains summary 2034, status menu 2036, button name list 2038, phone number list 2040, status list 2042, delete button 2044, and mail button 2046. Summary 2034 provides a summary concerning the status of the MTs. In the example shown in FIG. 15, it shows that the maximum number of MTs allowed is 5 and 2 have been used. Status menu 2036 provides the titles for button name list 2038, phone number list 2040, and status list 2040. Button name list 2038 lists the names of the current MTs. Phone number list 2040 lists the phone numbers, each being associated with a MT, where the user wishes to receive inbound calls. Status list 2042 lists whether a MT is active or is set at the "On" state. In the example shown in FIG. 15, the two current MTs are named "direkt" and "new button", respectively, and associated with the phone numbers "212-751-4114" and "212-983-8372", respectively. These two MTs are both active. Delete button 2044, if clicked, deletes the MT associated with the delete button. Mail button 2046, if clicked, will initiate the process of sending an email to a recipient and asking the recipient to make an inbound call to the user. That is, clicking mail button 2046 corresponds to process 2 of FIG. 13.

FIG. 16 shows a display in connection with the sending of an email caused by clicking the mail button 2046 of FIG. 15. It corresponds to processes 3 and 4 of FIG. 13. This display comprises trade name 2050, report 2052, mail button 2060, and back 2058. Mail button 2060 comprises MT info 2062, address 2054, and send mail 2056. MT info 2062 indicates the name and the associated phone number of the MT to be sent. In the example shown in FIG. 16, the name of the MT is "direct" and the associated phone number is 212-751-4114. In order to complete the email, the user needs to enter the email address of a calling party in the field of address 2054 and click send mail 2056. Report 2052 shows the result of the emailing. In the example shown in FIG. 16, report 2052 indicates that the email is sent. Back 2058, if clicked, will send the user back to the account page shown in FIG. 15. FIG. 17 shows an email sent to the calling party, notifying the arrival of a button, inviting the calling party to call the user. This corresponds to process 5 of FIG. 13. The email header 2102 contains a from info 2104, which indicates where the email is from, a to info 2106, which indicates where the email is directed, a date info 2108, which indicates the date and time when the email is sent, and a subject info 2112, which indicates the content of the email. The email body 2114 contains a message 21 16, which notifies the invitation to make a call, and link 21 18, which, if clicked, will initiate the call.

FIG. 18 is a display caused by clicking link 2118 of FIG. 17. Phone number 2202 comprises telephone 2204 and respond 2206. The calling party needs to enter the phone number where he wishes to talk to the user and click respond 2206. This corresponds to process 6 of FIG. 13. Status 2208 shows the status of the call. In the example shown in FIG. 18, a telephone number has been filled in the field of phone number 2202, respond 2206 has been clicked, and dialing has started, as indicated by status 2208.

The telephony services associated with a MT, as shown in Table 2, also include services such as Return Dropped Call, Schedule Call, Reschedule Call, Keep Trying Call, Voice Messaging, Text Messaging, Text to Voice, and Voice to Text.

Table 2: More services included in a MT.

The telephony services associated with a MT also include Defined Service Limits ("DSL" thereafter). DSL are limits which may restrict or prevent the MT from performing certain assigned services. A MT owner or an authorized recipient may define such limits either immediately following registration of a MT or at any time thereafter so long as the MT remains registered. Consequently, MC 1000 will establish the limits and, during any communication session, monitor and determine that the services are and remain within the limits. Failure of a MT to remain within the DSL may cause MC 1000 to deny and/or terminate one or all services assigned to the MT. Such denial and/or termination may be applied on an individual call basis or a global call basis subject to the DSL assigned to the MT.

The limits include, as shown in Table 3, categories such as Number of Calls, Duration of Calls, Cost of Individual Calls (Individual Call Limit), Accumulated Cost of Calls (Accumulated Global Call Limit), Called & Calling Number Restriction, Called & Calling Region Restriction, and Date & Time Restriction.

Table 3: List of DSL.

In Direct Connect, which is the MC 1000 of an embodiment according to the prevent invention, different tailored services are offered to different specific user groups. Also, in this embodiment, a MT is a button.

In Direct Connect, a user account, after a successful registration, can be configured in a 3-step sequence, as shown in FIG. 19. At step 1212, the user selects one of three Call Buttons as the basis for a particular service. The three Call Buttons are an Outbound Call Button, an inbound Call Button, and an Anywhere Call Button. After the selection of one of the three Call Buttons, the user associates the selected button with selected services and limits. The Outbound Call Buttons will place a call to telephone numbers and/or internet addresses listed by the user. The Inbound Call Buttons will receives a call from another party. The user provides the telephone number where he can be called and the name and_' or Website/e-mail address of the parties from whom the user wishes be called. The Anywhere Call Buttons allows the user, as the button owner, to transfer the button to a recipient who is then permitted to call anywhere he or she wishes. The owner provides the name and/or Website/e-mail address of the recipient.

At step 1214, the user enters the name, telephone number and/or Website/e-mail addresses to be assigned to the selected button. If an Outbound Call Button is selected, two tables must be created, as shown in the example of FIG. 20. The first table is for the button owner's telephone numbers and the second is for the telephone numbers of the parties being called. If an Inbound Call Button is selected, similarly, two tables must be created as shown in the example of FIG. 21. The first table is for the button owner's telephone numbers and the second is for the Website/e-mail addresses of the parties calling the button owner. Only one table need be filed in for the Anywhere Call Button as shown in the example of FIG. 22. This table holds the name and/or Web site/e-mail address of the Anywhere Button recipient.

At step 1216, the user sets Call Controls to be assigned to each or a group of selected buttons. There are a wide variety of options including restricting country codes, area codes, length of call, number of calls, dollar amount of a call or cost of all calls. There are specific settings restricting the time or date when calls can be made or received. These restrictions can be set by time zone and range of dates and date. There are procedures for managing busy signals, no answers or answering machines. Voice and e-mail messages can be entered directly or imported and attached set to be triggered by a selected event or other restriction. There are options for Voice Mail. Call Forward, Call Screening and Internet Call Waiting. In Direct Connect, the different tailored services include a marketing account, a company account, a professional/small business account, and a personal account. As shown in Table 4, these accounts are for different specific user groups.

Table 4: List of tailored services

As shown in Table 4, a marketing account can be used by internet marketing advertisers. Advertisers carry out large and small scale Internet marketing campaigns. This account can be configured to link directly to existing in-house and/or contracted call centers anywhere in the country and have calls switched to remotely located sales agents. In a marketing account, the user can enter or import Call Center Agents and Calling Lists into the tables.

In addition, the user can configure a Campaign Outbound Button, a Campaign Inbound Button, and a Free Promotion Button. The Campaign Outbound Button supports the set-up of large and small scale outbound marketing campaigns. Outbound campaigns can be carried out through a link to a large call center or through remote agents where the whole campaign is controlled and monitored from a single Internet connection. This enables small companies and volunteer based non-profit organizations to carry out sophisticated calling campaigns efficiently and cost effectively.

The Campaign Inbound Button supports inbound calling generated by customers. The customer can simply click a Campaign Inbound Button on an Internet banner. The button can also be sent as part of an e-mail marketing campaigns. Campaign Inbound buttons can also be placed in an Internet classified or directory listing such as the Yellow Pages, newspapers, magazines, and professional and industry directories.

The Free Promotion Button can be used in promotional campaigns. A Free Promotion Button can be e-mailed to a target recipient in exchange for a call to an advertiser, filling in a customer preference profile or other response deemed of value to the advertiser. It can be part of a new customer acquisition program or customer satisfaction or "Frequent Buyer" award program.

As shown in Table 4, a company account can be used for corporations and institutions. The Company Account serves larger organizations with multiple branch offices or a substantial number of at home staff or mobile workers. Also companies with a large customer or supplier base would benefit from the services offered by the Company Account.

A company account can be figured to have a Company/Staff Button, a Customer/Supplier Button, and a Custom Calling Card Button. The Company/Staff Button is an outbound calling button. Company/Staff Buttons can be configured as branch office and work at home or mobile worker Speed Dial Buttons, which provide convenience and control costs through direct billing and the use of low rates. A company can carry out Customer/Client outbound calling campaigns linked to the in-house call center or internal sales staff. The Company/Staff Button can also be linked to the company Customer Record Management System. Other applications include Call Conference directly or through integration within Group Collaboration Applications such as Lotus Notes. Staff can initiate automated outbound Return-Calls to parties who activated a Customer/Supplier Button. Customer/Supplier Buttons can act as a Call directory for Registered User Only or

B-to-B Website, providing direct voice link to various company departments. Consumer and service based companies can provide Customer/Supplier Buttons on company Websites or allow clients to place buttons on their personal Web sites or within their browser which link them to an their personal account officer or a sales, customer service, help desk or investor relations staff member. A Customer/Staff Button can also be placed in industry directories or company banner ads.

A Custom Calling Card Button allows the recipient to activate and place calls within the set Call Control limits. A Custom Calling Card Button allows a company to provide branch offices, at home workers and mobile staff with a controllable and cost efficient means of placing long distance business calls. These calls can be placed from a PC or internet enabled mobile phone or PDA. Restrictions can be placed on the button to tailor its use the intended corporate purpose.

As shown in Table 4, a professional/small business account can be used for professional offices and small businesses. It provides substantially all of the services supported by the Company Account with certain modification and additions to accommodate a smaller work force and customer base. It can be configured to have Office Button, Client Button, and Executive Card Button. Client Buttons can be placed on the company Website linked to specific key staff or to the owners. A Client Button can be e-mailed to a client or supplier requesting a call back at a scheduled time. A Client Button can also be placed in a Web banner ad with an offer for a free consultation, or embedded in a classified listing or internet directory.

Office Buttons support conference calling, automated Return-Call from inbound activated Client Button calls forwarded to voice mail, and small outbound customer call campaigns. A small office can configure PBX/Speed Dial buttons for immediate contact with key suppliers, customers, or owners with multiple contact numbers, such as home phone number, office phone number, cellular phone number, and pager number.

The Executive Card Button can act as a calling card integrated into internet linked cellular phone or PDA, without occurring high charges on wireless long distance calls. It can be given to key staff while away from the office, configured with the desired call restrictions and limits.

As shown in Table 4, a personal account can be used for individuals and families. It can be configured to have Personal Button, Private Chat Button, and Friends and Family Button. The Personal Button can be used as a private calling card for low long distance calling from a PC or cellular phone. A Personal Button can be configured to support Call Forwarding to a single number or to multiple numbers simultaneously or sequentially. It can include Call Screening and/or Voice Mail as part of these services. A Personal Button can initiate automated Call Backs to parties who have called via the Internet using a Private Chat Button or by phone which has been captured a callers ANI (Caller ID). It can request multiple call backs, eliminating the need to hang up between return calls. It can set to send Call Waiting or a pop-up alert and display voice messages.

A Private Button can be placed in classified ads such as personals or real estate, linking to a user's phone number. The number remains hidden and is never disclosed to the calling party. The user can change his call back number as he moves from place to place and will not miss important calls. He can leave a Voice Message. Private Buttons can be integrated into Internet Chat rooms for those who wish to speak directly but anonymously. The user can alert someone of interest to talk, in a way similar to the "off-line" Internet Chat option, without others knowing. Through the use of the Private Chat Button neither party will ever see the others telephone number. A user can e-mail Private Chat Buttons to others requesting a call-back immediately or at a scheduled time.

A Friends and Family Button can be sent by a user to family abroad, children away from home, loved ones, and special friends as a free calling privilege. But the user still retains control over the spending limits. It can be given as holiday gifts or a token of thanks.

FIGs. 23-34 show an example of the interfacing of a marketing account of Direct Connect. As shown in FIG. 23, the account page of a marketing account contains the information concerning the company which owns the account. For example, company 3002, shows the name of the company, telephone 3004 shows the telephone number of the company, email 3006 shows the email address of the company, and fax 3008 shows the fax number of the company.

The account page shown in FIG. 23 also contains the information concerning the account. For example, account name 3010 shows the name of the account, account number 3012 shows the account number, account executive 3014 shows the name of the person who is in charge of the account, and login ID 3016 shows the login ID of the account.

Also, the account page shown in FIG. 23 contains the information concerning the 5 records in the account. For example, campaign records 3018, if clicked, will cause a new display containing the campaign records; call center records 3020, if clicked, will cause a new display containing the call center records; call file records 3022, if clicked, will cause a new display containing the call file records.

In addition, the account page shown in FIG. 23 provides the options of new campaign

10 3024 for creating new campaign, modify campaign 3026 for modifying campaign, and delete campaign 3028 for deleting campaign.

Further, the account page shown in FIG. 23 contains a clear form 3030 for clearing the information shown on this page, a back 3032 for going back to a previous page, and a next 3034 for going to the next page.

15 FIG. 24 shows the display of campaign records page. It is invoked by clicking campaign records 3018 of FIG. 23. As shown in FIG. 24, campaign records page contains registered campaigns 3102, which lists, in window 3104, the type, the name, the associated client name, and the status of each of the registered campaigns. This page also contains options for manipulating the campaign list. For example, new campaign 3106 is for creating a

20 new campaign in the list, copy campaign 3108 is for making a copy of a registered campaign, modify campaign 31 10 is for modifying a registered campaign, and delete campaign 3112 is for deleting a registered campaign.

Also, the campaign records page shown in FIG. 24 contains current selection 3114, which lists, in window 3116, the type, the name, the associated client, and the starting and

25 ending date of each of the current campaigns. Clear 3118 is for clearing the content in window 3116.

In addition, the campaign records page shown in FIG. 24 contains fields for entry of new information. For example, campaign name 3120 is for entry of a campaign name, campaign account 3122 is for entry of the account number of a campaign, account executive

30 3124 is for entry of the name of the person in charge of an account, client name 3126 is for entry of the name of a target client, client account 3128 is for entry of a client's account number, department 3130 is for entry of the name of the department the campaign is associated, campaign dates 3136 and 3138 are for entries of the starting and ending dates, respectively, of the campaign, current button 3140 shows the appearance of current settings of the button associated with the campaign, and button settings 3142, if clicked, will allow a user to change the appearance and setting of the button. FIG. 25 shows the display of call file records page. It is invoked by clicking call file records 3022 of FIG. 23. As shown in FIG. 25, call file records page contains client call files 3202, which list, in window 3204, the file name, the client name, the contact name, the telephone number, the email address, and the fax number of each of the client call files. Also, new file 3206 is for creating a new file, modify file 3208 is for modifying a file, delete file 3210 is for deleting a file, and import file 3212 is for importing a file from another source. The call file records page shown in FIG. 25 also contains the information concerning call record. For example, target cust 3214 indicates the name of the target customer, telephone 3216 indicates the telephone number, email 3218 indicates the email address, web page 3220 indicates the name of the webpage, URL 3222 indicates the URL, and type 3224 indicates the record type. Further, this page provides options concerning call record. For example, new record 3226 is for creating new record, copy record 3228 is for making a copy of a record, and delete record 3230 is for deleting a record.

FIG. 26 shows the display of call center agent records page. It is invoked by clicking call center records 3020 of FIG. 23. As shown in FIG. 26, call center agent records page contains content control 3302, which controls the information displayed on this page to concern the records of either call center or call agent. When call center 3304 is clicked, the page will display the information concerning call centers. When remote agent 3308 is clicked, the page will display the information concerning call agents. When all 3312 is clicked, the page will display the information concerning both call centers and call agents. Also, when inbound 3306 is clicked, the page will display the information concerning inbound calls. When outbound 3310 is clicked, the page will display the information concerning outbound calls. When all 3314 is clicked, the page will display the information concerning both outbound and inbound calls. Look up 3316 is a link for more information. In the example shown in FIG. 26, the settings of content control 3302 makes the page show the information concerning outbound calls at remote agents.

The call center agent records page shown in FIG. 26 also contains call center/agent record 3318, which lists, in window 3320, the ID number, the name of the center/agent, the contact phone number, and number of agents, and the type of call centers or agents. Also, this page contains options for manipulating call center/agent records. For example, new record 3322 is for creating a new call center/agent record, copy record is for making a copy of a call center/agent record, modify record 3326 is for modifying a call center/agent record, and delete record 3328 is for deleting a call center/agent record.

In addition, the call center/agent records page shown in FIG. 26 contains fields for entries of call center/agent records. For example, ID # 3330 is for entry of the ID number of a call center/agent, company 3332 is for entry of the name of the company associated with the call center/agent, name 3334 is for entry of the name of the call center/agent, telephone 3336 is for entry of the telephone number of the call center/agent, email 3338 is for entry of the email address of the call center/agent, fax 3340 is for entry of the fax number of the call center/agent, login D# 3342 is for entry of the login ID number of the marketing account to be used at the call center/agent, type 3344 is for entry of the type of the call center/agent, ;= agent 3346 is for entry of the number of agents at the call center/agent, campaign 3348 is for entry of the name of the campaign to be carried out at the call center/agent, and client acc 3350 is the account number of the target client. Also, in 3352 indicates inbound calls and out 3354 indicates outbound calls.

Further, the call center agent records page shown in FIG. 26 contains information concerning campaigns assigned to call center/agent records. For example, telephone #'s 3356 indicates a list of telephone numbers for a campaign. A telephone number can be highlighted and, thereafter, added, when add 3358 is clicked, changed, when change 3360 is clicked, or deleted, when delete 3362 is clicked. Assigned campaigns 3364 lists the name of assigned campaigns. Start date 3366 and end date 3368, respectively, indicate the starting and ending dates of a campaign. Also, the call center agent records page shown in FIG. 26 contains information concerning the time table of call center/agent commitment in table 3382. The content of table 3382 can be changed. For example, when yearly 3374 is clicked, table 3382 will show a yearly calender; when monthly 3376 is clicked, table 3382 will show a monthly calender; when weekly 3378 is clicked, table 3382 will show a weekly calender; and when daily 3374 is clicked, table 3382 will show a daily time table. Also, when previous dates 3370 or next dates 3372 is clicked, table 3382 will show a previous or next call center/agent commitment time table, in a yearly, monthly, weekly, or daily format. In the example shown in FIG. 26, table 3382 is in the monthly format.

Similar to FIG. 26, FIG. 27 shows the display of campaign agent assignment page. As shown in FIG. 27, campaign agent assignment page contains content control 3402, which controls the information displayed on this page to concern the records of either call center or call agent. When call center 3404 is clicked, the page will display the information concerning call centers. When remote agent 3408 is clicked, the page will display the information concerning call agents. When all 3412 is clicked, the page will display the information concerning both call centers and call agents. Also, when inbound 3406 is clicked, the page will display the information concerning inbound calls. When outbound 3410 is clicked, the page will display the information concerning outbound calls. When all 3414 is clicked, the page will display the information concerning both outbound and inbound calls. Look up 3416 is a link for more information. In the example shown in FIG. 27, the settings of content control 3402 makes the page show the information concerning outbound calls at remote agents. The campaign agent assignment page shown in FIG. 27 also contains call center/agent record 3418, which lists, in window 3420, the ID number, the name of the center/agent, the contact phone number, and number of agents, and the type of call centers or agents. Also, this page contains options for manipulating call campaign agent assignment. For example, new record 3422 is for creating a new call center/agent record, modify record 3424 is for modifying a call center/agent record, delete record 3436 is for deleting a call center/agent record, and put in campaign 3428 is for inserting a campaign.

In addition, the campaign agent assignment page shown in FIG. 27 contains fields for entries of campaign agent assignment 3436, which lists, in window 3438, the names of campaigns, each with assigned call center/agent and the number of agent at the call center/agent. There are options for manipulating campaign agent assignment 3426. For example, clear assignment 3430 is for clearing the content of window 3438, modify assignment 3432 is for modifying assignments, and back to register 3434 is for going to register a call center/agent. Also, phone numbers 3440 lists phone numbers to be assigned by clicking assign 3442. Further, the campaign agent assignment page shown in FIG. 27 contains information concerning call center/agent availability in time table 3446. The content of time table 3446 can be changed. For example, when yearly 3462 is clicked, time table 3446 will show a yearly calender; when monthly 3464 is clicked, time table 3446 will show a monthly calender; when weekly 3466 is clicked, time table 3446 will show a weekly calender; and when daily 3468 is clicked, time table 3446 will show a daily time table. Also, when previous dates 3458 or next dates 3460 is clicked, table 3446 will show a previous or next call center/agent availability time table, in a yearly, monthly, weekly, or daily format. In the example shown in FIG. 27, time table 3446 is in the monthly format.

Also, the campaign agent assignment page shown in FIG. 27 contains fields for entry of campaign dates, selected based on the call center/agent availability shown in time table 3446. For example, campaign dates 3448 and 3450 are for entries of the starting and ending dates, respectively, selected based on the call center/agent availability shown in time table 3446. In addition, this page contains options for activating or deactivating the campaign. For example, activate 3452, if marked, sets the campaign in an active state. Alternatively, deactivate 3454, if marked, sets the campaign in a deactivated state. Also, set controls 3456 allows for the setting of campaign controls. FIG. 28 shows the display of campaign call file assignment page. As shown in FIG.

27, campaign call file assignment page contains campaign file options 3502. For example, email 3504, if chosen, sets campaign file in the form of email; web page 3506, if chosen, sets campaign file in the form of a banner in a webpage; calling 3508, if chosen, sets campaign file in the form of phone calls. Also, look up file 3510 is linked to a source for more information.

The campaign call file assignment page shown in FIG. 28 also contains client call file 3512, which list, in window 3514, the file name, client name, campaign name, record number, and the type of each client call file. The content of window 3514 can be manipulated. For example, new file 3516 is for creating a new file, modify file 3518 is for modifying a file, delete file 3520 is for deleting a file, view file 3524 is for viewing a file, and put in campaign 3524 is for inserting a campaign.

In addition, the campaign call file assignment page shown in FIG. 28 contains client call records 3526, which list, in window 3530, the target customer, the phone number, the email address, the URL, and the type of each client call record contained in a file indicated in file name 3528. The content of window 3530 can be manipulated. For example, new record 3532 is for creating a new record, modify record 3534 is for modifying a record, and delete record 3536 is for deleting a record. Further, the campaign call file assignment page shown in FIG. 28 contains campaign file assignment 3538, which list, in window 3542, the file name, contact person, phone number, record number, and status of each campaign file assignment contain in the campaign name identified by campaign name 3540. The content of window 3542 can be manipulated. 5 For example, clear 3544 is for clearing of the content in window 3542 and assign 3546 is for making the assignment in window 3542.

Also, the campaign agent assignment page shown in FIG. 28 contains fields for entry of campaign dates. For example, campaign dates 3548 and 3550 are for entries of the starting and ending dates, respectively. In addition, this page contains options for activating and

10 deactivating the campaign. For example, activate 3552, if marked, sets the campaign in an active state. Alternatively, deactivate 3554, if marked, sets the campaign in a deactivated state.

FIG. 29 shows the display of button settings page. It is invoked by clicking button settings of FIG. 24. As shown in FIG. 29, this page provides the various options. For

15 example, number of button copies 3802 is a field for entry of the number of copies for a button. Sequential button code if copied 3804 provides a "yes or no" choice. If Y (yes) is chosen, the copies for the button will have sequential numbers. If N (no) is chosen, the copies will not have sequential numbers. Identical button code if copied 3806 also provides a "yes or no" choice. If Y (yes) is chosen, the copies for the button will have an identical number. If N

20 (no) is chosen, the copies will not have an identical number. Require pin # ID on button 3808 also provides a "yes or no" choice. If Y (yes) is chosen, a pin # LD will be attached to the button and a user will have to use the pin # ID to activate the button. If N (no) is chosen, a pin # ID will not be attached to the button and a user will not need to use a pin # LD to activate the button. Require pin # ID on copies 3810 also provides a "yes or no" choice. If Y (yes) is

25 chosen, a pin # LD will be attached to a copy and a user will have to use the pin # LD to activate the copy. If N (no) is chosen, a pin # ID will not be attached to a copy and a user will not need to use a pin # LD to activate the copy.

FIG. 30 shows the display of a call control page of Direct Connect. As shown in FIG. 30, this page sets controls on both outbound and inbound calls. It contains call screening

30 3652, which limits the country code and area code of outbound and inbound calls. For example, call from country code 3602 lists the country code from which inbound calls will be taken. Inbound calls from a country code not listed in call from country code 3602 will not be taken. Similarly, call from area code 3604 lists the area code from which inbound calls will be taken. Inbound calls from an area code not listed in call from area code 3604 will not be taken. Also, call to country code 3606 lists the country code to which outbound calls will be made. Outbound calls to a country code not listed in call to country code 3606 will not be made. Similarly, call to area code 3608 lists the area code to which outbound calls will be made. Outbound calls to an area code not listed in call to area code 3608 will not be made.

The display of the call control page of Direct Connect shown in FIG. 30 also contains call limits 3654, which sets more restraints. For example, number of calls 3610 sets the maximum number of calls permitted to a MT button. Length of call 3612 sets the maximum time duration, in the unit of minute, allowed to a single phone call. Per call amount 3614 sets the maximum dollar amount allowed for a single phone call. Total amount 3616 sets the dollar amount allowed for all the phone calls that can be used of a MT button. Date range 3618 and 3620 specify the starting and ending dates, respectively, within which phone calls can be made. Time range 3624 and 3626 specify the starting and ending daily time, respectively, within which phone calls can be made. Select calendar 3628, if clicked, provides a calender indicating the date and time ranges.

Additional restraints are also contained in the display of the call control page of Direct Connect shown in FIG. 30. For example, permit schedule calls 3630 provides a "yes or no" option. If yes is chosen, schedule calls will be permitted. On the other hand, if no is chosen, schedule calls will not be permitted. Copy/transfer button 3632 also provides a "yes or no" option. If yes is chosen, the copy/transfer of the button will be permitted. On the other hand, if no is chosen, the copy/transfer of the button will not be permitted. Voice message on limits 3634 also provides a "yes or no" option. If yes is chosen, voice message on limits will be permitted. On the other hand, if no is chosen, voice message on limits will not be permitted. Also, record 3636, if clicked, allows for voice message to be recorded.

FIG. 31 shows the display of another call control page of Direct Connect. As shown in FIG. 31, this page sets controls on inbound calls only. It contains call screening 3702, which limits the country code and area code of inbound calls. For example, block country code 3704 lists the country code from which inbound calls will be blocked. Similarly, take only country code 3708 lists the country code from which inbound calls will be taken. Also, block area code 3706 lists the area code from which inbound calls will be blocked. Take only area code 3710 lists the area code from which inbound calls will be taken. The display of the call control page shown in FIG. 31 also contains customer call settings 3712, which sets more restraints. For example, limit # of call attempts 3714 provides a "yes or no" option. If yes is chosen, limit # of call attempts will be permitted. On the other hand, if no is chosen, limit # of call attempts will not be permitted. Save customer ANI 3716 also provides a "yes or no" option. If yes is chosen, customer ANI will be saved. On the other hand, if no is chosen, customer ANI will not be saved. Allow scheduled calls 3718 also provides a "yes or no" option. If yes is chosen, scheduled calls will be allowed. On the other hand, if no is chosen, scheduled calls will not be allowed. Voice message if screened 3720 also provides a "yes or no" option. If yes is chosen, a blocked inbound call can be recorded as a voice message. On the other hand, if no is chosen, a blocked inbound call can not be recorded as a voice message. Record 3722, if clicked, allows for voice message to be recorded. Internet message if screened 3724 also provides a "yes or no" option. If yes is chosen, a blocked inbound call can be recorded as an internet message. On the other hand, if no is chosen, a blocked inbound call can not be recorded as an internet message. Enter 3726, if clicked, allows for internet message to be entered.

The display of the call control page shown in FIG. 31 also contains agent no answer settings 3728, which sets more restraints. For example, schedule callback 3730 provides a "yes or no" option. If yes is chosen, schedule callback will be permitted. On the other hand, if no is chosen, schedule callback will not be permitted. Rollover to next agent 3732 also provides a "yes or no" option. If yes is chosen, rollover to next agent will be permitted. On the other hand, if no is chosen, rollover to next agent will not be permitted. Voice message if busy 3734 also provides a "yes or no" option. If yes is chosen, a voice message can be recorded if the line is busy. On the other hand, if no is chosen, no voice message can be recorded even if the line is busy. Record 3736, if clicked, allows for voice message to be recorded. Internet notice if busy 3738 also provides a "yes or no" option. If yes is chosen, an internet notice is allowed if the line is busy. On the other hand, if no is chosen, no internet notice is allowed even if the line is busy. Enter 3740, if clicked, allows for internet notice to be entered.

Similar to FIG. 31, FIG. 32 shows the display of another call control page of Direct Connect. As shown in FIG. 32, this page sets controls on outbound calls only. It contains call screening 3902, which limits the country code and area code of outbound calls. For example, block country code 3904 lists the country code to which outbound calls will be blocked. Similarly, make only country code 3908 lists the country code to which outbound calls will be made. Also, block area code 3906 lists the area code to which outbound calls will be blocked. Make only area code 3910 lists the area code to which outbound calls will be made.

The display of the call control page shown in FIG. 32 also contains agent call settings 5 3912, which sets more restraints. For example, limit # of call attempts 3914 provides a "yes or no" option. If yes is chosen, limit # of call attempts will be permitted. On the other hand, if no is chosen, limit # of call attempts will not be permitted. Callback if busy 3916 also provides a "yes or no" option. If yes is chosen, a callcack will be made when the line is not busy any longer. On the other hand, if no is chosen, a callback will not be made when the line 0 is not busy. Call back if wrong person 3918 also provides a "yes or no" option. If yes is chosen, a callcack will be made to the correct person. On the other hand, if no is chosen, a callback will not be made to the correct person. Record if wrong number 3920 also provides a "yes or no" option. If yes is chosen, the wrong number will be recorded. On the other hand, if no is chosen, the wrong number will not be recorded. Voice message on connect 3922 also 5 provides a "yes or no" option. If yes is chosen, a voice message will be recorded. On the other hand, if no is chosen, no voice message will be recorded. Record 3924, if clicked, will allow for the voice message to be recorded. Voice message if voice mail 3926 also provides a "yes or no" option. If yes is chosen, a voice message will be recorded. On the other hand, if no is chosen, no voice message will be recorded. Record 3928, if clicked, will allow for the voice message to be recorded. Voice message if screened 3930 also provides a "yes or no" option. If yes is chosen, a voice message will be recorded. On the other hand, if no is chosen, no voice message will be recorded. Record 3932, if clicked, will allow for the voice message to be recorded. Internet message if screened 3934 also provides a "yes or no" option. If yes is chosen, an internet message will be entered. On the other hand, if no is chosen, no internet message will be entered. Enter3936, if clicked, will allow for an internet message to be entered.

FIG. 33 shows the display of pre-recorded messages page of Direct Connect. As shown in FIG. 33, this page sets pre-recorded messages. It contains voice/sound 3852, which sets whether a pre-recorded message should be a phone message or an internet notice and whether the message should be currently recorded or imported from an import file. For example, phone message record now 3854 sets the pre-record message in the form of a phone message and to be currently recorded. On the other hand, phone message import file 3856 sets the pre-recorded message in the form of a phone message and to be imported. Similarly, internet notice record now 3858 sets the pre-recorded message in the form of an internet message and to be currently recorded. Also, internet notice import file 3860 sets the prerecorded message in the form of an internet notice and to be imported. The display of pre-recorded messages page shown in FIG. 33 also contains text-to- speech 3862, which sets, in the text to speech conversion, whether a pre-recorded message should be a phone message or an internet notice and whether the message should be currently typed in or imported from an import file. For example, phone message typed in now 3864 sets the pre-recorded message in the form of a phone message and to be currently typed in. On the other hand, phone message import file 3866 sets the pre-recorded message in the form of a phone message and to be imported. Similarly, internet notice typed in now 3868 sets the prerecorded message in the form of an internet message and to be currently typed in. Also, internet notice import file 3870 sets the pre-recorded message in the form of an internet notice and to be imported. The display of pre-recorded messages page shown in FIG. 33 also contains text only

3872, which sets, in the text only situation, whether a pre-recorded message should be a phone message or an internet notice and whether the message should be currently typed in or imported from an import file. For example, phone message typed in now 3874 sets the prerecorded message in the form of a phone message and to be currently typed in. On the other hand, phone message import file 3876 sets the pre-recorded message in the form of a phone message and to be imported. Similarly, internet notice typed in now 3878 sets the prerecorded message in the form of an internet message and to be currently typed in. Also, internet notice import file 3880 sets the pre-recorded message in the form of an internet notice and to be imported. In the embodiment where the service provision network 20 is an on-line gift distribution network and the services are the distribution of gift certificates, SN 5000 is a network connected to at least one department store 5050, where on-line redemption of gift certificates is provided as shown in FIG. 34. In this embodiment, a user, whether the owner or a recipient of a MT, can activate the MT to redeem a gift certificate at department store 5050, preferably when doing on-line shopping. Meanwhile, the owner of the MT remains in control of the services, such as the dollar amount and valid department store, associated with the MT. FIG. 35 shows an example of the distribution of a gift certificate MT. As shown in FIG. 35, MC 1000 lists gift certificate MT's at step 5012. These gift certificate MT's are authorized by at least one department store. They can be created by MC 1000. They can also be pre-existing gift certificates imported from a department store. At step 5014, a user registers a gift certificate and becomes the owner of the gift certificate. At the same time, a gift certificate account is established and the gift certificate owner obtains the AC (access code) to the gift certificate account. At step 5016, the owner transfers the gift certificate to a recipient. After the transfer, the owner remains in control of the gift certificate. The owner can access the gift certificate account and make changes to the services associated with the gift certificate. For example, the owner can change the dollar amount associated with the gift certificate. Also, the owner can change the list of valid department stores where the gift certificate can be redeemed. In addition, the owner can change the expiration date of the gift certificate. At step 5018, the recipient redeems the gift certificate at a department store.

According to the present invention, the technical functioning of a MT can be embodied in a variety of ways. In one embodiment, a MT functions as a Mobile Internet Proxy ("MLP" thereafter). The MIP is a minimum two-part string of digitally coded instructions. The first part of the string holds a Universal Resource Locator ("URL") which is the internationally accepted standard for identifying, locating and connecting to a registered address or end point over the Internet. The second part of the string is at least one unique MIP Identifier which may be any string of numbers, letters or symbols which follow an accepted standard for their digital representation such as the ANSI standard or other generally accepted digital coding standard. A MIP may have one or more ML? Identifiers.

In order for a user to activate a ML? he must be connected or "logged-on" to the Internet. A user logged on to the Internet has a unique URL which identifies his address. Following the Internet Protocol Standard, this address or URL may be assigned before or at the time the user logs on. When the user activates or "clicks" the MLP, this initiates a process whereby the user sends a request from his URL to communicate with the MLP URL. The MLP URL is referred to as the MIP Service Point.

The MIP Service Point is logged on to the Internet at all times. Upon the activation of the MIP by the user at least three critical functions are executed. First the locating of the MIP Service Point based on the MIP URL. Secondly, the MIP URL is located and is passed the string of code that has been appended to the MLP URL address in this case the MLP Identifier(s). Thirdly, the Service Point is passed the URL of the user who activated the MIP. This process is referred to as the Service Request. The user in activating the MLP has said "I am on the Internet, I am sending you, the Service Point, the MIP Identifier associated with some partially or wholly pre-defined service, I want you, the Service Point, to deliver me or deliver on my behalf that service. I am giving you, the Service Point, my Internet address should you wish to deliver the service to me directly on the Internet or should you have any need to communicate with me further."

Upon the making of the Service Request, the Service Point reads the ML? Identifier and searches for that ML? ID Record in its database. The ML? ED Record is a database record which holds the MEP ED in the first field and holds in one or more of its remaining fields strings of computer code (Service Instruction Code). The Service Instruction Code of a MEP LD Record is referred to as a MEP Script. A user Service Request might trigger a MEP Script associated with the ML? ID which requires further information from the user before the script can be fully executed and deliver the requested service i.e. ML? Script User Variables. In this case, the users URL, which was passed to the Service Point at the time of the Service Request, would be used by the ML? Script to open a a browser window at the users screen noting the request for user input. Once all variables had been loaded into a MEP Script it would be passed to a Media Gateway Controller or Softswitich.

The Service Instruction Code making up a MEP Script could be written in a variety of computer languages including C++ or the JAVA computer language. If written in Java they could include Java Servlets, simple or complex Java programs or Java pointers to other Java programs.

In the case of Communications Services ( Voice, fax, data (video, audio) the actual Java Code could be written according to the rules of a variety of Applications Programming Interface Protocols including; JTAPI, H.323 or SEP). All three protocol support similar classes of telephony service request instructions, however each is based on a different architecture. In all three cases the instruction set or service request would be passed to a Media Gateway Controller or Softswitch which is a server based computer system that stands between the three signaling protocol systems mentioned earlier (JTAPI, H.323, SEP) translating those instructions and passing them to the Media Gateway. A Media Gateway Controller will support a variety of incoming APIs such as JTAPI,

SEP, H.323 and outgoing will support those protocols necessary to interface to a variety of different Media Gateways. When initiating an outgoing VoIP communications session it will utilize MGCP or MEGACO in communicating and setting up a VoIP session on a VoEP Gateway. When initiating an SS7 or circuit switched session it will utilize SCP in communicating with and setting up a standard circuit switched phone call. A Media Gateway that supports both packet (EP/ATM) and circuit switched (SS7) network interfaces can be controlled by the Softswitch to deliver converged or hybrid communications sessions by cross-connecting the two different types of networks. The media Gateway will handle the actual voice or data translation between the two networks.

In this fashion a MEP has acted first as an Internet Service Requestor i.e. when activated it signals the Service Point requesting a service. The unique MEP ED embedded in the MEP acts as a proxy for the specific service requested which has been previously defined as a MEP Script and stored in a MEP Record along with the unique MEP ID. The MEP may be owned by anyone and need not be owned by the user requesting the service.

A MIP always has an Owner. A MEP Owner is a party who has registered at the Service Point and has agreed to be liable for and responsible for the payment for those services delivered when and only when the MIP is activated and a communication session is initiated or the desired service delivered. Payment for such services may be via a registered credit/debit card or according to agreement between the MEP Owner and Service Point Service Provider. A MEP Owner may have multiple MEPs. A MEP Owner may alter any MEP Script and therefore services underlying a particular MEP. The MIP not being an application or attachment is mobile within the confines of the

Internet i.e. it can be transferred or passed through the Internet via e-mail.

Unlike other methods or protocols that act to utilize the Internet to make a Telephony Service Request, i.e. SIP, H.323 or for that matter any kind of direct Service Request, a MEP is an abstracted Service Request in the sense that it does not directly request a service but requests that the service directly associated with the MEP ED(s) be delivered. An other novel feature of the MEP is that since all service requests result in calls or connections are initiated by the Service Point i.e. outbound from the Service Point and inbound to the user the party requesting and receiving the telephony service need not be the party obligated to pay for the service if he is not the owner of the MEP. Within this same context neither the party requesting a service or making a call nor the party delivering the service or answering the call need be the party or parties paving for the service so long as neither party are the owner of the MIP. The MIP uniquely separates service from obligation to pay for service and by abstracting that service through the MEP ED allows the obligor to define and control the level of service provided to the beneficiary by being able to change the services associated with the MEP ED without requesting the return of or replacement of the MIP. The MIP acts as a freely transferable and negotiable Service Instrument whose value and function may be altered at any time and may be transferred electronically over the Internet without alteration to the instrument itself.

Finally, while the present invention has been described with reference to certain preferred embodiments, it should be kept in mind that the invention is not limited to these. Variations of the above may well be within the present invention, whose extent is given by the scope of the claims presented below. It should also be kept in mind, that practicing the claimed invention need not necessarily result in any, let alone all, of the advantages and benefits discussed above.

Claims

CLAIMSWhat is claimed is:

1. A method of facilitating a telephone call comprising the steps of: transmitting, to a receiving party, a first transferrable call token comprising a first address and a first identification number; receiving, from an activating party, a first hypertext transfer protocol (HTTP) request including said first identification number; retrieving first information referenced by said first identification number; making a first call to a first party; making a second call to a second party; and merging the first and second calls.

2. The method of claim 1, further comprising the steps of: transmitting, to the activating party, a second HTTP request to enter a first telephone number, after the step of retrieving first information; and receiving, from the activating party, the first telephone number.

3. The method of claim 2, further comprising the steps of: transmitting, to the activating party, a third HTTP request to enter a second telephone number; and receiving, from the activating party, the second telephone number.

4. The method of claim 1, wherein the first address comprises a uniform resource locator

(URL) and the first identification number is embedded in the first address.

5. The method of claim 1, further comprising the step of updating at least one record associated with said first identification number.

6. A computer storage medium having executable software code stored thereon for facilitating a telephone call, the executable software code including: code to transmit, to a receiving party, a first transferrable call token comprising a first address and a first identification number; code to receive, from an activating party, a first hypertext transfer protocol (HTTP) request including said first identification number; code to retrieve first information referenced by said first identification number; code to make a first call to a first party; code to make a second call to a second party; and code to merge the first and second calls.

7. The computer storage medium of claim 6, the executable software code further including: code to transmit, to the activating party, a second HTTP request to enter a first telephone number; and code to receive, from the activating party, the first telephone number.

8. The computer storage medium of claim 7, the executable software code further including: code to transmit, to the activating party, a third HTTP request to enter a second telephone number; and code to receive, from the activating party, the second telephone number.

9. The computer storage medium of claim 6, wherein the first address comprises a uniform resource locator (URL) and the first identification number is embedded in the first address.

10. The computer storage medium of claim 6, the executable software code further including code to update at least one record associated with said first identification number.

11. A computer having associated therewith executable software code configured to facilitate a telephone call, the executable software code including: code to transmit, to a receiving party, a first transferrable call token comprising a first address and a first identification number; code to receive, from an activating party, a first hypertext transfer protocol (HTTP) request including said first identification number; code to retrieve first information referenced by said first identification number; code to make a first call to a first party; code to make a second call to a second party; and code to merge the first and second calls.

12. The computer of claim 11 , the executable software code further including: code to transmit, to the activating party, a second HTTP request to enter a first telephone number; and code to receive, from the activating party, the first telephone number.

13. The computer of claim 12, the executable software code further including: code to transmit, to the activating party, a third HTTP request to enter a second telephone number; and code to receive, from the activating party, the second telephone number.

14. The computer storage medium of claim 11, wherein the first address comprises a uniform resource locator (URL) and the first identification number is embedded in the first address.

15. The computer storage medium of claim 11, the executable software code further including code to update at least one record associated with said first identification number.

16. A method of initiating a telephone call comprising the steps of: receiving a first transferrable call token comprising a first address and a first identification number; transmitting a first hypertext transfer protocol (HTTP) request including said first identification number; and receiving a telephone call.

17. The method of claim 16, further comprising the steps of: receiving a second HTTP request to enter a first telephone number, after the step of transmitting the first HTTP request; and transmitting the first telephone number.

5 18. The method of claim 17, further comprising the steps of: receiving a third HTTP request to enter a second telephone number; and transmitting the second telephone number.

19. The method of claim 16, wherein the first address comprises a uniform resource 10 locator (URL) and the first identification number is embedded in the first address.

20. A computer storage medium having executable software code stored thereon for initiating a telephone call, the executable software code including: code to receive a first transferrable call token comprising a first address and a first 15 identification number; code to transmit a first hypertext transfer protocol (HTTP) request including said first identification number; and code to receive a telephone call.

20 21. The computer storage medium of claim 20, the executable software code further including: code to receive a second HTTP request to enter a first telephone number; and code to transmit the first telephone number.

25 22. The computer storage medium of claim 21, the executable software code further including: code to receive a third HTTP request to enter a second telephone number; and code to transmit the second telephone number.

30 23. The method of claim 20, wherein the first address comprises a uniform resource locator (URL) and the first identification number is embedded in the first address.

24. A computer having associated therewith executable software code configured to initiate a telephone call, the executable software code including: code to receive a first transferrable call token comprising a first address and a first identification number; code to transmit a first hypertext transfer protocol (HTTP) request including said first identification number; and code to receive a telephone call.

25. The computer storage medium of claim 24, the executable software code further including: code to receive a second HTTP request to enter a first telephone number; and code to transmit the first telephone number.

26. The computer storage medium of claim 25, the executable software code further including: code to receive a third HTTP request to enter a second telephone number; and code to transmit the second telephone number.

27. The method of claim 24, wherein the first address comprises a uniform resource locator (URL) and the first identification number is embedded in the first address.

28. A method of facilitating a service comprising the steps of: transmitting, to a receiving party, a first transferrable service token comprising a first address and a first identification number; receiving, from an activating party, a first hypertext transfer protocol (HTTP) request including said first identification number; retrieving first information referenced by said first identification number; and providing service to a party.