WO2001019065A1

WO2001019065A1 - Method, system, and apparatus for interfacing a screen phone with the internet

Info

Publication number: WO2001019065A1
Application number: PCT/US2000/024820
Authority: WO
Inventors: Steve Min-Chou Lin
Original assignee: Global Adsi Solutions, Inc.
Priority date: 1999-09-10
Filing date: 2000-09-08
Publication date: 2001-03-15
Also published as: AU7366300A

Abstract

A method, system, and apparatus are provided for enabling screen phone users to interact with the Internet. A request generated at a screen phone (105) is translated at an intermediary server (125) into a format that is compatible with the Internet server (140), e.g., an HTTP format, and is forwarded to and fulfilled at the Internet server (140). The Internet server (140) returns a response to the intermediary server (125). The response is converted at the intermediary server (125) directly into a format that is compatible with the screen phone (105) and is forwarded to the screen phone (105). Multimedia data may be exchanged between the screen phone (105) and the Internet server (140) via the intermediary server (125). Voice and data are received from the Internet server (140) at the intermediary server (125), the voice is stored at the intermediary server (125), and the data is forwarded to the screen phone (105).

Description

METHOD, SYSTEM, AND APPARATUS FOR INTERFACING A SCREEN PHONE WITH THE INTERNET

BACKGROUND This invention relates generally to a system, apparatus, and method for interfacing the

Internet with hand-held devices. More particularly, this invention relates to a system, apparatus, and method for interfacing the Internet with a screen phone.

The Internet has enabled companies to reach markets which would otherwise not have existed. A vast array of services are offered over the Internet via computer terminals. Examples of such services include home shopping services, general information retrieval services, messaging services and gaming.

Computer terminal users access the Internet using web browsers to read web pages. A web browser is a software program that allows a user to view the data received from an Internet site location. For this purpose, the user provides the web browser with a Uniform Resource Locator (URL) for an object on the Internet, e.g., a data file containing information. This document is referred to as a web page. Web pages often refer to other web pages using hypertext link or hyperlink that includes words or phrases representing the other pages in a format that provides the browser the URL for the corresponding web page. Hyperlinks are made possible by building web pages using a Hypertext Markup Language (HTML) which is used to construct documents in a standardized format. HTML is an ASCII text-based language which defines page formats used to display the HTML elements. Hypertext Transfer Protocol (HTTP) is the most widely used format for accessing and linking users with various other web pages or sites referenced by the original web pages.

When the user selects a site to visit, the URL identifies a location of a web page on a specific host computer on the Internet, referred to as a web server. The web browser retrieves the web page from the web server and displays it for the user.

The web browser sends requests to web servers via an Internet Service Provider (ISP), and the web servers attempt to fulfill these requests with information that is sent to the web browser via the ISP. This interaction is depicted in FIG. 1 which illustrates a web browser running on a computer terminal 100 that communicates with the web server 140 via a Public Switched Telephone Network (PSTN) 110, an ISP 120, and the Internet 130.

There are several ways that user requests may be fulfilled. For example, web servers may translate a request into a search for a file physically stored on the server. Another way in which the web servers may respond is by using a Common Gateway Interface (CGI) or a template-based HTML to obtain dynamic data.

The majority of services that are offered over the Internet using computer terminals can also be offered using screen phones, e.g., Analog Display Service Interface (ADSI) phones. However, while computer terminals and other devices are configured to received HTTP signals and HTML files, the specific display standards for ADSI devices, as well as the display capabilities for ADSI and other screen display telephones, allow only a limited view of HTTP transferred HTML files. In addition, ADSI display characteristics do not permit a user to take advantage of the hypertext features embedded in most HTML data files.

There have been attempts to enable screen phones to communicate with the Internet by converting HTML into a Handheld Device Markup Language (HDML) format, and then converting that format into an ADSI format usable by an ADSI screen phone. This approach is described in U.S. Patents No. 5,930,341; No. 5,923,738; and No. 5,937,041. This approach requires two conversions, which adds to complexity. Also, this approach does not provide for the exchange of multimedia data, e.g., data that includes voice, video, music, etc.

Currently, there is no intermediary server that enables screen phones to communicate with web servers, without requiring conversion between HTML and HDML. Also, there is currently no provision for efficiently exchanging multimedia data between the Internet and screen phones. Thus, users of screen phones cannot take full advantage of Internet services without requiring new equipment.

SUMMARY

It is therefore an object of the invention to enable screen phone users to access the Internet in a simple, inexpensive manner, without requiring new, complicated equipment. It is yet another object of the invention to provide a technique for enabling screen phone users to exchange multimedia data with the Internet in an efficient manner.

In exemplary embodiments, this and other objectives are met by a method, system, and apparatus for interfacing a screen phone with the Internet. The screen phone may be, as just one example, an ADSI phone.

According to one aspect, a request generated at a screen phone is translated at an intermediary server into a format that is compatible with the Internet server, e.g., an HTTP format. The translated request is forwarded to and fulfilled at the Internet server. The Internet server returns a response to the intermediary server, the response including data that can directly be converted into a format that is compatible with the screen phone, e.g., tags embedded in HTML data. The response is converted at the intermediary server directly into a format that is compatible with the screen phone, and the converted response is forwarded to the screen phone.

According to another aspect, multimedia data may be exchanged between the screen phone and the Intemet server via an intermediary server. Voice and data are received from the Internet server at the intermediary server, the voice is stored at the intermediary server, and the data is forwarded to the screen phone.

BRIEF DESCRIPTION OF THE DRAWINGS

The features, objects, and advantages of the invention will become apparent by reading this description in conjunction with the accompanying drawings, in which like reference numerals refer to like elements and in which: FIG. 1 illustrates a conventional Internet interaction;

FIG. 2 illustrates an interaction for a screen phone according to an exemplary embodiment;

FIG. 3 illustrates an exemplary screen for a screen phone:

FIG. 4 illustrates a method for enabling interaction between a screen phone and the Internet according to an exemplary embodiment;

FIG. 5 A illustrates an exemplary path of a Select Request FIG. 5B illustrates an exemplary path of a response to a Select Request; FIGS. 6-8 illustrates exemplary screens displayed in response to various requests made by screen phone users.

DETAILED DESCRIPTION In exemplary embodiments, an intermediary server is provided that enables screen phones to communicate with the Internet. The intermediary server is referred to below as an "E- Z Explorer". FIG. 2 is a high level overview of interaction for a screen phone with the Internet via an

E-Z Explorer. The screen phone 105 communicates with the web server 140 via the PSTN 110, an E-Z Explorer 125, and the Internet 130. The E-Z Explorer may be implemented on a suitable processor, e.g., a GLADSIS-SUNNY System which is available from Applicant's assignee and has full ADSI capability to communicate with ADSI screen phones as well as data network capability to communicate with any Internet servers. The screen phone may be an ADSI terminal or another screen phone device, e.g., a voice over IP phone. The web server 140 may be the same as that shown in FIG. 1.

The screen phone 105 may include a screen, a handset, and a keypad. For each screen of information displayed, there are four basic components: header (including a title, subtitles, and page indicators), body (including the main text), softkeys (including softkeys each having a label and an associated action), and voice prompt (an audio message that provides information about options, provides assistance, plays music, or advertises products and services). Screen phone customers interact with the screen using the speaker, softkeys, keypad, or keyboard. An exemplary screen layout is shown in FIG. 3.

Among other features, the E-Z Explorer is a search engine that allows screen phone users to access existing Internet sites and to interact with existing Internet sites using industry standard protocols. Architecturally, the E-Z Explorer provides both gateway and protocol conversion functions between the Internet sites and screen phones.

Since the standard HTML pages conflict with screen phone capability, a separate set of tags is used to mark pages so that they can be accessed by a screen phone. Therefore, according to an exemplary embodiment, a set of easy, clearly defined, mark up language tags for the Internet pages are provided that are compatible with the E-Z Explorer. These tags may be included in an application hosted by the web server 140. Simple addition of these tags to the standard HTML pages permits screen phones to access existing Internet pages and obtain, e.g., additional voice and music information, controls, and advertising messages. A preferable tag specification is fully compatible, i.e., does not interfere, with existing PC-based Internet browsers, and such a tag specification is set forth in the following publication, "GLADSIS E-Z Explorer™ and GLADSIS EasyWeb Markup Language (EWML) Developer's Guide", release 1.1, Global ADSI Solutions, Inc. (Nov. 30, 1999), which is expressly incorporated here by reference.

This collection of markup tags may be referred to as the Easy Web Markup Language (EWML). The EWML is ignored by standard web browsers when embedded in an HTML page. The EWML convention is similar to HTML, so there is a minimal learning curve involved in development. Standard HTML editor and CGI programming tools can be used to design EWML pages.

The screen phone tags enable multimedia information (e.g., voice and data) to be delivered to screen phones. All tags are enclosed by an <EWML> tag to differentiate them from HTML tags. Under the <EWML> tag, there are other tags that instruct the server how to deliver information to the screen phone. The tags used depend on the

Response. These tags enable inter-active multimedia services to be delivered to consumers via screen phones, using the Internet infrastructure. These tags support all ADSI constructs, such as defining a screen, specifying an input field, programming a softkey, or playing a voice prompt. The syntax of these tags follows a standard tag specification such as that cited above, so that Internet developers can quickly familiarize themselves with the use of these tags.

The E-Z Explorer appears to the Internet server as a standard Internet browser and therefore has no impact on existing Intemet server based Internet support implementations.

The manner in which ADSI screen phone users interact with ADSI applications is quite similar to the manner in which ISP users interact with Internet servers. In the Internet environment, the users are presented with Internet pages. They respond through clicking the mouse and typing on the keyboard. In the ADSI environment, the ADSI screen phone users are presented with ADSI screens along with voice instructions. They respond with DTMF keypad or softkey presses. To mediate the interactions between the ADSI screen phones and the Internet server, the E-Z Explorer translates these key presses into HTTP requests for the Internet server. Similar to a conventional ISP, these requests can be directed towards a tag specification file or the like or an executable program such as a CGI program.

In a typical application session, the ADSI screen phone user accesses the E-Z Explorer through a regular telephone call. Depending on the application the user intends to use, the E-Z Explorer establishes a standard HTTP connection through the TCP/IP network to the corresponding E-Z Explorer-capable Internet server. The E-Z Explorer generates requests to the web server in the same manner that a regular PC-based ISP generates requests.

The E-Z Explorer makes requests to a web site on behalf of screen phones using the HTTP protocol. Each request includes a URL with some default and possible user-specified data. The URL can either point to a file containing static EWML pages or a gateway program that generates dynamic EWML pages. If the URL points to a static EWML page, the data portion of this request would be superfluous, meaningless, and may be omitted by the web server. In response to the requests, the web server processes the user data, including data parsing, invoking business logic programs, communicating with other systems, performing database search, and so on. The result is a response containing a tag specification-like Internet page. The Response is an EWML page that subsequently causes the next request-response cycle. These responses may be statically contained in a file or dynamically generated by a gateway program.

The Internet pages retrieved from the web server are interpreted by the E-Z Explorer and converted into ADSI protocol packets. These packets are then sent to the ADSI screen phone using the ADSI protocol. The interactions between the E-Z Explorer and the web server are all based on existing Internet protocols and therefore require no changes to the web server.

FIG. 4 illustrates a method for interfacing a screen phone with the Internet, according to an exemplary embodiment. The method begins at step 400 at which the screen phone generates a request. At step 410, the E-Z Explorer receives the request and translates the ADSI request into HTTP. At step 420, the HTTP formatted request is sent to the web server. At step 430, the web server prepares a response to the request, including EWML tags embedded within HTML. This response is sent to the E-Z Explorer at step 440. At step 450, the E-Z Explorer receives the response and converts it into an ADSI format for the screen phone. At step 460, the E-Z Explorer forwards the response to the screen phone.

There are various forms of requests that can be used. Each form of request is different in content in that different variable are included along with the request, but all forms of requests expect a new page (response) from the web server.

An example of a request is a Select Request. The Select Request is generated by the E-Z Explorer when the screen phone user presses a softkey or makes a selection using the DTMF keypad. The Select Request user data field contains identification information indicating which softkey or selection the user makes. In addition, the Select Request may contain other identification information, such as current session and screen information.

The E-Z Explorer determines the target URL for the Select Request by determining if there is a Select URL for the softkey, item, or selection and, if so, using that URL. Otherwise, the E-Z Explorer determines if there is a Select URL for the screen, and if so, uses that URL. If there is no Select URL for the softkey, item, selection, or screen, the E-Z Explorer deteπnines if there is Select URL defined in the configuration, and if so, uses that URL. If no Select URL is found, an error is indicated. As an example, FIG. 5 A illustrates a Select Request interaction among a screen phone, an E-Z Explorer, and an Internet server, showing DTMF messaging between the screen phone and the E-Z Explorer and HTTP messaging between the E-Z Explorer and the Internet Server.

Another request supported by the E-Z Explorer is a First Request that is sent by the E-Z Explorer to the web server after a screen phone customer selects a service. To send the First Request, the E-Z Explorer obtain the URL and port identification, either from the user or from a directory maintained by the E-Z Explorer. The First Request may include information identifying the telephone number from which the screen phone is calling.

The E-Z Explorer also supports a Search Request that may be sent when a screen phone customer enters a query and then selects a "Search" softkey. The Search Request may include information identify the softkey as well as information about the current session and screen and the query string entered. The E-Z Explorer determines the target URL for the Search Request by using the URL for the softkey if there is one or, if not, using the URL for the screen. If there is no URL for the softkey or the screen, the E-Z Explorer uses the URL for the configuration. If no URL is found, an error is indicated.

In addition, the E-Z Explorer supports a Store Request that is sent after a screen phone customer leaves a "User Input" screen before submitting any values they many have entered. The current values are stored to relieve the screen phone customer of re-entering them. The Store Request includes information regarding the screen and the current session as well as information indicating the current values for input lines.

To determine the Store URL, the E-Z Explorer determines if there is a Store URL for the screen or, if not, determines if there is a Store URL for the configuration. If there is no Store URL for the screen or configuration, the values to be stored are discarded.

A Retrieve Request is sent after a screen phone user returns to the "User Input" screen. Previously entered values stored via the Store Request are retrieved. The Retrieve Request includes information about the current session and screen. To find the Retrieve URL, the E-Z Explorer detemiines if there is a Retrieve URL for the screen, and if not, determines if there is a Retrieve URL for the configuration. If there is no Retrieve URL, previously entered values are not retrieved. A Submit Request is sent when all required values have been supplied, and either the screen phone customer selects a "Submit" softkey on a confirm screen or there is no confirm screen. The Submit Request includes information regarding the current session and the screen as well as values for input lines. To find the Submit URL, the E-Z Explorer determines if there is a Submit URL for the screen, and if not, if there is one of the configuration. If there is no Submit URL for the screen or configuration, an error is indicated.

There are also a number of different responses to such requests that may be made by the Internet Server. FIG. 5B illustrates a response interaction among a screen phone, an E-Z

Explorer, and an Intemet server, showing EWML-tagged pages sent by the Internet server to the E-Z Explorer and ADSI-formatted messages or audio prompts sent by the E-Z Explorer to the screen phone.

An example of a response is a Display Screen Response that directs the E-Z Explorer to display a screen. Since the Display Screen Response is frequently used, it is described in detail here. There are common elements or "tags" that are frequently used in a Display Screen Response. These elements advantageously include an <EWML> element, an <AUDIO> element, a <SCREEN> element, and a <SOFTKEYS> element.

The <EWML> element is used for all web server response. The contents of the </EWML> element varies, depending for example on whether the Display Screen Response is the first Display Screen Response in a transaction or a subsequent Display Screen Response.

The <AUDIO> element corresponds to a voice port that E-Z Explorer is to play back to the screen phone. The <AUDIO> element contains one or more <VF> elements, each <VT element corresponding to an audio, e.g., voice, file. Multiple voice prompts segments can be concatenated by specifying numbers of voice prompt files via the <VF> elements.

The <SCREEN> element appears inside the <EWML> element of the Display Screen Response. The <SCREEN> element may have three variations: Information Display, Item Selection, or User Input. Each <SCREEN> element includes a label which may distinguish the screen from which a request originates. The <SCREEN> element also specifies the screen URLs for Select, Search, Submit, Store, and Retrieve, the screen title, and screen sub-titles.

The <SOFTKEY> element corresponds to a set of screen softkeys and may contain, for example, up to six <SK> elements. Each <SK> element corresponds to a soft key and specifies the position of the softkey and the type (e.g., "Back", "Dial", "Enter", "Exit", "Go Up or Cancel", "Help", "Line Select", "Main Screen", "Modify", "Next Page", "Null", "Previous Page", "Search", "Softkey Select", or "Submit"). An <SK> element may also specify information depending on the softkey, e.g., the labels for the "Dial", "Search", and "Softkey Select" softkeys, the identity for "Search" and "Softkey Select" softkeys, the Select URL for "Softkey Select" softkeys, the Search URL for "Search" softkey, and the telephone number for "Dial" softkeys.

In addition to these elements, other elements may be used in a Response, depending on the type of Display Screen Response. For example, a Display Screen Response in response to a First Request preferably has the following EWML syntax: <EWML> <CONFIG> element <SCREEN> element </EWML> The <CONFIG> element contains configuration information regarding the current session, time out and error parameters, standard voice files, service URLS or Select, Search, Submit, Store, and Retrieve requests, and labels for softkeys.

A subsequent Display Screen Response, e.g., in response to the Select, Search or Submit Request, may direct the E-Z Explorer to play a non-interruptible voice prompt prior to displaying the screen. This has the following syntax: <EWML

[SMOD=LOAD RELOAD INTERMEDIATE] >

[<AUDIO> ELEMENT] <SCREEN> ELEMENT </EWML>

The <AUDIO> element directs the E-Z Explorer to play the specified audio, e.g., voice or music, files, uninterrupted, prior to displaying the screen.

The different types of <SCREEN> elements also have different syntaxes. For example, for an Information Display Screen, the <SCREEN> element may have the following syntax: <SCREEN

LABEL= "label"

[SELECT= "URL"]

[SEARCH= "URL"] [SUBMIT= "URL"]

[STORE= "URL"]

[RETRIEVE= "URL"] [TITLE= "title"] [SUBTITLE= "subtitle"] >

[<INFODISPLAY> element] [<SOFTKEYS> element] [<AUDIO> element} <\SCREEN>

The <INFODISPLAY> element describes the screen body and contains one or more <INFO> element. Each <INFO> element corresponds to a new line, a heading, a paragraph, a bullet, or a selection. The "SOFTKEY: and <AUDIO> elements are optional.

An exemplary information Display Screen is depicted in FIG. 6. The screen phone user interacts with an Information Display Screen by pressing a softkey or entering selection number on the keypad.

For an Item Select Screen, the <SCREEN> element has the following syntax: <SCREEN

LABEL= "label" [SELECT= "URL"] [SEARCH= "URL"] [SUBMIT= "URL"] [STORE= "URL"]

[RETRIEVE^ "URL"] [TITLE= "title"] [SUBTITLE= "subtitle"] > <ITEMSELECT> element [<SOFTKEYS> element] [<AUDIO> element] <\SCREEN>

The <ITEMSELECT> element distinguishes an Item Select Screen and describes the screen body. The <ITEMSELECT> element contain one or more <ITEM> elements, each <ITEM> element corresponding to an item. The <SOFTKEYS> and <AUDIO> elements are optional. The screen phone user interacts with the Item Selection Screen depicted in FIG. 7 by pressing a softkey or entering an item number on the keypad.

For User Input, the <SCREEN> element has the following syntax: <SCREEN

LABEL= "label" [SELECT= "URL"]

[SEARCH= "URL"]

[SUBMIT= "URL"]

[STORE= "URL"]

[RETRIEVE= "URL"] [TITLE= "title"]

[SUBTITLE= "subtitle"] >

<USERINPUT> element [<SOFTKEYS> element] [<CONFIRM> element] <\SCREEN>

The <USERINPUT> element distinguishes a User Input Screen and describes the screen body. The <USERINPUT> element contains one or more <ENTRY> elements, each <ENTRY> element corresponding to a text line. <SOFTKEYS> and <AUDIO> elements are optional input lines.

The <CONF_RM> element describes the softkey an voice prompt for the optional confirm screen following the USER INPUT screen. The <CONF_RM> element may also optionally contain a <SOFTKEYS> element and a <AUDIO> element.

An exemplary User Input Screen is shown in FIG. 8. Below is a simple example of an E-Z Explorer page used to display an information screen with a number of softkeys and a voice prompt: <EWML SMOD=LOAD> <!— Beginning of an ADSI screen — > <SCREEN

LABEL= "MAIN"

<!-- Title and subtitle for the screen — > TITLE = "Welcome to CD-Online.com" SUBTITLE^ "***CD shopping is never easier***" <!-- Beginning of body of the screen which contains one or more information lines — > <ΓNFODISPLAY>

<INFO>

</INFODISPLAY> <!-- Defining softkeys for the screen — >

</ SOFTKEYS >

<!— Defining voice instructions for the screen — >

</VOICE>

</SCREEN>

<! — End of screen -->

</EWML>

When this page is received by the E-Z Explorer, it is converted into appropriate ADSI protocol packets for the screen phone, and the following screen appears at the screen phone: Welcome to CD-Online.com ***CD shopping is never easier***

Order now and save 25%

Join our CD club now and save even more!

Back Explore Main Screen Customer Service

The voice file "main.wav" is played at the screen phone right after the screen appears. If the user presses the "Explore" softkey, the E-Z Explorer is triggered to send a Request to the Internet server with the appropriate identifier for identifying the "Explore" softkey. This completes a cycle of interaction. A typical application session may includes many of these types of cycles. In addition to the Display Screen Response, other responses advantageously include a

Play Voice Response that directs the E-Z Explorer to play a voice prompt without updating the screen. A Link to Another Service Response redirects the E-Z Explorer to connect to another EWML page or web site. A No Operation Response directs the E-Z Explorer to do nothing, e.g., in response to a Store Request. A Values Response directs the E-Z Explorer to update specific values with current values, e.g., in response to a Retrieve Request. An Error Response indicates that an error has occurred, the type of error determining the action the E-Z Explorer should take.

Current web services are not efficient for voice delivery since most consumers have relatively slow connections (e.g., 56Kbps). Voice files are usually large, and downloading large voice files via a 56K connection is a time-consuming process. For screen phones, there is no storage to download those files even though it is a slow process.

To overcome the above inefficiency, according to another aspect of the invention, the communication channel between the screen phone and the server may be divided into voice and data. The data portion is delivered to the screen phone for displaying information. The voice portion is stored in the server. Web content providers may use the <VF> tag described above to specify particular voice files to be played to the consumers. A server may then use the Internet FTP protocol to retrieve the files. These files can then be stored and cached in the server for future reference.

For traditional web access, the ISPs are transport service providers. All information retrieved from the web contents providers are delivered to the consumers. This invention keeps the voice component of the contents in the server so that it can be more efficiently managed.

The E-Z Explorer enables rapid development and deployment of ADSI screen phone applications by building on the existing infrastructure of the Internet and Internet sites. This provides advantages in time to market, entry costs, and resource sharing.

By using an approach comparable to the existing Internet technologies, such as tag specification-like tags, the invention provides a development methodology that most Internet developers are familiar with and therefore drastically shortens the learning curve and reduces time to market. In addition, the E-Z Explorer handles proper construction of the ADSI screens and softkeys and therefore saves Internet developers from the complexity of the ADSI protocol. Also, to enable an Internet site to support ADSI applications, there is no additional hardware, software, or technologies to invest in, except the inclusion/addition of the E-Z

Explorer tag specification-like tags. All currently deployed systems and technologies, such as databases, back-end systems, back-end system interface software, business logic software, search engines, and so on, can be fully reused without any modifications.

Traditional computer telephony deployment requires investment in front-end server hardware and software along with investment in the telecommunication infrastructure. This further represents long-term maintenance and operations issues. With E-Z Explorer technology, applications are separated from front-end ADSI servers and therefore resource sharing is enabled. Companies which operate Internet sites, either by themselves or through third-party Internet hosting companies, can continue to do so while offering ADSI applications through a centralized call center. This represents the quickest path to market and creates tremendous cost savings through resource sharing and economy of scale. This is particularly beneficial to companies which operate multiple application sites and small companies which cannot afford or do not want to operate their own front-end ADSI servers.

It will be appreciated by those of ordinary skill in the art that this invention can be embodied in other specific forms without departing from its essential character. The embodiments described above should therefore be considered in all respects to be illustrative and not restrictive.

Claims

I CLAIM:

1. A method for enabling communication between a screen phone and the Internet, the method comprising: generating a request at a screen phone; translating the request at an intermediary server into a format that is compatible with the Internet server; forwarding the translated request to the Internet server; fulfilling the request at the Internet server; returning a response to the intermediary serve, the response including data that can directly be converted into a format that is compatible with the screen phone; converting the response at the intermediary server directly into a format that is compatible with the screen phone; and forwarding the converted response to the screen phone.

2. The method of claim 1, wherein the screen phone is an ADSI phone.

3. The method of claim 1 , wherein the language used to communicate between the intermediary server and the screen display phone includes tags embedded in HTML.

4. The method of claim 1 , wherein the intermediary server is incorporated into an HTTP server.

5. The method of claim 1 , wherein the system permits multimedia data to be exchanged between the screen display phone and the Internet server via the intermediary server.

6. The method of claim 5, wherein the data includes voice data.

7. The method of claim 5, wherein the voice data is stored in the intermediary server.

8. A method for enabling exchange of multimedia data between a screen phone and an Internet server, the method comprising: receiving voice and data from an Intemet server at an intermediary server; storing the voice at the intermediary server; and forwarding the data to the screen phone.

9. The method of claim 8, wherein the screen phone is an ADSI phone.

10. The method of claim 8, wherein the language used to communicate between the intermediary server and the screen display phone includes tags embedded in HTML.

11. The method of claim 8, wherein the intermediary server is incorporated into an HTTP server.

12. The method of claim 8, wherein the voice and data are provided from the Internet server in a format that can be directly converted into a format recognizable by the screen phone, the method further comprising converting the voice and data received at the intermediary server into a format recognizable by the screen phone.

13. A communication system, comprising: a screen display phone for generating requests and receiving responses; an Internet server for receiving requests and generating responses; and an intermediary server for interfacing the screen display phone with the Internet server, wherein the Internet server translates a request from the screen display phone into a format that is recognizable by the Internet server and forward the translated request to the Internet server, and the Internet server returns a response to the intermediary server including data that can directly be converted into a format that is recognizable by the screen phone, and the intermediary server converts the response into a format that is recognizable by the screen phone and forward the converted response to the screen phone.

14. The system of claim 13, wherein the screen phone is an ADSI phone.

15. The system of claim 13, wherein the language used to communicate between the intermediary server and the screen display phone includes tags embedded in HTML.

16. The system of claim 13, wherein the intermediary server is incorporated into an HTTP server.

17. The system of claim 13, wherein the system permits multimedia data to be exchanged between the screen display phone and the Internet server via the intermediary server.

18. The communication system of claim 17, wherein the data includes voice data.

19. The communication system of claim 17, wherein the voice data is stored in the intermediary server.

20. A communication system, comprising: a screen display phone for receiving responses; an Internet server for receiving requests for data from the screen display phone and generating responses including voice and data; and an intermediary server for receiving voice and data from the Internet server, storing the voice, and forwarding the data to the screen phone.

21. The system of claim 20, wherein the screen phone is an ADSI phone.

22. The system of claim 20, wherein the language used to communicate between the intermediary server and the screen display phone includes tags embedded in HTML.

23. The system of claim 20, wherein the intermediary server is incorporated into an HTTP server.

24. The system of claim 20, wherein the voice and data are provided from the

Internet server in a format that can be directly converted into a format recognizable by the screen phone, the method further comprising converting the voice and data received at the intermediary server into a format recognizable by the screen phone.

25. An apparatus for interfacing the Internet with a screen phone, the apparatus comprising: means for receiving a request form the screen display phone: means for translating the request received from the screen display phone into a format that is recognizable by the Internet server; means for forwarding the translated request to the Intemet server; means for receiving response from the Internet server; means for converting a response from the Internet server directly into a format that is recognizable by the screen phone; and means for forwarding the converted response to the screen phone.

26. The apparatus of claim 25, wherein the screen phone is an ADSI phone.

27. The apparatus of claim 25, wherein the language used to communicate between the intermediary server and the screen display phone includes tags embedded in HTML.

28. The apparatus of claim 25, wherein the intermediary server is incorporated into an HTTP server.

29. The apparatus of claim 25, wherein the system permits multimedia data to be exchanged between the screen display phone and the Internet server via the intermediary server.

30. The apparatus of claim 25, wherein the data includes voice.

31. The apparatus of claim 30, further comprising means for storing the voice.

32. An apparatus for interfacing the Internet with a screen phone, the apparatus comprising: means for receiving voice and data from the Internet server; means for storing the voice; and means for forwarding the data to the screen phone.

33. The apparatus of claim 32, wherein the screen phone is an ADSI phone.

34. The apparatus of claim 32, wherein the language used to communicate between the intermediary server and the screen display phone includes tags embedded in HTML.

35. The apparatus of claim 32, wherein the intermediary server is incorporated into an HTTP server.

36. The apparatus of claim 32, wherein the voice and data are provided from the Internet server in a format that can be directly converted into a format recognizable by the screen phone, the method further comprising converting the voice and data received at the intermediary server into a format recognizable by the screen phone.