Abstract:
A videotex decoder apparatus which, in various aspects, displays a status line to indicate when connect charges are occurring; overlays menus over displayed videotex frames with portions of the displayed frames remaining visible; provides easily called log-on procedures; retrieves remote information frames by user-specified keywords names; prints information frames in selectable different overall sizes; provides selectable different character sets for display; is table-driven; is structured to include a device independent decoder and device dependent drivers; includes a controller which feeds bytes to the decoder for decoding without regard to the protocol-dependent information content of those bytes; and uses an added frame header on stored frames to indicate the videotex protocol for decoding the frames.

Description:
This application is a continuation in part of U.S. patent application, Ser. No. 595,211, filed Mar. 30, 1984, titled Enhanced Videotex Decoder Apparatus. 
    
    
     BACKGROUND OF THE INVENTION 
     This invention relates to videotex systems. 
     In typical videotex systems, textual and qraphic information from a variety of sources (such as newspapers, retailers, or banks) is made available by a videotex supplier to a large number of subscribers via interactive two-way communication over the switched telephone network. 
     The videotex supplier electronically stores the information supplied by the different sources in the form of hundreds of thousands of pages (frames) each representing a collection (arranged, for example, in rows and columns) of alphanumeric and graphic characters to be displayed on a cathode ray tube (CRT) at the subscriber&#39;s location. Each frame is sent to the subscriber as a stream of encoded bytes. Some of the bytes identify the particular characters to be displayed. Other bytes are essentially instructions about the attributes of the displayed frame, for example, the size of a particular character or the background color for a particular line of characters. The characters and attribute information are translated into the encoded bytes in accordance with a set of rules (protocol) applied by each supplier. 
     In addition to a CRT, each subscriber has a decoder for converting the received encoded bytes back to the displayable alphanumeric or graphic characters and attribute instructions, and a keyboard with which the subscriber can tell the videotex supplier what frames to send to the subscriber, and can respond to questions posed in particular frames. 
     Different videotex protocols have been developed in different countries, for example Prestel in the United Kingdom, Telidon in Canada, and NAPLPS in the United States. A description of the Prestel system is set forth in Hudson, &#34;Prestel: The Basis of an Evolving Videotex System&#34;, (BYTE, July, 1983, p. 61), and in &#34;Prestel Terminal Specification&#34; updated through 8/1/83, available from Prestel Headquarters, Prestel 435, Telephone House, Temple Avenue, London EC4Y OHL, England, both incorporated herein by reference. 
     Some videotex decoders allow the subscriber to switch between viewing frames being supplied over the telephone line and frames which have been stored locally. Frames explaining to the subscriber how to proceed may also be displayed. 
     SUMMARY OF THE INVENTION 
     In general, the invention features, in one aspect, apparatus for locally displaying frames of digital information received from a central supplier, including a port connectable to the central supplier for receiving at least one of the information frames from the central supplier, a display device for locally displaying at least one of the information frames received from the central supplier, a storage device for locally storing, after it has been displayed, as a stored frame for later redisplay, at least one of the information frames received from the central supplier, and a processor connected to be responsive to the port and the storage device and comprising means for displaying, while the port is connected to the central supplier, an indication that the port is connected. 
     In preferred embodiments, the means for displaying is further arranged to display an indication of the expense entailed in the connection, in particular, the time which has elapsed during the period since the port was most recently connected; the indication of expense is displayed on the display device simultaneously while an information frame is being displayed; the processor also includes means for enabling the user to selectively either display or not display the indication that the port is connected; the means for displaying is further arranged to display an indication of whether the information frame being displayed is a stored frame from the storage device; the processor further includes means for enabling the user to selectively either display or not display the indication of whether the information frame being displayed is a stored frame from the storage device; the means for displaying is further arranged to display, while the port is unconnected to the central supplier, an indication that the port is unconnected; and the apparatus includes a data entry device for enabling the entry of data into the apparatus, the data including commands representing actions to be taken with respect to the information frames, and the processor includes means for delivering to the display device at least one menu frame for visually indicating possible actions which may be taken with respect to the information frames, including the actions of switching back and forth between displaying the information frames as they are received from the supplier, and displaying stored frames from the storage device, and the processor also includes means responsive to the data entry device for accepting and executing entered commands corresponding to the possible actions. 
     Displaying the status line (i.e., the indications that the port is connected, and whether or not the displayed frame is from the local storage device) reminds the user of subscriber fees and telephone tolls being incurred while connected to the videotex supplier. 
     In another aspect, the invention features apparatus for locally displaying frames of digital information received from a videotex supplier, including a port connectable to the central supplier for receiving at least one of the information frames from the supplier, a display device for displaying at least one of the information frames received from the supplier, and a processor comprising means for delivering to the display device at least one menu frame for visually indicating possible actions which may be taken while an information frame received from the supplier is being displayed on the display device, and means for visually overlaying the menu frame over the displayed information frame so that at least a portion of the displayed information frame is displayed simultaneously with the menu frame. 
     In preferred embodiments, the processor includes a data entry device for enabling the entry of data into the apparatus, including commands to cause the processor to selectively either overlay the menu over the displayed frame, or to display the menu without any underlying display of any portion of the previously displayed information frame; the possible actions include actions to be taken with respect to the underlying information frame; and one action is the storage of the underlying displayed information frame. 
     The overlay enables the user to observe at least part of the current frame while acting on a particular menu. 
     In another aspect, the invention features apparatus for obtaining access via a switched communications network to a central supplier of frames of digital information for obtaining frames to be visually displayed locally, comprising means for delivering to the central supplier via the network stored coded information required by the central supplier as a condition to allowing access to the central supplier, a display device for displaying the frames of digital information, a data entry device for enabling the entry of data into the apparatus, including commands, and a processor comprising menu means for sending to the display device a menu frame identifying the central supplier as being accessible, and log-on means responsive to the data entry device for accepting and executing an entered command to obtain access to the supplier, by triggering the means for delivering to send the coded information. 
     In preferred embodiments, the coded information delivered to the supplier includes a subscriber identifier; means for holding protocol information about a protocol specified by the supplier and governing the information frames of the supplier; each information frame comprises a collection of multiple-bit bytes and the means for holding is arranged to hold protocol information which includes the number of bits in each byte; the means for holding is arranged to hold protocol information which includes a table of commands each associated with an instruction specified by the supplier for retrieving information frames from the supplier, each command corresponding to a key on the data entry device, and the processor further includes means responsive to the data entry device for sending to the supplier in response to the pressing of a key, the instruction associated with the command corresponding to the pressed key; the specified instructions include instructions to retrieve the prior information frame, to repeat the presently retrieved information frame, to log off, and to go to the home frame; there are a plurality of central suppliers each requiring its own coded information; the apparatus includes means for specifying and updating, by data entered through the data entry device, the coded information to be delivered to the supplier when access to the supplier is commanded; the processor includes means for specifying and updating the protocol information held in the means for holding; and the menu sent by the menu means identifies at least a plurality of the suppliers, and the log-on means is responsive to the data entry device for accepting and executing an entered command to obtain access to one of the suppliers by triggering the means for delivering to send to that one supplier the coded information required by it. 
     The user thus can easily, quickly, and accurately log on to the videotex supplier&#39;s system. 
     In another aspect, the invention features apparatus for retrieving selected frames of information from a central videotex supplier of the information frames, each information frame having an associated unique identifier assigned by the supplier for retrieving the frame, the apparatus comprising a display device for displaying the information frames, storage means for storing the identifier and a unique keyword selected by the operator and associated with the identifier, menu means for displaying on the display device a menu frame containing the keyword, data entry means for entering into the apparatus a request for the retrieval of a selected information frame by moving a cursor to the keyword associated with the selected information frame, and a processor responsive to the data entry means for retrieving the information frame in response to the entry of the request by transmitting the associated identifier to the supplier. 
     In preferred embodiments, the data entry means is further arranged for entering the request by typing in the keyword; and the processor comprises means for enabling specifications and updating of the keywords appearing on the menu frame and the identifier associated with each keyword by commands entered through the data entry device. 
     The user can easily and quickly retrieve particular frames, e.g., a weather forecast, from the videotex supplier using an easy to remember keyword. 
     In another aspect, the invention features apparatus for locally storing frames of digital information received from a central videotex supplier, including a port connectable to the central supplier for receiving at least one of the information frames from the central supplier, a display device for locally displaying at least one of the information frames received from the central supplier, a storage device for locally storing, after it has been displayed, as a stored frame for later redisplay, at least one of the information frames received from the central supplier, a data entry device for enabling the entry of data into the apparatus, and a processor comprising means for accepting from the data entry device a name specified by the subscriber to be associated with a particular displayed information frame, means for storing the particular ihformation frame in the storage device together with the associated name, and means for retrieving the particular information frame from the storage device in response to entry through the data entry device of a command corresponding to the name specified for that frame. 
     In preferred embodiments, the processor also includes means for grouping information frames into directories, and mean for accepting from the data entry device commands designating the directory in which a particular displayed frame is to be stored; there are a plurality of central videotex suppliers and the processor further includes means for accepting from the data entry device commands for storing in a single directory frames received from different suppliers; the processor also includes means for displaying on the display device a menu listing by name the information frames stored in a given directory, and means for accepting from the data entry device a command corresponding to the name of an information frame included in the menu for retrieval from the directory; the command is entered by steps which include moving a cursor to the name of the information frame on the menu; and the command is entered by steps which include typing the name of the information frame on the data entry device. 
     In another aspect, the invention features apparatus for printing frames of digital information received from a central videotex supplier, comprising a port connectable to the central supplier for receiving at least one of the information frames from the central supplier, a printing device for locally printing at least one of the information frames received from the central supplier, and a processor comprising means for delivering to the printer digital information corresponding to an information frame to be printed, and means for confiquring the digital information to cause the printed information frame to be of a selectable overall size. 
     In preferred embodiments, there is a data entry device for enabling the entry of data into the apparatus, and the processor further comprises means for accepting from the data entry device commands corresponding to the different selectable overall sizes. 
     The user can easily choose different overall sizes of the printout. 
     In another aspect, the invention features apparatus for processing frames of information received from a central videotex supplier, different information frames comprising characters intended to be displayed by means of different character sets, the apparatus comprising a port connectable to the videotex supplier for receiving the information frames, a display device for displaying the received information frames, a storage device for storing character font information corresponding to the different character sets, a data entry device for entering data into the apparatus, and a processor comprising means for accepting from the data entry device commands each corresponding to the display of information frames according to one of the different character sets, and means for executing a command by reference to the stored font information corresponding to the character set specified by that command. 
     In preferred embodiments, the character sets include an English character set, a German character set, a Scandinavian character set, and a Belgian character set. 
     Different language fonts thus can be handled automatically. 
     In another aspect, the invention features apparatus for locally decoding a stream of bytes representing a frame of information received from a videotex supplier, comprising means for receiving each byte in turn for decoding, means for storing a table of entries each indicating what action is to be performed with respect to each byte based on the identity of the byte and on the current state of the decoder, and means for decoding each byte by finding the entry in the table corresponding to the action to be performed and thereafter performing that action. 
     In preferred embodiments, an index array indicates, for each said byte, the location in the table wherein the action to be performed will be found, given the current decoder state; the current state is a display state and the action to be performed is to display a character corresponding to the byte; the current state is other than a display state and the action to be performed is to implement a visual attribute of the frame as specified by the byte; when the decoder occupies a particular decoder state certain of the bytes cannot, according to a predetermined protocol for encoding the bytes, properly appear in the stream of bytes, and the entries in the table corresponding to certain bytes and to the particular state indicate that the action to be performed is to display a space; and the entries in the table correspond to a Prestel encoding protocol. 
     The table driven decoder is fast and flexible. Invalid bytes are decoded as spaces on the display. 
     In another aspect, the invention features apparatus for displaying a frame of information represented by a stream of bytes received from a videotex supplier, the bytes being encoded in accordance with a particular videotex protocol, the apparatus comprising a device for visually displaying the frame based on bit images that are encoded in accordance with a display device protocol different from the videotex protocol, means for decoding the bytes into alphanumeric and mosaic characters that are based on the videotex protocol and are independent of the display device protocol, and device dependent driver means for converting the characters into the bit images in accordance with the display device protocol. 
     In preferred embodiments, the display device is arranged to display the bit images in accordance with visual attributes that are encoded in the stream of bytes in accordance with the videotex protocol, the visual attributes are conveyed to the display device in accordance with the display device protocol, the means for decoding is arranged to decode the stream of bytes into visual attributes that are based on the videotex protocol and are independent of the display device protocol, and the device dependent driver means is arranged to convert the visual attributes into visual features of the bit images in accordance with the display device protocol; and there are a plurality of the display devices having different display device protocols, and a plurality of the device dependent driver means one for each display device, for converting the characters into the bit images in accordance respectively with the different display device protocols. 
     By making the decoder &#34;device independent&#34;, while the display drivers are &#34;device dependent&#34;, the system can easily accommodate different display device protocols. 
     In another aspect the invention features apparatus for decoding a frame of information represented by a stream of bytes received from a videotex supplier, the bytes being encoded in accordance with a videotex protocol, the apparatus comprising mean for decoding the bytes into alphanumeric and mosaic characters based on the videotex protocol, and means for controlling the decoding by accepting the stream of bytes from the supplier and delivering each byte to the decoding means, the controlling means being arranged to accept and deliver the bytes to the decoding means without regard to the protocol-dependent information content of the bytes. 
     The controller can therefore be arranged to easily serve different videotex protocols. 
     In another aspect, the invention features means for updating the current state of the decoder, after each byte is decoded, in accordance with the current state and the identity of the decoded byte. 
     In another aspect, the invention features apparatus for locally processing frames of information received from central videotex suppliers, different frames being encoded in accordance with different protocols, including means for locally storing the information frames, means for locally displaying the frames, means for decoding the locally stored frames as they are displayed, and means for tagging each stored frame with a header indicating the protocol used for encoding the frame, the means for decoding being arranged to decode each frame in accordance with the protocols indicated by the header of the frame. 
     Tagging permits proper decoding of various different frames from different suppliers using the proper protocols. 
     Other advantages and features will become apparent from the following description of the preferred embodiment, and from the claims. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     We first briefly describe the drawings. 
     Drawings 
     FIG. 1 is a block diagram of a videotex system. 
     FIG. 2 is a block diagram of the subscriber&#39;s equipment of FIG. 1. 
     FIG. 3a is a menu displayed when the system enters the unconnected mode. 
     FIG. 3b is a log-on menu. 
     FIG. 3c is a menu which allows a subscriber to log-on to a videotex supplier. 
     FIG. 3d is a menu similar to the menu of FIG. 3a. 
     FIG. 3 e is a menu which allows a subscriber to log-off a videotex supplier. 
     FIG. 3f is a menu which allows a subscriber to store a videotex frame 
     FIG. 3g is a menu which displays the frames stored in the current directory. 
     FIG. 3h is a menu which requires a subscriber to confirm that he wishes to replace on old stored frame. 
     FIG. 3i is a menu which allows a subscriber to chose a frame to be displayed. 
     FIG. 3j is a menu which allows a subscriber to select small or large format print. 
     FIG. 3k is a menu which allows a subscriber to chose one of four system functions. 
     FIG. 3l is a menu which allows a subscriber to modify log-on parameters. 
     FIG. 3m is a menu which enables a subscriber to select a log-on procedure to be deleted. 
     FIG. 3n is a menu which requires a subscriber to confirm his wish to delete a log-on procedure. 
     FIG. 3o is a menu which allows a subscriber to specify or change a short name for a procedure. 
     FIG. 3p is a menu which allows a subscriber to specify or change the serial communications port at which a modem is connected. 
     FIG. 3q is a menu which allows a subscriber to change or specify the baud rate for receiving data. 
     FIG. 3r is a menu which allows a subscriber to change or specify the baud rate for transmitting data. 
     FIG. 3s is a menu which allows a subscriber to specify that data is to be received and transmitted at equal speeds. 
     FIG. 3t is a menu which allows a subscriber to change or specify the number of bits per character, the stop bit length, and the parity protocol. 
     FIG. 3u is a menu which allows a subscriber to change or specify an error substitute action and character code, and a duplex mode. 
     FIG. 3v is a menu which allows a subscriber to change or specify the character set. 
     FIG. 3w is a menu which allows a subscriber to change or specify the subscriber identification number and password. 
     FIG. 3x is a menu which allows a subscriber to change or specify telephone numbers of a videotex supplier. 
     FIG. 3y is a menu which allows a subscriber to change or specify the proper codes to control the delivery of frames from a videotex supplier. 
     FIG. 3z is a menu which allows a subscriber to change or specify user keyboard names and codes. 
     FIG. 3aa is a menu which allows a subscriber to chose to display or not to display a log-on procedure as part of a log-on menu. 
     FIG. 3bb is a menu which requires a subscriber to confirm storage of a just-defined log-on procedure. 
     FIG. 3cc is a menu which enables a subscriber to specify a current directory of stored local frames. 
     FIG. 3dd is a menu which enables a subscriber to name a file to be deleted. 
     FIG. 3ee is a collection of messages for display on the display device of FIG. 2. 
     FIG. 3ff is a collection of messages for display on the display device of FIG. 2. 
     FIG. 3gg is a message that a file is missing or defective. 
     FIG. 3hh is a message that a directory of a given name could not be created. 
     FIG. 3ii is a message that a given directory does not exist. 
     FIG. 3jj is a menu which allows a subscriber to select one of the available user keywords. 
     FIG. 3kk is a display of a frame overlaid by a menu. 
     FIG. 4 is a representative help frame for display on the display device of FIG. 2. 
     FIG. 5a, 5b are status lines for display on the display device of FIG. 2. 
     FIG. 6 is a flow diagram of the operation of the decoder module of FIG. 2. 
     FIGS. 7a, 7b, 7c are flow diagrams of the operation of the control module of FIG. 2. 
     FIGS. 8a, 8b, 8c are a block diagram of the decoder and display/print modules of FIG. 2. 
     FIG. 9 is a representative portion of the index array of the decoder module. 
     FIG. 10 is a representative portion of the transition table of the decoder module. 
     FIG. 11 is a block diagram of the control module of FIG. 2. 
    
    
     Structure and Operation 
     Referring to FIG. 1, in videotex system 10, the subscriber&#39;s equipment 12 is connected through port 13 and via an asynchronous modem 14 (with a CCITT V 24/RS-232-compatible interface) and two-way channel 16 to the switched telephone network 18. The equipment (e.g., 20, 24) of different videotex suppliers is also connected, via two way channels 22, 23, to the switched telephone network 18. 
     Channels 16, 22, 23 and the switched telephone network 18 enable relatively high speed (e.g., 1200 bits per second) communication of streams of encoded bytes representing frames of information from a supplier&#39;s equipment 20, 24 to the subscriber&#39;s equipment 12 and relatively low speed communication (e.g. 75 bits per second) of data representing requests and responses from subscriber&#39;s equipment 12 to supplier&#39;s equipment 20, 24. The communication rate can be the same in either direction, e.g., 2400 bits per second for both sending and receiving. 
     Referring to FIG. 2, subscriber&#39;s equipment 12 includes a control module 30 connected (via port 13) to modem 14, and to decoder and display/print modules 32, 34. Decoder and display/print modules 32, 34 are connected through screen driver 37 to an industry standard red, green, blue, color CRT 36 and to a printer 38 (Wang Matrix Printer PC PM010). Control module 30 is also connected to keyboard 40 (a data entry device), and to disk file 42 (Wang diskette drive with 360 kilobytes storage capacity or a Wang Winchester drive). Control, decoder, and display/print modules 30, 32, 34 comprise a processor 35 which is implemented as a Wang Personal Computer (PC-001) with 128 kilobytes of memory, an asynchronous interface card for interaction with the port, an MS/DOS operating system version 2.01, BIOS version 1.21, and Wang Videotex decoder software release 1.0. The Wang Personal Computer is described in U.S. patent application Ser. No. 440,668, filed Nov. 10, 1982, An Wang et al., Management Communications Terminal, incorporated herein by reference. 
     Control module 30 manages the operation of the subscriber&#39;s equipment, accepts the received stream of encoded bytes for each frame from modem 14, temporarily stores the frame in a buffer provided in decoder module 32, directs the decoder module 32 to decode the stored frame, directs the display module 34 (which, in turn controls screen driver 37, a Wang Industry Standard Monitor/Graphics Card, type PC-PM003) to display the decoded characters on CRT 36, directs when the printer 38 is to print the decoded characters, receives and decodes the subscriber&#39;s requests and responses from keyboard 40, and as appropriate either acts upon them or encodes them in accordance with the proper protocol and delivers them to modem 14 for transmission to the appropriate videotex supplier. 
     Decoder module 32, when instructed to do so by control module 30, decodes the encoded bytes of a frame stored in disk file 42 and delivers the decoded characters and attribute instructions to display/print module 34 for display on CRT 36. 
     Display/print module 34 either delivers a frame of bits to screen driver 37, or a stream of groups of bits, each corresponding to a character, to printers 38. Screen driver 37 uses a bit-map technique to drive CRT 36 to display the frame characters, and includes a screen buffer having storage locations corresponding to each screen location. 
     In general, the subscriber&#39;s equipment 12 is arranged to enable the subscriber to work both with frames currently being delivered from the videotex supplier and frames which were previously received from a supplier, displayed, and then stored locally in disk file 42. Frames being currently delivered from a supplier are immediately displayed. The subscriber can interactively respond to options offered in such a displayed frame, or request other frames, by keying in the proper commands which are immediately transmitted back to the videotex supplier. Currently displayed frames can also be given names by the subscriber and stored (e.g., in organized groups) in directories established in disk file 42, for later retrieval and display. 
     In addition to displaying information frames, the subscriber&#39;s equipment also can display stored menus which describe options that can be chosen by the subscriber using the appropriate keys on keyboard 40. Help screens may also be displayed to provide information to a subscriber who is confused about how to proceed. 
     The system operates in either of two modes selected by the subscriber, unconnected or connected. In the connected mode, the subscriber&#39;s equipment is attached through modem 14 and the switched telephone network to a videotex supplier. Operating in the connected mode typically entails telephone toll charges and subscriber fees. In the connected mode, the subscriber may work either with frames being supplied from the videotex supplier or with frames previously stored. In the unconnected mode, there is no connection to a videotex supplier and the subscriber may only print or display locally stored frames. 
     When the subscriber, by appropriate keyboard commands, begins a videotex session, the system enters the unconnected mode. The control module 30 gets and causes display/print module 34 to display the menu shown in FIG. 3a. The same menu also appears at any later time in the session when requested by the subscriber if the system is then in the unconnected mode. The menu offers the subscriber the options of displaying a local frame (i.e. a frame already stored in a disk file 42), storing a frame, printing a frame, logging on to remote viewdata (i.e., calling and connecting to a videotex supplier), or performing system functions. At the lower right-hand corner of the menu, instructions are provided to the subscriber. The subscriber elects an option by using the space bar on keyboard 40 to move cursor 43 to the desired option and then by pressing the execute key. Alternatively by pressing the cancel key the subscriber can remove the menu. 
     If the subscriber selects the option of logging on to a remote videotex supplier, control module 30 next gets and causes display/print module 34 to display the menu in FIG. 3b, which offers the subscriber options of several different videotex suppliers. 
     The subscriber can elect one of the options (again using the space bar and execute keys as instructed at the bottom of the menu) and is then presented with the display in FIG. 3c, which gives the telephone numbers, subscriber ID, and password for calling and being connected to the selected videotex supplier. The subscriber may then manually dial the telephone number, the ID is automatically transmitted, and the password is typed in by the subscriber in the spaces provided. Alternatively, the system could be arranged for automatically dialing the selected videotex supplier and delivering the ID and password to effect the connection. 
     Once the connection is made, the control module enters the connected mode during which it accepts frames from the videotex supplier, delivers them byte-by-byte to the decoder module 32 where they are stored temporarily in the decoder buffer, and directs decoder module 32 to decode them and to cause display/print module 34 to display them on the CRT. Control module also accepts from the keyboard any requests or responses intended for transmission to the videotex supplier and effects the transmission. Thus the subscriber can interact with the videotex supplier in the normal way. 
     From time to time during operation in the connected mode, the subscriber may wish temporarily to interrupt his current activity. For example, he may wish to change the displayed frame from the one being sent by the remot supplier to one stored in disk file 42. By touching the cancel key, control module 30 will superimpose over the currently displayed frame, the menu of FIG. 3d, which provides the subscriber with options similar to the menu of FIG. 3a except that the fourth option enables the subscriber to log-off from the remote videotex supplier. The superimposed menu doesn&#39;t entirely obscure the current frame, but leaves a portion of it on one side and at the top visible to the subscriber. 
     If the subscriber elects the log-off option, control module 30 causes the menu of FIG. 3e to be displayed. The subscriber can then confirm his intention to log-off (by pressing execute), after which control module 30 effects the log-off, and the system enters the unconnected mode. The displayed status line (described below) then no longer includes the elapsed connect time. 
     In either the connected or unconnected modes, the menus of FIGS. 3a, 3d give the subscriber the option of storing the currently displayed frame, e.g., a current frame sent from a videotex supplier, in disk file 42. 
     If that option is chosen, control module 30 causes the menu of FIG. 3f to be displayed. The subscriber may then choose and enter a name for the frame in the space provided, or before doing so may ask to see the frame directory (by pressing the indent key, i.e., program function key #1). In the latter case the control module 30 will cause the display of the menu of FIG. 3g listing the name of the current directory, the disk drive on which it resides, and the names of all local frames stored in disk file 42, or, if the directory is empty, will display a menu which says, &#34;The Directory is Empty&#34;. 
     Once the subscriber enters the frame name on the menu of FIG. 3f, control module stores the frame in that directory under that name for later easy retrieval. If the chosen frame name is already being used, control module 30 will cause the menu in FIG. 3h to be displayed to indicate that fact and permit the subscriber to confirm that the current frame should replace the old stored frame of the same name. 
     Thus the store frame function can be used to store a frame currently being displayed from the videotex supplier or to refile or rename a locally stored frame. 
     In either the connected or unconnected mode, the menus of FIGS. 3a, 3d, also permit the subscriber to display a stored local frame. Thus even when the system is connected to a remote supplier, the subscriber may temporarily interrupt the interactive session, while remaining in the connected mode, and display a stored local frame. When the subscriber elects to display a local frame, the menu of FIG. 3i is displayed. The subscriber then may enter the name of the frame to be displayed, or use the cursor to indicate the frame. The control module 30 then retrieves and causes the requested frame to be displayed. 
     Likewise, in either the connected or unconnected mode, the subscriber can elect to print a displayed frame. Control module 30 then causes the menu of FIG. 3j to be displayed, enabling the subscriber to select small or large format print, which governs the overall size of the printed frame. Based on the selection, the control module 30 via display/print module 34 causes printer 38 to print the currently displayed module. 
     Finally, in either connected or unconnected mode, the menus of FIGS. 3a, 3d, allow the subscriber the option of performing various system functions. When that option is selected, control module 30 causes the menu of FIG. 3k to be displayed and allows the subscriber to select one of four system functions: modify log-on parameters, modify storage parameters, delete stored frame, and select character set. 
     When the subscriber elects the option of modifying log-on parameters, control module 30 causes the menu of FIG. 31 to be displayed. The subscriber may then elect either to delete a log-on procedure, or to modify or create a log-on procedure. 
     If a log-on procedure is to be deleted, the menu of FIG. 3m is displayed, enabling the subscriber to select the log-on procedure to be deleted, followed by the menu of FIG. 3n, which confirms the subscriber&#39;s wish to delete that procedure. 
     If the subscriber elects to modify or create a log-on procedure, control module 30 causes the display of a succession of menus, FIGS. 3o through 3bb, which enable the subscriber to define or change the values of various parameters needed to establish a connection to a particular videotex supplier, and protocol information needed for proper interaction with the supplier. 
     In particular, the subscriber can specify or change (FIG. 3o) a short name for the procedure, (e.g. &#34;Prestel&#34; to identify the procedure used to call and connect to the Prestel service); the serial communications port of the subscriber&#39;s equipment at which the connection to the modem is made and whether the transmit/receive rate is to be equal in both directions or different (split) for transmission and reception (FIG. 3p); the baud rate for receiving data (FIG. 3q), for transmitting data (FIG. 3r), or for receiving and transmitting data at equal speeds (FIG. 3s); the number of bits per character, the stop bit length, and the parity protocol (FIG. 3t); the error substitute action and character code, and the duplex mode (FIG. 3u); the character set (FIG. 3v); the subscriber identification number and subscriber password (FIG. 3w); the telephone numbers of the videotex supplier (FIG. 3x); the proper log-off, back up frame, repeat frame, and home frame codes for transmission to the particular videotex supplier to control the delivery of frames (FIG. 3y); user keyboard names and codes to be described below (FIG. 3z); the choice of displaying or not displaying the procedure as part of the log-on menu (FIG. 3aa); and a confirmation of the storage of the just-defined procedure (FIG. 3bb). 
     Each frame available from a videotex supplier has an associated identifier assigned by the supplier. For example the weather forecast might be assigned the code *3097#. The current weather forecast frame is always available by sending that identifier to the supplier. Using the menu of FIG. 3z, the subscriber can enter the code and give it a keyword name, e.g., weather. Available user keywords can be displayed by pressing the dec tab key, i.e., function key #4, which causes the menu of FIG. 3jj to be displayed. 
     When the subscriber selects the modify storage parameters option of FIG. 3k, control module 30 causes the menu of FIG. 3cc to be displayed, which enables the subscriber to specify the current directory of stored local frames (i.e., the one to which frames are sent for storage and from which stored frames are retrieved) and specify the disk drive on which it is to reside. 
     When the subscriber selects the delete stored frame option of FIG. 3k, the menu of FIG. 3dd is presented, enabling the subscriber to name the file to be deleted. 
     When the subscriber selects the select character set option of FIG. 3k, the menu of FIG. 3v is displayed enabling the user to select the character set, i.e., the character font (e.g. English, German, Scandinavian, or Belgian) which will be used in displaying the frames. 
     When certain options are selected by the subscriber from a menu, the control module causes a display on the screen of either a message that the requested option has been executed (the possible execution messages are listed in FIG. 3ee) or an error message (the possible error messages are listed in FIG. 3ff). In response to the subscriber naming a frame which is missing or defective, the message in FIG. 3gg is displayed. When the subscriber names a directory, the control module 30 may, if appropriate, display the error messages of FIGS. 3hh and 3ii. 
     Referring to FIG. 3kk, whenever a menu is to be shown to a subscriber while a frame of information is being displayed, the menu is overlaid on the frame so that portions of the frame are still visible around the periphery of the screen. If the subscriber wishes to uncover the entire frame, he presses the &#34;cancel&#34; key to page through the hierarchy of menus until a menu at the top of the hierarchy appears. Pressing &#34;cancel&#34; again will uncover the entire current frame. 
     Whenever a menu is being displayed, the subscriber may take different actions by pressing different keys. The available actions depend on which menu is being displayed. Some of the available actions are indicated at the lower right of the frame. Generally the cancel key is used to remove the present menu and return to the prior menu. If there is no prior menu the cancel key removes the menu, leaving the underlying information frame fully displayed. The shift cancel key causes either the main menu (FIG. 3a or FIG. 3d) to be displayed, or causes the videotex session to be terminated. The space bar is used to move the cursor. The execute key is used to execute the option selected by the subscriber. The indent key (function key #1) displays the frame directory. The help key causes a help frame (described below) to be displayed. 
     When no menu is being displayed the shift cancel key causes the main menu to be displayed. 
     The actions available to the subscriber at any time can be seen by pressing the help key, which causes a help frame to be displayed. 
     For example, referring to FIG. 4, the help frame which appears if the help key is pressed while the connected main menu is displayed lists the available functions. Successive strokes of the page key (function key #2) causes the modem to be alternately ignored or acknowledged. The center key (function key #3) allows the status line (described below) to be displayed or removed. The format key (function key #6) allows the underlying frame behind an overlaid menu to be displayed or removed. 
     Referring to FIGS. 5a, 5b, the system is capable of displaying a status line with every frame and menu indicating whether the subscriber&#39;s equipment is unconnected to the videotex supplier (FIG. 5a), or is connected (FIG. 5b) in which case the elapsed time since the connection was begun is shown at the end of the line. In this way, the subscriber is always alerted to the fact that he is incurring charges while connected, even though he may be working with locally stored frames. The subscriber can choose whether or not to display the status line using the center key. 
     Different videotex suppliers use different encoding schemes for the data which make up frames of information in their respective systems. Control and decoder modules 30, 32 may be capable of recognizing, for each frame to be dgcoded, the identity of the videotex system in accordance with which the encoding was done, and must be capable of applying the appropriate decoding rules for the particular frame being decoded. 
     Each frame stored in disk file 42 includes a frame header of 64 bytes (of which 42 are actually used). The frame header identifies (a) the name assigned to the frame by the subscriber, (b) a unique arbitrary frame identifier assigned by the videotex supplier, (c) a frame offset indicating the number of bytes from the start of header to the start of the frame data, (d) the number of bytes of data in the frame, (e) the encoding protocol (e.g. ASCII, or Prestel), (f) the language (e.g. English, German, Scandinavian, or Belgian), (g) the version of the system software, (h) the version of the encoding protocol, and (i) the videotex supplier. By storing this information as a frame header, decoding, frame retrieval, and file management are made more accurate and efficient. 
     The interaction between control module 30 and decoder module 32 is accomplished in such a way that each of the modules executes certain procedures when told to do so by the other module. 
     In particular, the decoder module 32, when told to do so by control module 30, performs any necessary decoder initialization (and returns a flag to the control module 30 if initialization fails); performs any necessary de-initialization (and returns a flag if de-initialization fails); accepts and decodes a single byte (and returns a flag if action is required by the control module, for example if the decoded character represents a request by the videotex supplier to have the subscriber&#39;s equipment send back its ID number); causes the display/print module 34 to display the entire contents of the decoder buffer onto the CRT as a displayed frame beginning with the first character in the decoder buffer; causes the display/print module 34 to display selected portions of the decoder buffer onto the CRT to cause display of selected rows of an information frame; causes display/print module 34 to print the current contents of the display buffer (and returns a flag if the printing failed); and sets the decoder character font (e.g., either English or German). 
     Conversely, the control module 30, when instructed to do so by decoder module 32, clears the display screen (while maintaining the status line on the screen); returns to the decoder module an index value indicating the language specified by the frame file header associated with the current local frame; and returns to the decoder module an index value indicating the language specified by the current log-on procedure. 
     The interaction between the control module 30 and decoder module 32 is also governed by a set of common flags and variables maintained by the decoder module 32. The common flags and variables are a flag set by the control module 30 to indicate that characters sent to the decoder module should be displayed; a flag set by the control module 30 to indicate that &#34;conceal&#34; fields (i.e., portions of the information frames which may need to be concealed, such as answers to quiz questions posed in the frames) should be concealed; an address of the decoder buffer set by the decoder; an address set by the decoder to indicate a number block of the videotex supplier; a flag which is set when a request is made and reset when the request has been satisfied; a value set by the decoder to indicate the videotex supplier&#39;s block number subject to modification; and a value set by the decoder to indicate an action requested by the videotex supplier. The action requested by the videotex supplier may be to send the supplier appropriate ID information or to indicate to the control module that the beginning of a remote frame (i.e., one being sent from the supplier) has been received. 
     While the decoding applicable to each type of videotex system must, of course, satisfy the protocol rules for that system, and thus be unique, decoder module 32 is arranged so that decoding for widely different videotex systems can proceed in similar ways. The decoding is accomplished by a table oriented system. 
     Before a frame of encoded bytes is received for decoding control module 30 causes decoder module 32 to set all positions in the decoder buffer to spaces. The received and decoded characters are then overwritten into the appropriate positions in the decoder buffer. Attribute codes are tagged before being stored to indicate that they relate to an attribute and are not themselves to be displayed. 
     Whenever a stored frame is to be displayed, decoder module 32 must decode the characters and attributes and deliver the decoded information to display/print module 34. 
     The decoding for each different protocol is accomplished by means of values stored in tables associated with that protocol. Based on the relevant protocol, the decoder follows a straightforward sequence of steps to decode each byte, using the tables for that protocol to produce a displayable alphanumeric or graphic character for each of the row-and-column positions of the display. The tables are called Frame, State, Character Font, and Transition. 
     The Frame table corresponds to the decoder buffer and has as many entries as there are positions in the display (e.g., 24 rows of 40 characters each in Prestel). Each entry in the Frame table is the encoded byte for the display position corresponding to that entry. 
     The Character Font table contains the bit-pattern information defining each one of, for example, 172 different characters which may be displayed as single-height and double-height characters, either alphanumeric, or contiguous or separated mosaics. For example characters may each be defined by an 8×8 bit pattern. 
     The State table contains values that indicate the state attributes of the display which are applicable at a given time, for example to effect mosaic or alphanumeric, color of foreground, color of background, or position in line, and to locate the place in the character table where the relevant character definition is found. 
     The Transition table has entries, indicating for the current encoded byte and the current state, what action is to be performed and what the next state is to be. For example, one entry in this table would be &#34;put character C into line L, row K (using attributes specified in the State table)&#34;. Another would be &#34;display current line from current position to end of line in background color (specified in the State Table)&#34;. 
     Referring to FIG. 6, the steps performed by decoder module 32 for decoding and displaying a stored frame (i.e., for repainting the screen) begin with clearing all display positions and initializing the state table (100). In the case of a current frame being delivered from the videotex supplier, the decoding steps begin at the entry print labeled &#34;decode a character&#34; (101). The decoder module 32 then executes a loop which has the following steps. The next encoded byte is either retrieved (102) from Frame table 104, or delivered directly from control module 30, as the case may be. On the basis of the byte value, and the current state (105), the decoder determines (108) what action is to be taken. Next, using the state table 106, the Transition table 112, and the Character table 118, the decoder determines what changes to the display are needed, if any, and executes them (114), i.e., by delivering the appropriate character definitions from the Character table 118, to the display/print module 34. Then, using the current state 106 and the Transition table 120, the decoder determines what state changes are needed and executes them (122) by modifying the State (123). Finally, the decoder returns to receive (102) the next byte from the control module, or gets the next byte from the Frame table, as the case may be, repeating the sequence until all encoded bytes in the frame have been processed. 
     The decoder module 32 and the display/print module 34 (FIG. 2) are implemented by a program (in &#34;C&#34; programming language) which is structured to provide in effect a set of elements to perform the jobs required of modules 32, 34. A given job is accomplished by a sequence of steps performed by different ones of the elements. 
     FIGS. 8a, 8b, 8c show the eight elements that make up modules 32, 34. Within each element is shown a list of steps included within the repertoire of steps which that device is capable of performing. The lines connecting various step in the different elements show the sequences in which steps are performed to accomplish a given job. 
     The eight elements consist of a device dependent low resolution screen driver 400, a device dependent printer driver 402, a device independent display driver 404, a decoder controller 406, a decoder attribute manager 408, a decoder state processor 410, a decoder utilities processor 412, and a decoder function/state transition table 414. 
     The device dependent low resolution screen driver 400 performs steps that generate control signals and provide bit patterns of the specific types needed by screen driver 37 and CRT 36 to display each frame of characters in an appropriate format, i.e., with the desired character font, the desired language, character color, background color, and flashing of characters. The inputs to driver 400 are detailed device-independent instructions about which characters are to be displayed, in which font, which language, with which background and character colors, and with which flashing characteristics. Color card (FIG. 2) 37 contains a screen memory which stores for each display pixel on CRT 36 four bits which together represent one of 16 different colors to appear in that pixel. Thus, the information which must be passed from processor 400 to color card 37 is the bits defining the colors for all pixels to be displayed. 
     The device dependent printer driver 402 plays a similar role as that of driver 400 but with respect to printer 38, that is it provides rows of detailed control signals and character bit images in a format which is compatible with the particular requirements of printer 38. Among other steps, driver 402 handles form feeding, initializes and terminates the printing, and deals with single-height and double-height rows. Printer 38 prints characters using an 8-bit by 8-bit dot matrix pattern. Thus, the information which must be passed from element 402 to printer 38 is the columns of 8-bits defining each character to be printed. 
     Both element 400 and element 402 perform their steps in response to steps performed in a device independent display driver 404. Driver 404 provides detailed instruction sufficient to specify all of the parameters needed by a particular display device, e.g., a printer or a cathode ray tube. Driver 404 provides those instructions in a generalized form usable by either driver 400, or driver 402 (or any other device dependent driver which may be used). 
     Driver 404 performs its steps in response to steps performed in one of four other elements 406, 408, 410, 412, which together serve to specify the characters to be displayed in a frame, the attributes of the display, including font, color, flashing or steady, and background color, character height, and the cursor attributes. 
     The decoder function/state transition table 414 takes each character to be decoded, looks it up in an index array which provides an index to the rows of the Transition table. The entry which is in the row pointed to and is under the column which represents the current state, is then executed by either the decoder attribute manager 408 or the decoder state processor 410. 
     The decoder attribute manager 408 supervises the execution of various character attributes including starting a new row, color, flash, and background, all in accordance with the decoded attributes from table 414. 
     Decoder utilities processor 412 provides various utility functions in response to instructions from devices 406, 408, 410, including cursor control, keeping track of decoder state variables, initializing for start of a new row of the frame, and handling single height or double height display. 
     The decoder state processor 410 manages the state of the display including the display of an alphanumeric or mosaic character, or of a space when a character is out of sequence, the control of the active display position for a CRT (including movements of the active position up, down, backward, forward, home and to the beginning of a line), the delivery of status information back to the Videotex supplier via the control manager, initializing the program block, turning the cursor on and off, and clearing and reinitializing the screen. 
     Referring to FIG. 9, the array index table comprises a number of columns (only a portion of one column of which is shown in FIG. 9). The column includes a number of characters, for example &#34;capital B&#34; and opposite each character a row number pointing to a row in the Transition table. 
     Referring to FIG. 10, the Transition table comprises an array (only a representative portion of which is shown). The rows have numbers corresponding to the row numbers derived from the array index table. In each row of the table are seven columns representing the action to be taken when the decoder is in each of seven different states. For example, when the decoder is in the display mode (the 0 column of the transition table), if a &#34;capital A&#34; is received, the function to be performed is to display that character. If the decoder were instead in the escape state (the 1 column of the transition table), the A would indicate an alpha font and color attribute to be set, namely alphanumeric RED in the case of Prestel. If the decoder were instead in the escape 1 state (the 2 column), the A would be an improper character and the function would be simply to display a space. The number after each function indicates the next state to be assumed. 
     The entries in the Transition table take the form of addreses, each of which points to a structure consisting of the name of the function to be performed and the number of the next state to be assumed. In decoding a character, the decoder uses the array index table to find the proper row in the Transition table, then uses the address found in the Transition table to find the name of the appropriate function to be performed. 
     As an example of the step sequences represented by FIGS. 8a, 8b, 8c, if the next character to be acted on by the decoder controller (420) is a &#34;FLASH&#34; attribute character (in the Prestel protocol), the decoder controller tells the transition table to look up that character in the index array (422). The Transition table uses the index to point to the FLASH function in the transition table (424). The FLASH attribute is then processed (426) by the decoder attribute manager which triggers the display driver to initiate flashing mode (428). The flashing mode in turn is implemented in a device dependent manner by a screen driver 400 which delivers (430) flashing control signals to screen driver 37. 
     The link between control manager 30 and decoder 32 represents information passing from control module 30 to decoder 32, including function calls (i.e., commands), common variables (i.e., data stored in a common memory), and returns (i.e., information sent in response to function calls). Function calls and returns are likewise passed back to control module 30 from decoder 32. 
     The overall operation of system 10 is managed by the control module, which is arranged to perform the following routines as required: 
     (1) initialize the asynchronous port 13 connected to modem 14, 
     (2) at appropriate times close off the port 13 connected to modem 14, 
     (3) look to the asynchronous port 13 for a byte received from the videotex supplier and check parity. 
     (4) look to the input buffer of keyboard 40 for a keyed in character, 
     (5) deliver a byte to the asynchronous port 13 for transmission to the videotex supplier, 
     (6) check keyed in characters to see if they are valid bytes under the videotex supplier&#39;s protocol, 
     (7) tell the decoder module to stop sending characters to the display so that a help frame can be displayed, 
     (8) store a current frame in the disk file under a name specified by the subscriber, 
     (9) print a current frame via display/print module on printer 38, 
     (10) log onto videotex service, 
     (11) log off, 
     (12) store a specified frame having a specified identifier from the videotex supplier, 
     (13) transmit a frame number or other comments to the videotex supplier, and 
     (14) display appropriate menus. 
     The control module passes bytes to the decoder without regard to the information contained in them, that is, its treatment of each frame byte is essentially protocol independent. 
     Referring to FIG. 7a, the control module continually cycles through a main processing loop with two embedded loops. The routing of the process throuqh the loops depends on two two state variables: &#34;finished&#34; and &#34;show-display&#34;. When finished (200) is true the control module ends the videotex session. When finished is false but show display (202) is true, the character processing loop 204 is entered. When finished is false and show display is false, the menu display and processing loop 206 is entered. 
     In the menu display and processing loop, the system first determines (207) whether the menu is to be overlaid on the information frame with some of the frame remaining visible. If so, the control module instructs the decoder to clear only a portion of the decoder (209) buffer to make room for the overlay. Otherwise, the entire decoder buffer is cleared (211). Next, if the system is in the (logged-in) connected mode (208), the connected mode main menu is displayed (210); otherwise the unconnected mode main menu is displayed (212). Then, based on the option chosen by the subscriber (214, 216, 218, 220, 222, 224, 226, 228, 230, 231), the system either (a) sets show display to true (232) and returns to begin (which causes the menu to be removed and the current frame to be displayed), (b) retrieves a local frame (234) to be displayed and sets show display true, (c) stores a frame (236) and returns to begin, (d) prints a frame (238) and returns to begin, (e) logs on (240) and sets show display true (causing the received frame to be displayed), (f) logs off (242) and sets show display true, (g) displays the system functions menu (244), (h) executes any user functions (246) and sets show display true, (i) sets finished true (248) if the subscriber has pressed shift cancel, or (j) resets the overlay flag to change from an overlaid to a non-overlaid display or vice versa. 
     If the system functions menu is displayed (244), then based on the option chosen by the subscriber (250, 252, 254, 256, 260, 262) the system, with the subscriber&#39;s assistance, either (a) modifies the log-on procedure (264), (b) modifies the frame directory (266), (c) deletes a stored frame (268), (d) effects a character selection (270), or (e) returns to (244) or to begin. 
     In character processing loop 204, if a character is to be displayed (280), the character is fetched and delivered to the decoder for decoding and display (282). If a keyboard character is to be processed (284), the character is either transmitted to the videotex supplier (286) or is executed as a command. If the help key is pressed (290), the appropriate help menu (291) is displayed. If the cancel or shift cancel is pressed (292, 294), show display is set false (296) causing the system to return to the menu display and processing loop to display a menu. If the subscriber asks to have hidden information in the frame revealed (298), the information is revealed (300). If the subscriber calls a user function (302), the user function is executed (304). 
     Referring to FIG. 7c, the status line is controlled by a status line routine (350) which begins by determining (352) whether a display status line flag is true (indicating that the status line is to be displayed). If true, the system determines (354) whether the mode is connected or unconnected. If connected, it causes the display (356) of the elapsed time check at the end of the status line. In the next step, the system determines (358) whether the currently displayed frame is a stored local frame from the disk file or a remote frame being delivered from the supplier and accordingly displays either &#34;LOCAL FRAME&#34; (360) or &#34;REMOTE FRAME&#34; (362) at the beginning of the status line. The system determines (364) whether the center key (function key #3) has been pressed and if so switches (366) the state of the display status line flag to cause the status line to be removed (if previously displayed) or displayed (if previously absent). 
     The control module is implemented by a program (in the &#34;C&#34; programming language) which is structured to provide in effect a set of elements to perform the jobs required of the control module. A given job is accomplished by a sequence of steps performed by different ones of the elements. 
     FIG. 11 shows the ten elements that make up the control module. Within each element is shown a list of steps included within that element&#39;s repertoire. The ten elements consist of a main controller 502, an operating system interface 504, help screen and menu handlers 506, 508, a keyboard interface handler 510, a videotex supplier interface handler 512, a decoder interface handler 514, a status line handler 516, a display interface 518, and a system functions handler 520. 
     Help screen handler 506 displays appropriate help screens. Menu handler 508 displays appropriate menus or directories. The operating system interface 504 fetches needed files from the disk, stores files on disk under specified names, and deletes files from disk as appropriate. Keyboard interface handler 510 accepts keyboard entries and treats them appropriately either as commands when in local mode or as commands or characters when in the remote mode. 
     Videotex supplier interface handler 512 connects and intializes the port for a remote session, terminates the session as appropriate, and receives incoming characters. 
     Decoder interface handler 514 manages the initialization and termination of the decoder, sends bytes to the decoder for decoding and display or printing, tells the decoder the current display language, and asks the decoder to give it the responses to videotex supplier inquiries. 
     Status line handler 516 sets the status to local or remote, manages writing the status line on the screen, and handles the elapsed time clock under control of an interrupt from the operating system. 
     Display interface 518 causes the display screen to be painted with a menu (with or without surround), or with a help screen, or with the status line, as appropriate. 
     System functions handler 520 adds, deletes, or modifies the log on procedures and sets up user callable functions. 
     Main controller 502 supervises the performance of all of the jobs to be performed by calling on the other elements of FIG. 11 as required. 
     As an example of the step sequences represented by FIG. 11, when called upon to do so by the user, main controller 502 logs in to a remote videotex supplier and displays remote frames (530) by displaying the menu showing the selection of log-on procedures (532), accepting the user&#39;s key entry (534) that indicates the log-on procedure to use, acting on that entry (536) by connecting and intializing the port for a remote session (538), setting the status line remote (540), writing the status line (542) (which cause the status line to be painted--544), telling the decoder the current display language (546), receiving incoming characters (548), and sending them to the decoder for decoding and display (550). 
     Other embodiments are within the following claims. For example, the supplier might be located within the same facility as the subscriber, thus requiring no modem.