WO1999053670A2

WO1999053670A2 - A proprietary information system and various methods of use connected therewith

Info

Publication number: WO1999053670A2
Application number: PCT/US1999/007917
Authority: WO
Inventors: Richard Leggitt; James Abenschan; Steve Landry
Original assignee: Landel Technology, Inc.
Priority date: 1998-04-10
Filing date: 1999-04-09
Publication date: 1999-10-21
Also published as: EP1058887A2; AU3553999A; WO1999053670A3

Abstract

Disclosed herein is an information system having a server (12) and a pluralities of terminal units (14). Each of the terminal units (14) and the server (12) include software having a proprietary protocol. The terminal units (14) initiate contact with the server through normal telephone channels such as public switch telephone network. Once contacted the server (12) and terminal units (14) exchange proprietary protocol and establish an on line session. The server (12) obtains the electronic mail for the particular terminal unit (14), downloads the mail to the particular terminal unit (14) and then upload any electronic mail that the terminal unit (14) wants to send. Offline the terminal unit (14) is used to read, create, edit and delete email. The server unit (12) calls external servers for services including electronic mail.

Description

A Proprietary Information System and Various Methods

Of Use Connected Therewith

Field of the Invention

This invention relates to an information system for obtaining electronic mail (email) as well other information through the use of a server from a terminal unit. More particularly the information system in accordance with this invention relates to a low cost terminal unit connected to a proprietary network having a proprietary server.

Background of the Invention

As use of the Internet and general electronic mail services has become more popular, there has developed a strong need to make such services available to those neither technically skilled with the use of a computer nor those having the financial resources to own even a modest personal computer system. As a result, the marketplace has become inundated with many new devices claiming to provide low- cost, user-friendly access to the Internet.

For example, one company has marketed a telephone device known as an "iPhone" which has built-in features such as caller ID, a auto-dialable personal directory, a keyboard, and a World Wide Web browser.

Another device, known as the Intelliphone has the ability to send and receive email, but is restricted to a small 3-line by 20-column display. Such a small screen, combined with a miniaturized keyboard make ordinary email messages quite difficult to both read and compose. Yet another device known as "Easy Mail" offers similar email capabilities, but suffers the same limitations as the previous examples.

All of these devices mentioned are either too expensive for some consumers, or, due to the screen and keyboard size, are too difficult to use for email on a regular basis.

Critical in all such devices is that the user device be low cost. In order to accomplish this objective, the email device must be designed as a "thin client". In client/server architecture, a server computer communicates through a network with multiple client devices. A "thin" client is distinguished from a regular client in that much of the capability of the regular client is removed from the thin client and is instead located at the server. For instance, a regular client may be able to both create and display a complicated image, whereas a thin client would rely upon a server to create the same image before sending it to the thin client for display. The concept of "thin client" is a relative term. A thin client, as used herein, is a device, which used to perform activities associated with composing, sending, receiving, and viewing email messages.

While many consumer email devices attempt to be a thin clients, such devices are optimized for Internet compatibility instead of cost.

Additionally, a consumer email device should be easy to use. This suggests a display that permits comfortable viewing of standard, email-format messages, as well as a keyboard, which allows comfortable message composition.

What is needed is a consumer email appliance, which is low cost and capable of efficiently and effectively handling the sending and receiving of email.

Summary of the Invention It is an object of this invention to provide a proprietary information system including a server and a plurality of terminal units wherein each of the server and terminal units communicates through a proprietary protocol.

It is an additional object of this invention to provide such an information system wherein the server does most of the work involved in receiving and sending information and the terminal unit is a "thin client" consumer appliance designed for the primary purpose of sending and receiving email.

It is an additional object of this invention to provide a terminal unit which is low cost and which serves effectively and efficiently to receive and send emails.

In accordance with the above objects and those that will be mentioned and will become apparent below, the proprietary information system in accordance with this invention comprises: a server unit including: a communication section having the ability to perform two-way communications with the terminal unit(s); software for supporting the proprietary protocol and for sending and receiving email; at least one terminal unit compatible of communication with the server unit including; a communication section having the ability to perform two-way communications with a server unit, including uploading and downloading email messages; a user interface; and a memory section for storing messages to and from the server unit, whereby, at least one terminal unit and the server unit are capable of two-way communications and storing and transmitting email messages.

The consumer premises equipment (CPE) known herein as a terminal unit is a thin client, meaning that the CPE does not need to be a Pentium or any sort of high powered computer. Rather the customer's equipment includes relatively ordinary technology. For example, the CPE of the invention includes a 2400 baud modem, clearly not among the forefront of today's high technology range; nor a fast or high powered CPU such as a 486, Pentium or the like. In fact the CPE processor is a SIEMENS C151 16-bit microprocessor. Thus, the terminal unit, because it relies upon a connectable network server (the LSP server) to do most of the work in sending and receiving emails, need only have moderate or even low intelligence and speed (16-bit processor and 2400 baud modem).

In another alternative embodiment, the informational system in accordance with this invention, comprises: a server unit including: communications section having the ability to perform two-way communications with a terminal unit; software for supporting the proprietary protocol and for sending and receiving email; the server unit being integrated with an independent remote server, the independent remote server being capable of two communication with various information net works for allowing the terminal unit(s) to communicate outside of the information system through the server unit; a terminal unit including: a communication section having the ability to perform two-way communication with the server unit upon the initiation by either the terminal unit or the server unit; a user interface; a memory section for storing messages to and from the server unit, and whereby, at least one terminal unit and the server unit are capable of two-way communications and each unit is capable of storing inputted and outputted messages and whereby the terminal unit can communicate both within the information system and to information net works outside the information system.

In this embodiment, the server is integrated with an independent remote server, such as an ISP server. Thus, actual telephone connection is made not directly with the LSP server, but with the ISP communications device or router, which then sends the communication with the terminal unit or CPE to the LSP server.

In another exemplary embodiment, the information system in accordance with this invention, comprises: a server unit including: a communication section having the ability to perform two-way communication with a terminal unit; software for supporting the proprietary protocol and for sending and receiving email; an independent server, the server unit being in communication with the independent server, the independent server being capable of communication with various information net works for allowing the terminal units to communicate outside the information system through the server unit; a terminal unit including: a communication section having the ability to perform two-way communication with a server unit upon the initiation by either the terminal unit or the server unit; a user interface; a memory section for storing messages to and from the server unit, and whereby, at least one terminal unit and the server unit are capable of two-way communications and storing inputted and outputted messages and whereby, the terminal unit can communicate both within the information system and to information net works outside the information system. In this exemplary embodiment, the LSP server is remote from the ISP server and requires a network connection with the ISP server after the CPE has contacted the ISP server.

It is an advantage of the information system in accordance with this invention to be simple to retrieve and send email messages while be cost effective and an efficient household appliance.

Brief Description of the Drawing

For a further understanding of the objects and advantages of the present invention, reference should be had to the following detailed description, taken in conjunction with the accompanying drawing, in which like parts are given like reference numerals and wherein: Fig. 1 is a schematic view of the proprietary information system in accordance with this invention.

Figs. 2 & 3 represent schematic views of alternative embodiments of the proprietary information system in accordance with this invention.

Fig. 4 is a perspective view of a representative user interface in accordance with this invention, including a keyboard and display screen.

Figs. 5 & 5A are schematic representations of a flow chart illustrating an LSP session.

Fig. 6 is a schematic representation of a flow chart illustrating a Registration session. Fig. 7 is a schematic representation of a flow chart illustrating a External session.

Fig. 8 is a schematic representation of a flow chart illustrating an "In-Band" LMCP command session.

Fig. 9 is a schematic representation of the top most level of the LSP software.

Fig.10 s a schematic representation illustrating the Messages subroutine, Fig.11 s a schematic representation of the Read Selection subroutine, Fig.12 s a schematic representation of the Edit Message subroutine, Fig.13 s a schematic representation of the Address Book subroutine, Fig.14 s a schematic representation of the Edit Address subroutine, Fig.15 s a schematic representation of the Phone Book subroutine, Fig.16 s a schematic representation of the Edit Phone Book subroutine, Fig.17 s a schematic representation of the Call subroutine, Fig.18 s a schematic representation of the Caller ID subroutine. Detailed Description of the Invention

The proprietary information system in accordance with this invention transmits and receives email, including Internet email. The Information System (IS) uses a proprietary server (Landel Session Protocol (LSP) server) and a plurality of terminal units, also known as "Customer Premises Equipment" (CPE) or herein as a terminal unit. Through the LSP server, the CPE can send and retrieve email, not only within the proprietary system, but also over the Internet. In fact, as will be fully appreciated below, the delivery and sending of email whether through the proprietary information system of the invention or directly with the Internet is invisible to any particular CPE or terminal unit. The LSP server is a proprietary computer, which includes software to exclude non-system users from the proprietary information system of this invention. Each system user or CPE, includes a CIF file, a set of instructions and information exchanged between the CPE and the LSP server which establishes the CPE as having valid rights on the proprietary information system in accordance with this invention. If the caller attempting to connect with the LSP server does not conform to the proprietary requirements, no connection will be established between the caller's terminal unit and the LSP server.

The "CIF" or CPE Information File contains information necessary to establish the communication link between the caller and the LSP server. A valid caller or CPE transmits the CIF file to the LSP server. The CIF file contains the user's email address, email account and password, and the server telephone number. Additionally, the CIF contains dynamic information (such as alternate mailboxes from which email can be retrieved).

The user has indirect access only to specific portions of the CIF, in particular, the user can modify the server phone number at will. However, the remainder of the CIF contains other information, which is not modifiable by the user. For example, the CIF information file contains information required for connection to the information system. Without such information there would be no connection between the LSP server and the terminal unit or any remote external server.

Additionally, the virtual rights of the terminal unit are set forth in the CIF information file as defined by the email password. These virtual rights allow the LSP server to determine if a terminal unit is authorized to access resources such as email or external information systems such as Dialog or the Stock Exchange. Additionally, other information sources are contemplated within the spirit and scope of this invention.

These virtual rights are identified in the CIF information file and tell the LSP server the rights of a particular terminal unit.

In one embodiment (Fig. 1), the LSP server is a stand-alone computer having modem connection to the terminal unit and other external servers. In a second embodiment (Fig. 2), the Internet Service Provider (ISP) includes an LSP server module as part of it's ethemet. In this embodiment (Fig. 2), the LSP server is actually part of the ISP's equipment and the terminal unit is like any other caller calling into the ISP except for the special protocol (LSP) associated with the terminal unit. In a third embodiment (Fig. 3), the LSP server is remote from the ISP and although the terminal unit cannot tell the difference, the terminal unit calls are routed to the LSP server through the ISP router.

As will be explained more fully with respect to Figure 4, the user interface includes a keyboard and a display. The user interface in an exemplary embodiment includes an ability to dial telephone numbers as well as use the terminal unit for email communication.

With particular reference to Fig. 1 , there is shown the information system generally designated by the numeral 10 in accordance with this invention. The

Information System 10 (IS) is a proprietary information system meaning that it is closed to those not within the system. The information system 10 includes at least one server unit designated by the numeral 12 and a plurality of terminal units, better known as terminal units, and designated by the numeral 14 As described above, the information system 10 is proprietary or closed because terminal units outside the information system 10 can not communicate with the LSP server 12 or directly with the terminal units 14. A special set of instructions and information is exchanged during the handshake between the LSP server 12 and the terminal unit 14. If the set of instructions and information exchanged does not conform to the proprietary requirements, no connection will be established between the terminal unit and the LSP server 12. This special sequence of information defines the CIF file.

Each of the terminal units 14 connects with the LSP server 12 over the public switched telephone network (PSTN). This switching network provides a low cost means of connection while using the lines previously established and known for their reliability. The use of existing PSTN equipment allows low cost connection as well as use of standard components in the terminal unit 14.

Upon connection to the LSP server 12 and correct validation with the IS 10, the LSP server 12 connects through the Internet to a POP (Post Office Protocol) server, (as defined by ITEF document RFC1939, which is specifically incorporated herein by reference) retrieves the user's email from the POP server, formats the message in such a way that it is easily viewed by the terminal unit, and downloads it to the terminal unit.

After the new mail has been downloaded to the terminal unit 14, the upload process begins. Any outbound email messages are uploaded to the LSP server and transmitted to the email SMTP server as shown in Fig. 1. Simple Mail Transport Protocol is defined by ITEF document RFC821 , which is specifically incorporated herein by reference.

The LSP server 12 is capable of two-way communication between the terminal unit 14 and the LSP server 12. The LSP server 12 includes a communication section (not shown). The communication section establishes and maintains the two-way communication between the LSP server 12 and the terminal unit 14. The LSP server 12 includes a capability for downloading a text message and displaying that text message on the the terminal unit "IDLE" screen. The display of text message may include text of any kind including advertising.

The operation of the LSP server 12 and its communication with the terminal unit 14 is described more fully below with respect to Figs. 5 - 8.

Each terminal unit 14 includes a communication section for two-way communication between the LSP 12 and the terminal unit 14. Each terminal unit 14 additionally includes a memory section and a user interface. In an exemplary embodiment, the user interface includes a screen and a keyboard as described more fully below with respect to Fig. 4.

The memory section is used for storing messages to and from the terminal unit 14. Additionally, the memory section is used for storing an address book, a phone book, caller ID records and various kinds of mail. The address book includes email addresses and names, which are popular with the user. It will be appreciated that email addresses and names can be edited, deleted, or added at the user's discretion.

Additionally, a phone book can be created and placed in the memory section. The phone book contains names and telephone numbers for repeditory dialing. For example, the terminal unit 14 can be used to dial telephone to telephone connections instead of merely using email.

Various categories of mail may also be stored in the memory section. Mail that has been created but not yet transmitted, (out-bound mail); mail that has been created and transmitted, (sent mail); and mail that has been received but not yet read, (new); mail that has been received and read, (read); and mail that has been created and saved without sending, (saved). The memory section thereby is used for mail that in any way relates to the particular terminal unit 14.

The terminal units 14 communicate with the LSP server via the LSP software protocol over the PSTN. The LSP server 12 communicates with the Internet 16 through Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), and the telnet protocol (as defined by ITEF document RFC732, which is specifically incorporated herein by reference) depending on the operation being performed. When outgoing mail is to be sent across the Internet, it is relayed through a SMTP server. When incoming mail is being retrieved from across the Internet, it is retrieved from a POP server. The "on-line" sessions to and from External servers over the Internet 16, (either the Registration or the Information Services server) occurs through the telnet protocol with the embedded Landel Mailbug Configuration Protocol (LMCP), as will be described in more detail below.

While other systems are useful, in an exemplary embodiment, the terminal unit 14, alone, initiates the communication with the LSP server 12.

With respect to Fig. 2, there is shown an alternative exemplary embodiment of the proprietary information system in accordance with this invention and designated by the numeral 20. The IS 20 includes terminal unit 14 which connects with an LSP module 22. The LSP module 22 serves the same purpose as the LSP server 12. However, as shown in Fig. 2, the LSP module 22 is integrated as part of the ISP's Ethernet. The terminal unit, upon dialing and connecting to an ISP through the PSTN, will send a sequence of commands designed to connect it to an LSP server. It will execute these commands until it has made contact. (This is commonly referred to as a "Chat Script")

Once at the LSP module 22, the caller is identified in exactly the same manner as described above with respect to Fig. 1. The terminal unit 14 sends through its CIF file and the CIF file is verified by the LSP module 22. Once the CIF has been validated, the email is downloaded and uploaded in precisely the same manner as that described above with respect to Fig. 1.

With particular reference to Fig. 3, there is shown a third exemplary embodiment of the proprietary information system (IS) in accordance with this invention designated generally designated by the numeral 30. As described above with respect to Figs. 1 and 2, the IS 30 includes a plurality of terminal units 14 which connect to the ISP 16 through the PSTN. In this embodiment, IS 30, the LSP server 12 is located remote from the ISP 16. When a terminal unit 12 calls in, the ISP 16 routes the call directly to the LSP server 12 through the ISP Ethernet.

Upon connection to the LSP server 12, the terminal unit's CIF file is transferred to the LSP server 12 for verification. In the same way as described above, the caller, terminal unit 14 is verified as a valid user. The email is then downloaded and uploaded in the manner described above in connection with the earlier described embodiments. It will be appreciated that the two-way communication with the LSP server 12 and the ISP router are facilitated over a T-1 line. Of course, other line facilitations are equally possible within the spirit and scope of the invention. For example, the LSP server might reside on the same LAN as the ISP, or multiple LSP servers might be installed in various locations throughout the ISP's coverage area.

With particular reference to Fig 4, there is shown the terminal unit 14 including a user interface 40. The terminal unit user interface 40 includes a keyboard 42 and a display screen 44. Additionally, there are eight keys across the user interface 40 just below the display screen 44 which define soft keys 46. The soft keys 46 operate the primary method to obtain and send email and for other functions as will become apparent from the description below. For example, if the user wants to obtain his new emails, he will press the soft key designated as CONNECT.

As is apparent from Fig. 4, the keyboard 42 is a keyboard having full size keys. Additionally, it is contemplated within the spirit and scope of this invention that a voice activated input device may be used with the terminal unit 14 either replacing or as a compliment to the keyboard.

The keyboard 42 is a QWERTY keyboard with typical cursor control and editing keys. The cursor control may include a centrally located mouse (not shown) or other pointing device. Other variations of the keyboard 42 are well known and are contemplated within the spirit and scope of this invention.

The display screen 44 includes six lines of text display and two lines dedicated for status display. For example, if the terminal unit 14 is on-line, the elapsed time for the session is displayed. Also displayed are whether or not the terminal unit 14 is online or off-line as well as various other status conditions set forth below with respect to Figs. 9 - 18.

The display screen is a full 79 column text display. This enables the entire email message to be shown on the display screen 44. This is a departure from many other inexpensive "thin client" devices, which operate as nothing more than a mere novelties. By using a screen, which can not conform to the format of Internet email, such novelty devices cause the email message to be truncated and/or to be unreadable. Thus, email devices having less than a full screen are rendered relatively useless. The display screen 42 in accordance with this invention represents a leap forward in "thin client" devices for the use of email.

The display screen 44 has 8 lines. The top line is reserved for time and other status display. The middle six lines are used for display of text, for example the email message itself. The bottom line is reserved for soft key labels. As will be appreciated, depending upon which software subroutine is running, the softkey labels will be different. The active software subroutine controls the function and labels of the soft keys.

The terminal unit 14 includes an imbedded microprocessor, such as a SIEMENS C151 16-bit microprocessor. The SIEMENS C151 microprocessor, when used in conjunction with the proprietary software and at least one memory device holds at least 100 electronic messages. This gives the terminal unit 14 moderate intelligence and controls the affordability of the unit. Thus, the terminal unit 14 operates as a "thin client" while performing effectively all of the functions of the terminal unit 14, as stated herein.

The terminal unit 14 includes a 2400 baud V.22bis modem. This is a relatively slow speed and low cost modem, which enables the entire cost of the terminal unit to be quite low. The terminal unit 14 includes a flash memory for data storage. The flash memory includes the CIF file, as well as other files including the local information file (LIF), which contains parametric information includes local customization options (such as whether email messages will be "quoted" when they are replied to.) Other files stored in flash memory include the address book; the phone book, the CIF file; the LIF; Caller ID record; and individual email.

In order to connect to a server, the LMCP requires information that each and every user must enter exactly correctly in order to be logged on to the proprietary network. This information must be stored on the user's CPE for repeated usage. In one embodiment a single copy of this information is stored by the registration server into the CPE's memory using LMCP and is used in order to connect to the LSP server 12.

In another embodiment, there are multiple CONNECT locations stored in the LIF. This allows the user to transport his CPE from location to location. In this embodiment, the CPE can store up to 96 different location records for connection to the LSP server 12. Usually only one or two locations are needed in normal use. Three or more locations are seldom used but in this embodiment up to 96 locations are possible. The LSP server 12 preprograms each separate and distinct location. On his CPE, the user locally selects one of the locations to be the "current" location, which is used for all subsequent connections unless changed by the user and defines the default location. The current location can be selected among the 96 locations. The information provided in the multiple CONNECT locations includes:

NAME: location description, i.e. "San Jose, CA". AREA CODE: i.e. "408". NUMBER - i.e. "555-1212". PREFIX: defines a set of digits to dial before dialing the number, i.e. it may contain "9" to dial past a PBX system, "*67" to disable call waiting, etc. DIAL AREA CODE FLAG: controls whether the area code will be dialed. For example, if the location is long distance, this switch would be enabled and a "1" would be appended to the PREFIX In other circumstances, the area code is required even for local calls.

AUTOCONNECT FLAG - controls whether the terminal unit 14 will automatically check for new mail. For long distance this would probably be turned off to reduce toll charges. Note if this is disabled for the current location, then the top-level idle screen always displays a "Connect" button, and the user is required to manually press it to check for new mail.

CHAT SCRIPT: this function instructs the terminal unit14 on how to respond to login and password prompts after the call is answered by the terminal server, but before the connect has been routed to the LSP server 12.

TIME ZONE: this function provides the information necessary for the LSP server 12 to set the TERMINAL UNIT14's time and date.

Of these parameters, only the PREFIX and the two flags, AUTOCONNECT FLAG and DIAL AREA CODE FLAG can be modified by the user.

LMCP supports an ADVANCED REGISTRATION button, which simply connects the CPE to the registration server. One of the functions supported by the Registration Server is the ability to allow the user to select new locations to be downloaded into the TERMINAL UNIT14. Ordinarily if the user has already taken the CPE to a location where he has no programmed location on the LSP server, then the CPE won't be able access the registration server. To solve this, ADVANCED REGISTRATION always inquires as to whether the current location is dialable before attempting the connection. If 'yes' then the current location is used. If 'no', then the TERMINAL UNIT14 must use a special toll- free dial-in provided by LSP server 12 known as LOCATION ZERO. LOCATION ZERO is the first location in the memory for "current locations." Among the locations available to user, LOCATION ZERO is excluded and reserved for the toll free number. For this reason, the user may not modify the flags or PREFIX in LOCATION ZERO.

In another exemplary embodiment, the terminal unit 14 has a telephone connected to the PSTN in parallel to the terminal unit 14 and the user may use the telephone as an ordinary telephone unit. Terminal unit 14 therefore includes the feature of being able to receive and store Caller ID messages, and to display calling number information on its screen. Terminal unit 14 may also be programmed with one or more telephone numbers, which can automatically dialed once the associated telephone's handset has been lifted, thus acting as a repertory dialer. Additional features of the terminal unit user interface 40 include a repeditory dialer. Thus, in the telephone mode, the user simply presses one of the soft keys so designated and the telephone will continue to ring until the busy signal is exhausted.

It will also be appreciated that the user interface in accordance with the invention does not require an graphic user interface (GUI). The GUI requires extensive detail and technology in the screen display not required by the display screen 44. This allows the display screen 44 to be inexpensive and supported by inexpensive technology and software.

The terminal unit 14 includes a timing mechanism (not shown) which causes the communication section to periodically communicate with the remote server at predetermined times to check for messages stored at the remote server which are destined for the terminal unit. In the preferred embodiment, it is an option for the user to defeat the periodic communication with the remote server. The AUTO CONNECT is disabled in the location setup file.

With particular respect to Fig. 5, there is shown a schematic representation of the LSP session. The LSP session occurs when the terminal unit 14 goes on line with the LSP server 12. The terminal unit 14 initiates the software for connection to the LSP server 12. At the start, the user initiates the software, for example, by depressing the softkey "CONNECT". This causes a transition to "online" behavior.

Upon the initiation of the connecting software, the LSP server 12 queries the terminal unit 14 for its version number or code. If the terminal unit 14 version of the LSP software is not supported the connection is broken by the LSP server 12 with a disconnect error stating that the terminal unit 14 version is not supported by the specific version of LSP server software, then the connection is broken by the LSP server 12 with a disconnect error stating that the terminal unit 14 version is not supported and to consult the LSP administrator. Additionally, in the preferred embodiment the LSP server 12 reports the number dialed, the time zone and the reason for the connection, for example if registration is required.

If this is a supported version, the terminal unit 14's CIF file is transferred from the terminal unit 14 to the LSP server 12. The LSP server 12 checks to see if the CIF is empty or invalid and the reason for connection. If the CIF is empty or invalid or if the reason for connection indicates that Registration is required, a Registration session is begun in accordance with the description below. In one embodiment, if there is a valid CIF file, or, at least, the CIF file is not empty, the CIF file is checked to see whether the CIF dirty flag is set. The dirty flag is set whenever the CIF file is known by the terminal unit 12 to require inspection by the LSP server 12

In the embodiment where the dirty flag is set, the LSP server 12 starts a registration session. If the "dirty flag" has not been set, LSP server 12 sets the terminal unit 14's clock and validates the terminal unit 14 pursuant to known email authentication methods, particularly RFC 1939. If the email account and password in the CIF 14 is invalid, a registration is begun.

Next, the LSP server 12 examines the reason for connection and inquires of the terminal unit 14 whether LSP server 12 is to begin an External session. If so, the LSP server 12 begins an External session as described more fully below with respect to Fig. 7. If there is no External session to be begun, then the LSP server asks if there is new email in the terminal unit 14's mailbox. If there is mail in the terminal unit 14's mailbox, the email is transferred from the terminal unit 14 to the LSP server 12 and sent out for delivery via standard email delivery methods (SMTP).

With particular reference to Fig. 6, there is shown a schematic flow chart of the

Registration session. The LSP server 12 inquires of the terminal unit 14 whether a Registration server is defined. A Registration server is defined as a server which handles new user registration as well as allowing existing users to modify some of the features of their email service.

The LSP server must be pre-configured to use a registration server. If no such definition exists then the LSP server disconnects the terminal unit with an appropriate error message provided the LSP server has defined a registration server. The registration session is begun and the appropriate updates and modifications may be made to the CIF file .

The modifications include the ability to retrieve email from multiple POP mailboxes, and the ability to subscribe to services such as daily news/weather/sports information.

External session. The LSP server must be pre-configured to use an external server.

Upon proper initiation and connection of the terminal unit 14 with the LSP server 12, a telnet session is started between the LSP server 12 and the external server. If connection to the external server can not be opened, the terminal unit 14 is disconnected with the appropriate error message. On the other hand, if the connection can be opened, a two-way communication will take place, wherein information regarding keyboard entry by the user is sent to the external server via the LSP server

12, and display information is sent by the external server, via the LSP server 12, to the display of the terminal unit 14. The remote server may include any server which speaks the text-based 'telnet' protocol, such as chat servers, news and information servers, stock quote servers and the like. It will be appreciated that the method of communication between the LSP server

12 and the registration server is identical to that between the LSP server 12 and the external server, with the exception that the registration server is allowed by LSP server 12 to perform certain operations not available to the external server. In particular, the LSP server has the ability to access the user name and password contained within the CIF file of terminal unit 14. Because of this similarity, the term "remote server" is used to describe connection to either the registration server or the external server, except where specific differences may occur.

Upon receipt of the data from the remote server, the LSP server 12 inquires whether the data includes a special escape sequence. If there is a special escape sequence, it is processed using the Landel Mailbug Configuration Protocol (LMCP), as explained in more detail below with reference to Fig. 8. After processing the special escape sequence, the program continues as diagramed in Fig. 7.

If there is no special escape sequence, the LSP server 12 inquires whether the remote server closed down. If the remote server has closed down, the LSP server returns to default operation. If not, the data from the remote server is forwarded to the terminal unit 14, and any keystrokes from the terminal unit 14 are sent to the remote server, and the sequence repeats.

When the remote server wants to send a command to manipulate the user's CIF, LIF or other file or control the LSP server 12 in some way, the remote server will send a LMCP commands. The LSP server 12 will see these commands, recognize them as unique control codes, and process them internally rather than sending them to the remote terminal unit 14 for displaying.

By way of example, the following describes the special compared to the routine scenario: 1) Remote Server says: "Hello, terminal unit. Pleased to meet you.";

LSP server 12 sees: "Hello, terminal unit. Pleased to meet you."; LSP server 12 sends: "Hello, terminal unit. Pleased to meet you." to the terminal unit 14.; and terminal unit 14 sees: "Hello, terminal unit. Pleased to meet you." 2) In the special scenario, the word <DC1 > denotes the start of special escape sequence and <DC1> indicates the end of the escape sequence. It will be appreciated that any word can be used instead; Remote Server says: <DC1 > QC <DC2>;

The LSP server 12 sees: <DC1> QC <DC2>;

The LSP server 12 recognizes <DC1> QC <DC2> as the special escape code sequence and hands the request QC (Query Configuration) to a special subroutine which sends the terminal unit 14's configuration back to the remote server.; The LSP server 12 sends nothing to the terminal unit 14;

The terminal unit 14 sees nothing. This lets the remote server administrator send configuration commands over an ordinary terminal session without the terminal unit 14 user knowing about the configuration commands and without making the remote server complicated. The remote server merely sends out a command framed by <DC1 > and <DC2>and a query and it will get a reply over its existing telnet session. Also updates and the like can be performed without having to go through a complicated procedure or equipment and without the user of the terminal unit 14 being aware of the changes, updates, revisions or the like. With particular respect to Fig. 8, there is shown the schematic flow chart of the processing of the special escape sequence. This is done using the LMCP commands described above with respect to Fig. 7. As seen from Fig. 8, if the remote server does not have the proper authorization, an error will be reported back to the remote server.. If the remote server has the proper authorization, the command is executed as requested and returned to the remote server with no error. Thus, if the remote server is not a registration server, the LSP server 12 won't give up any sensitive information such as the terminal unit 14 user's login name or password. When the CIF information file is received by the LSP server 12, if it is invalid, it identifies the user as a new user. In that case, the on-line registration is accomplished through an on-line session in which the user provides the first three lines of information of the CIF information file.

It will be noted from Figs. 1 - 3, that the terminal units 14 do not speak directly with one another. However, as well be appreciated, each of the terminal units 14 may leave messages with the LSP server 12 to identify it and send a message to the other terminal units 14. Also, as well be appreciated, each terminal unit 14 can send or receive messages on any of the information services to which it has virtual rights. This may includes Dialog, Internet, Stock Exchange and various other information networks. Thus, while there is no peer to peer direct connection, each of the terminal units 14 can, in fact, communicate with each other by leaving messages at the LSP server 12.

The LSP server 12 connects to various information services through Telnet services, as shown in Fig. 1. While only Dialog, Internet, and the Stock Exchange are shown through the connection on Figs. 1 -3, it will be appreciated that within the spirit and scope of this invention that any electronic information service would be virtually connectable to the LSP server 12.

With particular reference to Fig. 9, there is shown the top most level of the user interface, illustrating the off-line behavior of the terminal unit 14 and defining the User Interface sub-routine. First the terminal unit is powered. The main or idle screen appears and is shown as "IDLE". As with virtually all screens in the user interface, the user must depress a soft key to exit a screen. As noted above, each sub-routine defines its own of soft key labels and functions. The "IDLE" screen includes the soft keys CALLER ID, PHONE BOOK, MESSAGES, CHECK, and EXTERNAL. After no more three minutes (for example two minutes or five minutes is also within the scope and spirit of the invention) of inactivity, not just from the top level shown in Fig. 9, but in any level, the program times out and returns the user to the "IDLE" screen. When this occurs, and if the phone line has been idle for at least one minute and not more than two minutes. The time between one and two minutes is set by a random program in the CPE and not controllable by the user. If there are email messages stored in memory and marked as 'outgoing', then the program follows the path entitled "Automatic connect." This event, or if the user depresses either the CHECK or EXTERNAL soft keys, causes the LSP server 12 to be dialed and, in turn, process the LSP commands. During this phase, the user is presented with the "DIAL PROGRESS" screen and then the "CHECK PROGRESS" screens. Depressing the ABORT soft key from either of these screens terminates the LSP session and returns the program to the "IDLE" screen.

Terminal unit 14 may also be programmed by an entry in its LIF file and by a command that terminates the previous session to make periodic unattended connections to LSP server 12 for the purpose of receiving of new email messages. In this case, the program again follows the path entitled "Automatic connect" from the "IDLE" screen, as described above, at or near the scheduled time.

Upon depressing the CALLER ID softkey, the user is transferred to the Caller ID sub-routine, described in detail with respect to Fig. 18. Similarly, depressing the soft key PHONE BOOK invokes the Phone Book step (Fig. 15); and MESSAGES invokes the Messages sub-routine (Fig. 10).

With particular respect to Fig. 10, there is shown the Messages sub-routine. By the depressing the soft key MESSAGES on the "IDLE" screen, the program transfers to the Message subroutine. The message subroutine includes the screen entitled

"MESSAGES, and the soft keys ADDRESSES, REMOVE, COMPOSE, and READ.

In this screen, a list of all email message headers is displayed. The user may select any specific email message by using the cursor control keys to highlight any desired header. Upon depression of the soft key ADDRESSES, the Address Book is selected and the detailed description is had with respect to Fig. 13. Depression of the soft key REMOVE from the screen of Fig. 10 causes highlighted messages to be removed by the "Remove Selection" step. Upon confirmation of the deletion of the highlighted message, the program is returned to the entitled "MESSAGES" screen.

Upon depression of the soft key labeled COMPOSE, the step of building a new message with no subject or recipient is performed. After the building of the new message is performed, the step of "Edit Message" is performed wherein the user places the text and subject of the email message. Afterwards, the program is returned to the entitled "MESSAGES" screen.

Depression of the READ soft key invokes the Read Selection sub-routine as described in detail with respect to Fig. 11 , and the user is allowed to read the message associated with the highlighted header. Depression of the DONE soft key returns the program to the user at the "MESSAGES" screen.

With respect to Fig. 11 , there is shown the Read Selection sub-routine. The Read Selection sub-routine includes the screen, "Read Message" and the soft keys FORWARD, REPLY, CHANGE, ERASE and DONE.

Upon depression of the soft key FORWARD, and if the message is a received, the message is marked as 'read', then the step of building a new message with the text of original as the body and having no recipient is invoked. The next step is Edit Message. Here the user may edit the message as described in detail with respect to Fig. 12. Upon completion of the Edit Message step, the program is returned to either the "Read Message" screen, if the Retum(O) path was taken or back to the tope of the "Messages" screen, if the Return (1) path was taken.

Upon depression of the REPLY soft key, and if the message is a received message, then the step of "Build new message with text of original as body and sender as recipient" is invoked. The only difference between the REPLY soft key and FORWARD soft key is that the sender of the original message becomes the recipient under the REPLY soft key. The next step is again the Edit Message step and the process is identical to that described with respect to the FORWARD soft key. Upon depression of the CHANGE soft key, and if the message was created by the user, e.g. marked as 'saved' or 'sent' or 'outbound', then the step of copying the message to the edit buffer is invoked. Then the Edit message step is invoked and is the same as described above with respect the REPLY and FORWARD soft keys.

Upon depression of the ERASE soft key, the message highlighted is deleted and the program is returns the user to the "MESSAGES" screen.

Upon depression of the DONE soft key, the Messages subroutine is terminated, and the program returns the user to the "IDLE" screen .

With respect to Fig. 12, the Edit Message sub-routine is shown in detail. The Edit Message sub-routine includes the screens, "EDIT MESSAGE", "LIST ADDRESSES", "SAVE", and "ERROR". From the "EDIT MESSAGE" screen, upon depression of the ADDRESS soft key, the program moves to the screen entitled "LIST ADDRESSES". At that screen, the user has three softkey options, namely CC which adds a cc field to the message in the edit buffer, TO, which adds the "to" item field to that message and DONE. Regardless of the action taken, the user is returned to the "EDIT MESSAGE" screen.

From the "EDIT MESSAGE" screen, upon depression of the DONE soft key, the software detects whether there have been any changes made by the user to the message in the edit buffer. If no changes have been made then the program follows the Return (0) path back to the calling subroutine. If changes have been made, the program proceeds to the "SAVE MESSAGE" screen. From this screen, the user has four softkey options: "SAVE" stores the changed message as a 'saved' message, assumedly for later editing, and follows the Return(1) path to the subroutine which first invoked EDIT MESSAGE; "BACK" returns to the "EDIT MESSAGE" screen; "CANCEL" follows the Retum(1) path, discarding changes to the message; "SEND" causes the program to validate the email addressee: if valid, the message is stored as an

'outgoing' message and the program follows the Retum(1) path. If invalid, the user is taken to the "ERROR" screen, which informs him that an addressing error has been made. From this screen, the user may press the OK key, which returns him to the "EDIT MESSAGE" screen.

With particular reference to Fig. 13, there is shown the Address Book subroutine. The Address Book subroutine includes the screen, "ADDRESS BOOK". This screen provides the soft keys REMOVE, CHANGE, CREATE, TO, and DONE. This screen shows a list of email addresses and associated names, and the user is allowed to highlight any single entry using the cursor control mechanisms. From this screen, the highlighted address book entry may be deleted by depressing the REMOVE softkey.

To change a record from the "ADDRESS BOOK" screen, the CHANGE soft key is depressed when the record to be changed is highlighted on the screen. A copy of the highlighted address record is loaded into the edit buffer and the Edit Address step of Fig. 14 is invoked. Upon the changes being made to the address record the program returns to the "ADDRESS BOOK" screen.

A new address record may be created from the "ADDRESS BOOK" screen by depressing the CREATE soft key. Upon doing so, a new empty address record is created in the edit buffer and then the step of Edit Address is performed and likewise returned to the "ADDRESS BOOK" screen as described above with respect to the CHANGE soft key.

Depressing the TO soft key creates an empty email message record with the selected (highlighted) address record inserted into the message as the addressee. The Edit Message step then performs the functions previously described with respect to Fig. 12. Upon completion of the Edit Message step, the program is returned to the "ADDRESS BOOK" screen.

With particular respect to Fig. 14, there is shown the Edit Address step. The Edit Address step includes the screens "EDIT ADDRESS" and "SAVE ADDRESS". Also included are the soft keys DONE, BACK , SAVE, and CANCEL.

On the "EDIT ADDRESS" screen, the user may modify the name and email address of the record in the edit buffer. From the "EDIT ADDRESS" screen, upon depression of the DONE softkey, if no changes to the address record have been made, then the program returns the user to the caller of the Edit Address subroutine. If changes have been made, the user is taken to the "SAVE ADDRESS" screen.

From the "SAVE ADDRESS" screen, the user has three softkey options: "BACK" returns back to the "EDIT ADDRESS" screen; "SAVE" stores the newly modified address record into the terminal unit memory section in a manner based on the alphabetical order of the name fields of each address book record, and returns to the caller of the Edit Address subroutine; "CANCEL" causes any changes to the edit buffer to be discarded, and returns to the caller of the Edit Address subroutine. With particular respect to Fig. 15, there is shown the Phone Book step which includes the screen "PHONE BOOK". Operation of this screen is similar to that of the Address Book step of figure 13. The "PHONE BOOK" screen provides the soft keys DONE, REMOVE, CHANGE, CREATE, and CALL, and shows a list of phone numbers and associated names, from which the user is allowed to highlight any single entry using the cursor control mechanisms.

To delete a record from the "PHONE BOOK" screen, the DELETE soft key is depressed when the record to be deleted is highlighted on the screen. The highlighted address record will be deleted and the "PHONE BOOK" screen will now reflect the deletion. To change a record from the "PHONE BOOK" screen, the CHANGE soft key is depressed when the record to be changed is highlighted on the screen. A copy of the highlighted address record is loaded into the edit buffer and the Edit Phone Book step of Fig. 16 is invoked. Upon the changes being made to the phone book record the program returns to the "PHONE BOOK" screen. A new phone book record may be created from the "PHONE BOOK" screen by depressing the CREATE soft key. Upon doing so, a new empty phone book record is created in the edit buffer and then the step of Edit Phone Book is performed and likewise returned to the "PHONE BOOK" screen, as described above with respect to the CHANGE soft key.

Upon depression of the CALL soft key, the Call sub routine is invoked, as described in detail with respect to Fig. 17 below. Upon completion of the Call subroutine, the program is returned to the "PHONE BOOK" screen. At any time from the main screen of the Phone Book step, upon depression of the DONE soft key, the program is returned to the top level (Fig. 1) through the Phone Book step.

With particular reference to Fig. 16, there is shown the Edit Phone Book step. The Edit Phone Book step has a main screen entitled, "EDIT PHONE BOOK" and a second screen entitled "SAVE PHONE BOOK". The Edit Phone Book step includes the soft keys DONE, BACK, CANCEL, and SAVE.

On the "EDIT PHONE BOOK" screen, the user may modify the name and phone number of the record in the edit buffer.

From the "EDIT PHONE BOOK" screen, upon depression of the DONE softkey, if no changes to the phone book record have been made, then the program returns the user to the caller of the Edit Phone Book subroutine. If changes have been made, the user is taken to the "SAVE PHONE BOOK" screen.

From the "SAVE PHONE BOOK" screen, the user has three softkey options: "BACK" returns back to the "EDIT PHONE BOOK" screen; "SAVE" stores the newly modified phone book record into the terminal unit memory section in a manner based on the alphabetical order of the name fields of each phone book record, and returns to the caller of the Edit Phone Book subroutine; "CANCEL" causes any changes to the edit buffer to be discarded, and returns to the caller of the Edit Phone Book subroutine. With respect to Fig. 17, there is shown the Call sub-routine. Upon depression of the CALL soft key, the program detects whether the telephone line connected to the terminal unit 14 is in use. If not, the user is instructed to pick up the handset, engage a speakerphone, or otherwise activate the telephone system by the "REQUEST USER LIFT HANDSET" screen.

At this point, the user can either lift the handset or depress the CANCEL soft key. Activating the soft key CANCEL returns through the top of the Call sub-routine. If the user lifts the handset the "DIAL NUMBER" screen appears. At that screen, dialing proceeds automatically and the user is shown the progress of the dialing. The user can depress the soft key CANCEL, which immediately terminates the dialing and follows the path of "Cancel" and returns through the top of the Call sub-routine. Alternatively, the user may hang up the handset or otherwise disengage the phone line, at which point dialing will be immediately terminated and the program will follow the path of "Line not in use" to the caller of the Call subroutine. Otherwise, after dialing is complete, the program follows the path of "Done Dialing" to the caller of the Call subroutine. With respect to Fig. 18, the Caller ID sub-routine is shown. The Caller ID sub-routine includes the main screen "CALLER ID" and a screen entitled "DELETE CALLER ID". The Caller ID sub-routine includes the soft keys DONE, SAVE, LIKE, REMOVE, DIAL 10 DIGIT, DIAL 1+, DIAL, ALL and THIS. Caller ID information is provided by the telephone company at the time of a received call, and is described in detail in Bellcore document TR-NWT-000030, which is specifically incorporated herein by reference. There are several methods of Caller ID delivery: the common purpose is that the time and date of the call, the phone number of the caller, and possibly the caller's name is delivered to the called party. Caller ID records received from the Telephone Company are converted into a single format and stored by the terminal unit in order of occurrence. These records are then listed on the "CALLER ID" screen of Fig. 18. Furthermore, all records received since the previous invocation of the Caller ID subroutine is indicated on the "CALLER ID" screen as 'New'. From the "CALLER ID" screen, depression of the soft key SAVE will copy the selected caller ID record to the edit buffer in the format of a phone book record. The program then proceeds to the Edit phone book step of Fig. 14, and the user is thus allowed to save received Caller ID data into the phone book. Upon completion, the program returns to the "CALLER ID" screen.

From the "CALLER ID" screen, upon depression of the soft key REMOVE, the screen "DELETE CALLER ID" appears. From this screen, the user has four softkey options: "THIS" deletes the highlighted record and returns to the "CALLER ID" screen; "LIKE" deletes all records whose phone number fields match that of the selected record, including the selected record, and returns to the "CALLER ID" screen; "ALL" deletes all the Caller ID records and returns to the "CALLER ID" screen. It should be noted that the records for callers which have blocked (private) caller ID delivery will contain the word "BLOCKED" in the phone number field, thus all such records can also be deleted by depression of the LIKE key. This is also applies to records which have been classified as 'out-of-area'.

From the "CALLER ID" screen, depressing of the DIAL 10 DIGIT soft key leaves the 10 digit caller ID record as is and initiates the CALL step of Fig. 17. Upon completion of the CALL step, the user is returned to the "CALLER ID" screen. From the "CALLER ID" screen, depressing of the DIAL 1+ soft key adds the prefix number 1 to the 10 digit caller ID record and initiates the CALL step of Fig. 17. Upon completion of the CALL step, the user is returned to the "CALLER ID" screen.

From the "CALLER ID" screen, depressing of the DIAL soft key reduces the 10 digit caller ID record to a 7-digit number and initiates the CALL step of Fig. 17. Upon completion of the CALL step the user is returned to the "CALLER ID" .

Variations and modifications to the above-described invention are, of course, possible. Notably depression of the soft keys is typically used in exemplary embodiments of the terminal unit 14 in accordance with the invention. However, other types of activation of the soft keys are possible within the spirit and scope of the invention. For example, voice activation is within the spirit and scope of the invention. Accordingly, the present invention is not limited to the particular embodiments described above.

Claims

CLAIMSWhat is claimed is:

1. A proprietary information system, including a server and at least one terminal in communication, the server and each of the terminals connecting through a proprietary protocol software the proprietary information system comprising: a server unit including: a communication section having the ability to perform two-way communications with the terminal unit(s); software for supporting the proprietary protocol and for sending and receiving email; at least one terminal unit compatible of communication with the server unit including; a communication section having the ability to perform two-way communications with a server unit, including uploading and downloading email messages; a user interface; and a memory section for storing messages to and from the server unit, whereby, at least one terminal unit and the server unit are capable of two-way communications and storing and transmitting email messages.

2. An information system as set forth in Claim 1 , wherein the terminal unit is remote from the server unit.

3. An information system as set forth in Claim 1 , wherein the terminal unit(s) initiates the communication with the server unit.

4. An information system including at least one server unit and at least one terminal unit, the information system comprising: a server unit including: communications section having the ability to perform two-way communications with a terminal unit; software for supporting the proprietary protocol and for sending and receiving email; the server unit being integrated with an independent remote server, the independent remote server being capable of two-way communication with various information networks for allowing the terminal unit(s) to communicate outside of the information system through the server unit; a terminal unit including: a communication section having the ability to perform two-way communication with the server unit upon the initiation by either the terminal unit or the server unit; a user interface; a memory section for storing messages to and from the server unit, and whereby, at least one terminal unit and the server unit are capable of two-way communications and each unit is capable of storing inputted and outputted messages and whereby the terminal unit can communicate both within the information system and to information net works outside the information system.

5. An information system, including a server and at least one terminal, comprising: a server unit including: a communication section having the ability to perform two-way communication with a terminal unit; software for supporting the proprietary protocol and for sending and receiving email; an independent server, the server unit being in communication with the independent server, the independent server being capable of communication with various information net works for allowing the terminal units to communicate outside the information system through the server unit; a terminal unit including: a communication section having the ability to perform two-way communication with a server unit upon the initiation by the terminal unit; a user interface; a memory section for storing messages to and from the server unit, and whereby, at least one terminal unit and the server unit are capable of two-way communications and storing inputted and outputted messages and whereby, the terminal unit can communicate both within the information system and to information net works outside the information system.

6. An information system according to Claim 3, wherein the terminal unit includes a processor for causing data received from a remote server unit to be displayed on the screen of the terminal, and for causing data entered by the user on the terminal's keyboard to be transmitted to the server unit.

7. A terminal unit capable of two-way communication with a server unit and remote units, the terminal unit comprising: a communication section capable of two-way communication with remote units upon initiation of the terminal unit; a user interface including a screen and user input device; a memory for storing messages input from the user interface or received from the remote unit; and a timer which causes the communication section to periodically communicate with the remote server at predetermined times to check for messages stored at the remote server which are destined for the terminal unit.

8. A terminal unit as set forth in Claim 7, wherein the terminal unit includes a timing mechanism causing the communication section to periodically communicate with the server unit at predetermined times for down loading of messages stored on the server unit destined for the terminal unit.

9. A terminal unit according to Claim 8, wherein the communication section automatically disconnects from a remote unit upon receipt of one or more messages from the remote server or upon receipt of an indication from the remote server that there are no stored messages destined for the terminal unit.

10. A method of retrieving messages from a proprietary information system, the proprietary information system having a server and at least one terminal unit, the method comprising the steps of: contacting the server unit from the terminal unit; exchanging proprietary protocol information between the server unit and the terminal unit; creating an on-line session between the server unit and the terminal unit; downloading messages destined for the terminal unit from the server unit; storing messages from the server unit on the terminal unit; disconnecting from the server unit and going off-line; opening an off-line session with the terminal unit; and reviewing messages stored on the terminal unit.

11. A method of sending messages to a proprietary information system, the proprietary information system comprising, a server and at least one terminal unit, the method comprising the steps of: initiating a session with the a terminal unit while the terminal unit is disconnected from the server unit, defining an off-line session; creating outgoing messages, while the terminal unit is in an off-line session, the outgoing messages having a destination address, storing in the terminal unit the outgoing messages created; contacting the server unit from the terminal unit; exchanging proprietary protocol information and establishing a connection between the terminal unit and the server unit, creating an on-line session between the terminal unit and the server unit; up-loading the stored outgoing messages from the terminal unit to the server unit; storing the up-loaded messages on the server unit; and sending the outgoing messages to their destination address(es) through the server unit.

12. The method of sending messages as set forth in Claim 11 , wherein before sending the message to its destination address(es) the step of disconnecting the terminal unit from the server unit is included.

13. A method of acquiring electronic mail for distribution on a proprietary information system, the proprietary information system including a server and at least one terminal unit, the method comprising the steps of: contacting the server unit from the terminal unit; exchanging proprietary protocol information and establishing a connection between the terminal unit and the server unit, creating an on-line session between the terminal unit and the server unit; the server unit communicating with various electronic mail sources; and the server unit acquiring the electronic mail from each mail source for the terminal unit; down-loading the acquired electronic mail messages to the terminal unit from the server unit; storing the down-loaded messages in the terminal unit; sending the outgoing messages to their destination address(es) through the server unit; and disconnecting the terminal unit from the server unit