WO2001080221A9 - System and method for interfacing telephones to world wide web sites - Google Patents

Abstract

The invention relates to an arrangement with a front module which serves as a telephone interface between caller and the system which is the subject of this invention, an application fulfilling the role of database for the storage of various voice messages, an agent module 'Internet to maintain information of Internet sites on the system and a communications module that serves as an interface to the public switched telephone network and the Internet. From an operational point of view, the system dialogues with a user in voice mode, to receive requests, such as requests to purchase goods and services or information. The system communicates requests for goods and services or information to a website via the Internet. The system can also be configured to receive information or questions from websites, and to contact users by telephone to present information or questions to them, while receiving answers to questions and providing them to the website. The system also allows two-way communications between a user and a website. The website can communicate with the information in the system that needs to be routed to the user, and the system can contact the user over the phone and give them the information.

Description

System and Method for Interfacing Telephones to World Wide Web Sites

Background of the Invention

This invention relates to a telephone-to-server and a web site-to-server communications interface. More particularly, the invention relates to a computer system and method for carrying out a communications interface whereby two-way communications between telephone callers and World Wide Web sites are provided.

With the recent interest in electronic commerce, commercial web sites have become a driving force in what is now a global economy. Even with the rapid increase in commercial web sites on the Internet, user Internet access is lagging. With only about 40% of United States households having Internet access, and 10% of the International households having Internet access, there is still a large number of people who do not have access to the Internet. One reason these percentages are low is that a user typically has to pay an Internet Service Provider for Internet access, purchase expensive computer hardware and software, and has to develop certain skills to surf the web. Portable Internet access devices are also available, but these devices typically attract users who already have home or office Internet access. These devices are not attracting new users to the Internet.

To attract new users to the Internet and to expand the reach of those who have Internet access, what is needed is a communications device that is common, user friendly, low cost, and can communicate with web sites over the Internet. One device that has all of the above benefits except the ability to communicate with web sites is a standard telephone. What is needed is a communications interface that can provide a communications link between telephones and web sites so that a telephone caller can send and receive information to and from web sites.

Summary of the Invention

Deficiencies in the prior art are overcome, and an advance in the art is achieved with a system that interfaces telephones to the Internet web sites. The system comprises a front-end module for providing a telephone caller interface to the system, an application database for storing various voice scripts, an Internet agent module for interacting with a web site and a communications module that interfaces with the Public Switching Telephone Network and with the Internet. Operationally, the system interacts with a user in voice to receive requests, such as a request to purchase goods and services or information. The system communicates the request for goods and services or the request for information to a web site via the Internet, and communicates the results to the user. The system is also capable of being configured to receive information or questions from web sites, and to initiate access to a telephone user to present the information or questions, to receive answers to the questions, and to provide the answers to the web site.

Brief Description of the Drawings FIG. 1 presents a network diagram of a system in accord with the principles disclosed herein;

FIG. 2 illustrates a block diagram of a illustrative system of the present invention;

FIG. 3 is a flow chart depicting the operation of the system as it interacts with a user;

FIG. 4 is a flow chart depicting the operation of the system as it provides information to a user.

FIG. 5 is a flow chart depicting the operation of the system as it accesses telephones to provide and receive information; and FIG. 6 illustrates a flow chart depicting the operation of the system in an auction arrangement.

Detailed Description

FIG. 1 presents a high level system diagram of an arrangement that embodies the principals of the invention. It shows a general purpose telephone 2 connected to the Public Switch Telephone Network (PSTN) 4. System 6, which provides the communications interface between the telephone 2 and a web site 8, is connected to PSTN 4 and to the Internet 9. Telephone 2 can be a landline telephone, or a cellular telephone. System 6 is also adapted to interface web site to a speech enabled Internet device 5 such as a telephone that uses the Voice Over Internet Protocol (VOIP). System 6 is also capable of simultaneously linking multiple telephones 2 and speech enabled Internet devices 5 to multiple web sites 8. It should be realized that system 6 can provide service concurrently to many voice devices such as elements 2 and 5.

FIG. 2 presents a general block diagram of an illustrative arrangement of server 6. It includes a processor 1 10, a memory 50, a telephone communications module 20, and an Internet communications module 40. Communications module 20 provides two-way telephone communications between telephone callers and server 6, while communications module 40 provides two-way communications between web sites and server 6. Memory 50 stores a front-end module 65, databases 60, an Internet agent module 90. In the embodiment illustrated in FIG. 2, front-end module 65 includes a speech recognition module 70, and a speech generator module 80.

Databases 60 includes an application database 180, a call record database 190, a profile database 100, a product database 105, a purchase order database 160, a Uniform Product Code (UPC) database 165, a survey database 195, and a telephone number database 135. Internet agent module 90 includes a scraping module 140, a data synchronization module 150, an email module 155, a posting module 170, a reverse look-up module 175, and a parsing module 185.

Telephone communications module 20 comprises a conventional module - for example, modem bank and associated software - that connects telephones to server 6 via the Public Switch Telephone Network (PSTN), and a digital interface module that interacts with digital devices such as device 5. Internet communications module 40 is a conventional software module that connects server 6 to the Internet using, illustratively, the protocol employed on the World Wide Web. As illustrated in the FIG. 2 embodiment, speech recognition module 70 and speech module 80 provide a user interface to server 6. These modules allow a telephone caller to communicate with server 6 in audio (speech or DTMF), and allow server 6 to verbally communicate with the caller. Speech recognition module 70 is a conventional software module. The Lernaut Haustie firm offers a software module known as "Real Speak" that may be employed to realize module 70. Speech Works International offers a software module known as "Speech Works" that may be employed to realize module 80. DTMF detectors are notoriously well known in the art. Databases 60 includes application database 180, call record database

190, profile database 100, product database 105, purchaser order database 160, and Universal Product Code (UPC) database 165. One category of items that application database 180 stores is voice scripts. As described in more detail below, server 60 can be adapted to communicate with a number of predetermined web sites, each of which belongs to a merchant. Each merchant may want to have his/her own desired manner by which the merchant wants to interact with users. That includes different greetings and, of course, different prompts, because those are related to the merchant's business. For example, a web site that sells books will have voice scripts relating to books. Accordingly, application database 180 stores voice scripts that, at least in one illustrative embodiment, are segregated by merchants. There is a grouping of voice scripts for merchant A, another grouping of voice scripts for merchant B, etc. for the merchant web sites. Additionally, database 180 stores common voice scripts such as "Hello" or "What is your credit card number?" which can be used in association with all of the merchants.

Call record database 190 stores call activity, such as the time a call started, ended, and what voice scripts were played. This information is stored for determining fees that are billed to the merchants' web sites, as well as for other reasons, such as maintenance analyses. Profile database 100 stores telephone caller information, such as shipping information and billing information. For example: Name: John Doe

Telephone number: 973-444-1221 Shipping Address: 34 Main Street, New York, NY, 10022. Past purchases: x, y, z, ...

The FIG. 2 embodiment includes Universal Product Code (UPC) database 165 stores. It stores most currently known prices of products and Universal Resource Locator (URLs) of merchant web sites that sell those products. Internet agent module 90 includes scraping module 140, data synchronization module 150, an email module 155, a posting module 170, a reverse look-up module 175, and parsing module 185. Scraping module 140 coordinates accessing, searching, and retrieving of information from merchant web sites for storage in server 6. Scraping module 140 comprises scraping agents that are unique to each merchant web site. The scraping agents are programmed using conventional programming techniques and development tools. Web Method offers a software development tool known as "Wittle" that may be employed to realize the scraping agents. The scraping agents are programmed to automatically navigate to web sites and to particular web pages for specific information, such as to retrieve a cost of a book. To illustrate, a programmer, using a web browser, might go to a desired web page and note the URLs required to get to that page. Once at the desired web page, the programmer may view the Hypertext Markup Language (html) code of the page and note the html tag associated with the information on the page that the programmer would like the scraping agent to retrieve, such as a price of the book. The programmer may then copy the html tag or tags in the row of html code that includes the price of the book and include the copy in the agent program. The programmer would also include the URLs in the agent program so that the scraping agent can navigate to the web page.

During operation, the scraping agent can negotiate to the desired web page, using the URLs, and can scan the html within the web page, until it finds the row of html tag or tags that match the copy of html tag or tags within the program. Once the scraping agent locates the row of html tag or tags that match the copy, it can scan through the row of tags until it locates the price of the book. Once the price of the book is located, the scraping agent can retrieve the information, store the information in product database 105, and convert the information to voice scripts, which are stored in application database 180. Data synchronization module 150 accesses, searches, and retrieves information from merchant web sites to synchronize databases in server 6 with databases at the merchant web sites. Module 150 can use the scraping agents in scraping module 140 to search for information that has been changed, or is new, or has been deleted from the merchant's web site database since the last time server 6 was synchronized with the database. Module150 is programmed to routinely go to the web site and check for changes in information. If any changes are found, module 150 makes the appropriate changes in product database 105, thus keeping the information current. Product database 105, for example, can store records of products having three fields, a manufacturer field, a model number field, and a price field. For example, a record may be named "Sony", the manufacturer field can contain the name "Sony", the model number field may contain a model number "CD1234", and the price field may contain a price "$4.00". After module 150 retrieves the information from the web site, it takes the information and compares it first to the record names in database 105. Referring back to the example, if module 150 finds the record name "Sony", it compares the fields within the record to the information retrieved from the web site. If all three fields in the database match the information retrieved from the web site, then the information in the record contains current information and does not need to be updated. If the record is not found within the database 105, then a record should be added to database 105 containing the new information. This scenario typically occurs when a new product has been added to a web page. If the record is found, but the price field does not match the price retrieved from the web page, then the price should be updated to reflect the current price of the item. This situation usually occurs when the web site has changed the sales price of the item. If module 150 does not find the product information that it is looking for in the web page, then the record relating to that information is deleted from database 105. This scenario occurs when the web site is no longer selling the product.

Email module 155, which is a conventional module that is well known to those skilled in the art, receives email at server 6, and sends email to merchant web sites or to e-mail addresses of the users of elements 2 and 5 (when appropriate, and if such users have e-mail addresses that are known to server 6).

Posting module 170 retrieves purchase order forms from application database 180, which is another category of items that are stored in application database 180, and populates the forms with information received from callers and information retrieved from other databases. Each purchase order form, which is adapted to the merchant's specification, once populated with data is sent to the appropriate merchant's site, where the merchant can fulfill the order. The following discussion discloses an operational schema where website merchants make a telephone number known to the public, allowing a person to call that number and to place an order for goods offered by the merchant's web site. Generally speaking, in accordance with the principles of this invention, when a person calls the advertised telephone number, the caller is connected to server 6 the caller interacts in voice with server 6 to place his or her order, server 6 sends a purchase order to the merchant's web site and receives a confirmation. Server 6 informs the caller that the order has been successfully executed, and the interaction terminates.

The general operation of an embodiment will now be described with reference to FIG. 3. At step 200, a caller calls a branded telephone number that connects the caller to server 6. A branded telephone number is a number that is associated with a specific merchant web site. The caller may believe that a connection was made to the merchant but, in fact, the connection is made to server 6. At step 210, server 6 receives the telephone call and the calling party's number (conventional hardware/software in module 20). In applications where a number of different called party numbers all converge on server 6, module 20 in step 210 also obtains the called party's number. Employing the Dialed Number Identification Service (DNIS), the task of identifying at server 6 which number was called by an incoming call is quite simple. It should be noted, however, that server 6 could comprise a collection of computers, each of which is dedicated to one merchant, and is the terminating point for a single telephone number. In such an arrangement there is no need to obtain the called number.

The embodiment disclosed in FIG. 2 includes an reverse look-up module 175, which is used to search the Internet for caller information.

Module 175 is employed to provide information about callers who have not yet identified themselves to server 6. By accessing long distance directory assistance web sites, module 175 can retrieve a name and an address of a person associated with a telephone caller's Automatic Number Identification (ANI). In embodiments that employ module 175, the module performs its function in step 210. That is, if there is no record found in profile database 100 for the number provided by ANI, reverse look-up module 175 searches the Internet for caller information. Advantageously, before this information is stored in profile database 100, a voice script is played asking the caller whether the information is correct. An affirmative response triggers a process that stores the information in profile database 100. A negative response triggers a series of voice prompts that ask the caller for his or her name and address, which are then stored in profile database 100. Following step 210, control passes to step 220, where server 6 retrieves appropriate voice scripts from application database 180 (of the merchant associated with number called by the user) and initiates a dialog with the user. The dialog is a combination of fixed scripts, together with scripts that are modified in accordance with information that is received from the user, and database query results (from database 105) that are obtained from the following step 230, which in FIG. 3 follows step 220. Steps 220 and 230 thus operate interactively for the duration of the dialog.

To illustrate, the dialog might follow the following sequence: Script 1 : "Welcome to Amazon.com" Script 2 (based on information from step 210): "Mr. John Doe" Script 3: "What book would you like to purchase ?" Caller: "I want to buy the book The Three Pigs"

Script 4 (based on information from database 105): "We have the book 'The Three Pigs' in stock" Script 5 (based on information from database 105): "It's price is $7." Script 6: "Would you like a summary of the book The Three Pigs ?" Caller: "No"

Script 7: "Would you like to purchase the book The Three Pigs ?" Caller: "Yes" Etc.

At step 240, a record of the negotiations is stored in call record database 190 in a table associated with the caller's name. Primarily, the information is stored for situations where, for example, the user wishes to inquire about the transaction. At step 250, posting module 170 retrieves an order form for a purchase from application database 180 that is acceptable for use on the merchant's web site. Using the information retrieved from the caller during the dialog and information retrieved from profile database 100 (e.g. caller's name), posting module 170 populates the information into the order form and sends it to the merchant web site, where the merchant can fulfill the order. Additional voice script information, such as a sales order number, is played for the caller. If the caller has an e-mail address that server 6 knows about, then the purchase order form forwarded by server 6 to the web site includes the user's e-mail address. If the e-mail address is given, the web site sends an e-mail message to the user, informing the user that a purchase order was placed. The above states that step 230 accesses product database 105. Of course, unless product database 105 is all-inclusive, it is quite possible that database 105 would not contain the item that the caller wishes to purchase. It should be understood that, at step 230, if product database 105 does not contain the product information that the caller is looking for, then the server 6 proceeds to access the merchant's web site directly (using scraping module 140) and search a database within the web site for the sought information. Once found, server 6 searches for information such as price and quantity, retrieves the information and stores it in product database 105.

Another embodiment of the present invention is illustrated by the flowchart of FIG. 4. This embodiment allows a caller, who is out shopping in a merchant's store to select a product and call server 6 to have the product's price compared to identical products available at merchant web sites. At step 300, a caller selects a product and captures the Universal Product Code

(UPC). The caller can write the UPC on a piece of paper and then later use a landline telephone (or use a cell phone) to connect to server 6.

At step 310, the caller calls a branded telephone number that directly connects the caller to server 6. To illustrate, the branded telephone number can be a number that is associated with a specific merchant web site. Upon receiving the call, server 6 reads a Dialed Number Identification Service (DNIS), which identifies for server 6, the number that the caller dialed and therefore the service that the caller is requesting. In this case, the caller called the price comparison service telephone number, so the system retrieves the price comparison voice scripts from applications database 180.

At step 320, using speech module 80 as in the FIG. 3 embodiment, voice scripts are played for the caller, which in due course ask the caller to specify a UPC for price comparison information. A typical conversation between the caller and the system might be: Script 1 : "You have reached the UPC price comparison system, please provide a UPC." Caller: "The UPC is 89396 15296." Using speech recognition module 70, server 6 captures the UPC recited by the caller and converts it to a data message. Some users might prefer using DTMF signaling, and as indicated above, module 20 can accommodate DTMF signaling.

At step 340, the system queries UPC database 165 for a UPC that matches the UPC recited by the caller. The database contains tables related to specific UPCs and the tables contain a column of merchant web site URLs, that offer the product for sale, and a column of prices that merchants charge for the product.

Advantageously, the prices should be current. A designer might decide, for example, that if the price of a product is not updated within 48 hours (because no one else queried about that item), then it is flagged as stale. After server 6 locates a matching UPC, it determines whether there are stale entries. If so, server 6 accesses the merchant's web site, and data synchronization module 150 retrieves the current price information of the UPC in question. As mentioned above, module 150 coordinates accessing, searching, and retrieving of information from the merchant web site database. The price is stored in UPC database 165.

At step 360, speech module 80 converts the price to a voice script and presents it to the user in order, from lowest to highest price. Illustratively, Script: "The product identified by UPC 89396 15296 is a video titled Star Wars." "The prices and the merchant web sites offering the product for sale will be listed form lowest price to highest price." "Four dollars and fifty cents at Zellers.com" "Five dollars at Amozon.com" "Five dollars and ninety nine cents at Video.com" At step 370, a voice script is played asking the caller if he or she would like to purchase the video, and from which merchant. If the caller elects not to order the video, and recites the word "no", the system plays a voice script that thanks the caller for using the server and terminates the session by hanging up. If the caller elects to purchase the video and recites the word "yes", then the server engages in a dialog session with the caller in the manner described in connection with FIG. 3, and places the order with the appropriate web-site merchant in step 390.

Another embodiment involves server 6 making an outbound call to a user for the purpose of retrieving information about the user. For example, a merchant may want to contact a group of individuals for the purpose of conducting a survey. In this example, the merchant can access the system and create a series of questions and answers for the system to convert to voice scripts, which can be used for a telephone survey.

The following embodiment is an illustration of an outbound calling process that provides a client, such as a merchant web site, the ability to communicate to the public via the PSTN. Referring to FIG. 2, an outbound calling module 145 is provided to dial an outbound telephone number and retrieve the appropriate voice scripts from application database 180.

FIG. 5 illustrates an outbound calling process in accordance with the principles of the present invention. At step 400, a merchant client accesses server 6 via the Internet. The client uses a standard web browser running on a computer connected to the Internet.

At step 410, the client is prompted by server 6 to provide a script, and the client merchant types in the text of the desired scripts. The text is stored in application database 180 and used, as appropriate, in the outbound calling process. The speech for the outgoing process is created by speech module 80, which in an embodiment where the script is presented in the form of a text string (rather than stored voice), must be a text-to-speech synthesizer.

There are four types of survey answers that the client can choose from when creating a question. The first type of answer is a standard yes/no answer arrangement, the second type is a satisfaction rating answers, the third type is a multiple choice answer, and the forth type is an open-ended answer. After the client creates a question, server 6 automatically ask the client what type of answer will be used with this question. If the client selects the yes/no answer type, then server 6 automatically attaches a yes/no voice script answer to the question. If the client selects the satisfaction rating answer type, then server 6 automatically adds the voice script, "Choose your level of satisfaction based on a scale of 1 to 5", to the question. In the above situations, the client does not have to provide the answers for the questions. If the client selects the multiple choice answer type, then server 6 converts the textual answer choices, provided by the client, to voice script answers. When a survey taker provides an answer to any question having one of the first three answer types, server 6, using speech recognition module 70, converts the spoken answer choice to a data value, which is stored in survey database 195. This information can be tabulated and statistically analyzed for use in marketing research.

If the client selects an open-ended answer type, then server 6 does not provide an answer for the question. Instead, after server 6 plays the voice script question for the survey taker, server 6 captures the survey taker's answer by recording the answer. The answer can be an audio recording or a digital recording (e.g. WAVE).

Additionally, at step 430, the client creates a telephone number database to store the telephone numbers that the client would like server 6 to call for the survey. After the voice scripts for the survey are created and the telephone numbers are gathered, outbound calling module 145 accesses telephone number database 135 for a telephone number, and makes a telephone call via the PSTN, step 420. At step 440, if a person answers the telephone call, server 6 plays voice scripts introducing the survey and plays the survey questions voice scripts. The person who answered the telephone responds by speaking the answers to the survey questions. As mentioned above, this question and answer process utilizes speech recognition module 70 and speech module 80, except in the case of the open-ended answer type questions, where the answers to the questions are recorded. At step 450, server 6 accesses the merchant web site and updates a database at the merchant' web site with the survey results.

Another embodiment of the invention will now be illustrated in connection with FIG. 6. This embodiment provides a telephone auction notification and update bid process for a telephone user and an auction web site. A person who is registered with an auction web site and who has decided to participate in an auction for an item, can receive updates on the auction price, and update the bid price using a telephone. The auction web site and server 6 are configured to send and receive email between each other. The email contains auction information, such as bid price, ask price, last price and is directed to the person who is participating in the auction. The web site and server 6 also share information such as the person's email address (if one is known) and telephone number, so that server 6 and the web site can communicate with the person participating in the auction. During the auction, the auction web site and server 6 exchange email, which contain the name of the bidder, and the current auction status, and any updates in bid price. It should be noted that server 6 and the auction web site can be configured to communicate with each other using other means, such as by file transfer. Referring to FIG. 2, parsing module 185, which is a conventional module that is well known to those skilled in the art, is utilized for this embodiment to remove predefined types of information from incoming email. For example, it can extract a piece of information from an email, such as a name of a person, or other text within the email. Additionally, this embodiment utilizes the outbound calling module 145, which is responsible for outbound dialing.

The auction web site can have a command button that a bidder can select that will initiate the auction notification and update bid process. When the bidder clicks the button, the bidder is hyper-linked to server 6 and is presented with a web page that explains that his or her email address, which was provided to the auction web site during registration, will be changed to an email address associated with server 6. Additionally, the web page provides for the bidder to enter the telephone number that he or she can be reached at during the auction. Server 6 accesses the auction web site and changes the bidder's registration information to reflect the bidder's choice to send auction update status email to server 6. Optionally, the auction web site can change the bidder's registration information so that the auction updates are emailed to server 6. Server 6 also stores the bidders email address and telephone in profile database 100.

During an auction, the auction web and server 6, exchange one or more email. FIG. 6 illustrates an embodiment of a single status notification and single bid update. At step 800, server 6 receives an email from the auction web site. The email may contain the name of the person participating in the auction and the current status of the auction. The status can be, for example, the highest price bid for the item or it can be a statement indicating that the bidder one the auction.

At step 810, parsing module 185 parses the email for the auction status and cross references the email address with the telephone number stored in profile database 100. Using speech recognition module 70, server 6, converts the textual bid information to speech and stores it in a memory associated with the outbound telephone line. Moreover, the bid information is reviewed to determine whether it meets one of four conditions: 1. The bidder has won the auction; 2. The bid has been out-bid and the current high bid is X; 3. The current high bid is the bidder's bid; 4. The bidder lost the auction. Parsing module 185 forwards the auction status and bidder's telephone number to outbound calling module 145.

At step 820, outbound calling module 145 receives the telephone number from parsing module 185 and makes a telephone call via the PSTN. At step 830, the bidder answers the telephone call and server 6 plays a voice script explaining the current status of the auction. Depending upon the condition determined at step 810, one of the four voice scripts will be played to the bidder: If condition one is achieved, then server 6 plays a voice script "You have placed the winning bid." If condition two is achieved, server 6 plays a voice script "You have been out-bid, the current high bid is X dollars. Would you like to increase you bid ?" If condition three is achieved, then server 6 plays a voice script "You currently have the highest bid". If condition four is achieved, then server 6 plays a voice script "The auction is over and you did not win". If at step 830, the bidder is notified that the auction is over, or at step 840, the bidder is given the option to increase a bid and decides not to increase the bid, then the process ends.

If at step 840, the bidder decides to increase a bid, then the bidder can respond by reciting the new bid price into the telephone handset. Speech recognition module 70 captures the recited price and converts it to a data message, step 860. At step 870, the data message is stored as a record of the new bid in the profile database 100. Additionally, speech recognition module 70 captures the spoken response and converts it to text. The text is forwarded to email module 155, which creates an email and send the email and the new bid to the auction web site, step 880.

Claims

Claims:

1. A method carried out in a server comprising the steps of: interacting with a user in voice to receive a purchase request; and placing a purchase order corresponding to said request with a web site via Internet communication.

2. The method of Claim 1 wherein said step of interacting with the user is carried over a telecommunications network.

3. The method of Claim 1 wherein said step of interacting includes a negotiation session between the server and the user.

4. The method of Claim 3 further comprising a step of converting voice to text and converting text to voice as part of said negotiation session.

5. The method of Claim 3 wherein the negotiation session involves accessing database information related to said purchase request.

6. The method of Claim 5 wherein said database information is located at the web site.

7. The method of Claim 5 wherein said database information is located in a database at the server.

8. The method of Claim 1 further comprising the step of said server accessing said web site to obtain information for populating said database at said server.

9. The method of Claim 1 where said server provides to said web site a message, corresponding to said purchase order, which message is formatted in a manner corresponding to messages sent by other users connected to said web site through the Internet when said other users place purchase orders, or to messages derived from purchase orders placed to said web site by said other users.

10. The method of Claim 1 further comprising the steps of sending a response to the user.

11. A method carried out in a server comprising the step of: interacting with a client computer to receive information; and interacting with a user in voice, based on said information over a telecommunication network.

12. The method of claim 11 further comprising the steps of: creating a report from said interaction; and sending said report to said client computer.

13. The method of claim 11 wherein said information is a survey.

14. A method carried out in a server comprising the step of: interacting with a web site by email, said email having information; and interacting with a user in voice to convey said information over a telecommunication network.

15. The method of claim 14 further comprising the step of sending an instruction in voice from said user to said server and from said server to said web site in text.

16. A method carried out in a server comprising the step of: receiving an email having information contained within, from a web site; converting information in said email to voice scripts; and interacting with a user in voice to convey said information over a telecommunication network.

17. The method of claim 16 wherein said information is a price of a product or a service.

18. The method of claim 16 wherein said information is a notification of winning an auction.

19. A server comprising: a communication module for communicating over a telecommunications network and over the Internet; a user interface for negotiating with said user in voice for information, over said telecommunications network; and a memory area for storing a voice script for use in said negotiation with said user.

20. The server of claim 19 further comprising: a posting module for populating an order form for a purchase with at least some of said information from said negotiations and for sending said order form to a web site.

21. The server of claim 19 further comprising: a scraping module for accessing, searching and retrieving web site information from a web site for use in said negotiations.

22. The server of claim 19 wherein the user interface further comprises: a speech recognition module for allowing said user to communicate with said server; and a speech module for allowing said server to communicate with said user.

23. A server comprising: means for communicating with a telecommunications network and the

Internet; means for negotiating with a user in voice to receive one or more information; and means for populating an order form for a purchase with said one or more information, and sending said order form to a web site for fulfillment.

24. A server comprising: a communication module for communicating over a telecommunications network and over the Internet; an email module for receiving an email over said Internet; a parsing module for extracting information from said email; a speech module for converting said information to text; and a user interface for providing said information to a user in voice over said telecommunications network.

25. A server comprising: a communication module for communicating over a telecommunications network and over the Internet; a user interface for receiving information from a user in voice over said telecommunications network, and for converting said information to text; and an email module for sending said information by an email over said Internet to a web site.