REGISTER  |  SIGN IN
United States Patent5568612
Barrett , ; et al.October 22, 1996
Title
Method and apparatus for advertising services of two network servers from a single network node
Abstract
Method and apparatus for advertising two network servers from a single network node in a LAN communication system which supports advertising only a single network server from any one node. A surrogate server is configured at the network node to listen for network broadcasts to a proprietary socket and then interleavedly advertises that the services of the first and second network servers (the "client" servers) are available from the node. When a network broadcast request addressed to the proprietary socket is received, the surrogate server responds to the request if directed to one of its clients, thereby permitting direct communication to be established with the designated one of the first or second network servers, for example, over the communication socket which is different from the proprietary socket.
Inventors:Barrett; Lorraine F. (Yorba Linda, CA), Russell; William C.  (Laguna Hills, CA), Wadsworth; Robert D.  (Costa Mesa, CA), Kraslavsky; Andrew J.  (Rancho Santa Margarita, CA), Kalwitz; George A.  (Costa Mesa, CA)
Assignee:Canon Kabushiki Kaisha (Tokyo, JP)
Appl. No.:978499
Filed:November 18, 1992
Current U.S. Class:709/203 709/219 
Field of Search:395/200,650,800,200.01
U.S. Patent Documents
4742483May 1988Morrell
4800488January 1989Agarwal et al.
4835673May 1989Rushby et al.
4866664September 1989Burkhardt, Jr. et al.
4974199November 1990Verbanets, Jr. et al.
5007013April 1991Elms
5018079May 1991Shukunami, et al.
5075875December 1991Love et al.
5151989September 1992Johnson et al.
5163131November 1992Row et al.
5191650March 1993Kramer et al.
5220674June 1993Morgan et al.
5303336April 1994Kageyama et al.
5341477August 1994Pitkin et al.
5379296January 1995Johnson et al.
5410535April 1995Yang et al.
5450571September 1995Rosekrans et al.
Foreign Patent Documents
384339Aug., 1990EP
Other References
IBM Technical Disclosure Bulletin, Aug. 1990, vol. 33, pp. 407-408..~
Primary Examiner: Treat; William M.
Assistant Examiner: Maung; Zarni
Attorney, Agent or Firm:Fitzpatrick, Cella, Harper & Scinto
Claims

What is claimed is:
1. A method for advertising first and second network servers resident on a single network node from the single network node in a local area network (LAN) communication system which supports advertising only a single network server from each node, said method comprising the steps of:
configuring a surrogate server, resident on the single network node, to listen for network broadcasts from the LAN communication system to a proprietary socket;
advertising at periodic intervals, from the surrogate server and by broadcast over the LAN, the services of both the first and the second network servers, wherein advertising for the first and second network servers is interleaved;
receiving a request addressed to the proprietary socket, the request requesting network services;
responding, from one of the first and second network servers, to the request if the request is directed to one of the first and second network servers; and
continuing interleavedly advertising, from the surrogate server and by broadcast over the LAN, for the first and second network servers.

2. A method according to claim 1, wherein said responding step comprises the step of sending on the proprietary socket an IPX packet that designates a communication socket.

3. A method according to claim 2, further comprising the step of establishing direct communication with the designated one of the first or second network servers via an SPX connection over the communication socket.

4. A method according to claim 1, further comprising the step of multi-tasking said first and second network servers on a non-preemptive multi-tasking basis.

5. A method according to claim 4, wherein the first network server comprises a peripheral server and the second network server comprises a socket server.

6. A method for responding to broadcast requests directed to either of first and second network servers executing at a single network node in a local area network (LAN) communication system which supports only a single network server from each node, said method comprising the steps of:
configuring a surrogate server at the same network node as that of the first and second servers to listen for broadcast requests from the LAN communication system to a proprietary socket;
receiving, at the surrogate server, a request from the first server to advertise network services for the first network server;
advertising at periodic intervals, from the surrogate server and by broadcast over the LAN, for the first network server;
receiving, at the surrogate server, a request from the second server to advertise network services for the second network server;
advertising at periodic intervals, from the surrogate server and by broadcast over the LAN, for the second network server, wherein advertising for the first and second network servers is interleaved;
receiving a broadcast request addressed to the proprietary socket, the broadcast request for requesting identification of network services;
determining if the broadcast request is directed to one of the first and second network servers;
responding, from one of the first and second network servers, to the broadcast request if the broadcast request is directed to the one of the first and second network servers; and
establishing direct communication between the respective network server and the broadcast requestor.

7. A method according to claim 6, further comprising the step of continuing to interleavedly advertise, from the surrogate server and by broadcast over the LAN, services of the first and second network servers.

8. A method according to claim 6, wherein said responding step comprises the step of sending on the proprietary socket an IPX packet that designates a communication socket which is different from the proprietary socket.

9. A method according to claim 8, wherein the step of establishing direct communication with the designated one of the first or second network servers comprises the step of communicating via an SPX connection over the communication socket.

10. A method according to claim 6, further comprising the step of multi-tasking said first and second network servers on a non-preemptive multi-tasking basis.

11. A method according to claim 10, wherein the first network server comprises a peripheral server and the second network server comprises a socket server.

12. An interactive network board connectable to a peripheral via a bi-directional peripheral interface and connectable to a local area network (LAN) via a LAN interface, said interactive network board defining a single network node on the LAN, said interactive network board comprising:
a peripheral server for receiving peripheral data via the LAN interface and for providing the peripheral data to the peripheral via the peripheral interface;
a socket server for (1) receiving requests for status via the LAN interface, the status requests including requests for status of the interactive network board and requests for status of the peripheral, (2) responding to requests for status of the interactive network board received over the LAN interface by providing status of the interactive network board via the LAN interface, and (3) responding to requests for status of the peripheral received over the LAN interface by obtaining the status of the peripheral via the peripheral interface, and providing the status of the peripheral via the LAN interface; and
a surrogate server for receiving requests from the peripheral server and the socket server to advertise services of the peripheral server and the socket server, and for interleavedly advertising services of the peripheral server and the socket server at periodic intervals via broadcast over the LAN interface, said surrogate server being responsive to broadcast requests on the LAN which are directed to a proprietary socket so as to establish direct communication with the broadcast requestor.

13. An apparatus according to claim 12, further comprising an IPX layer, and wherein in the case where said surrogate server receives a broadcast request for services of either the peripheral server or the socket server, said surrogate server causes the said IPX layer to send on the proprietary socket an IPX packet that designates a communication socket.

14. An apparatus according to claim 13, further comprising an SPX layer, and wherein the respective one of said peripheral server and said socket server establishes direct communication with the broadcast requestor via an SPX connection over the communication socket.

15. An apparatus according to claim 12, further comprising a non-preemptive monitor for multi-tasking the peripheral server, the socket server, and the surrogate server.

16. An interactive network board connected to a printer via a printer interface and to a local area network (LAN) via a LAN interface, the interactive network board defining a single network node on the LAN, said interactive network board comprising:
a LAN interface, over which plural servers are advertised via broadcast at periodic intervals, and over which requests for printer information and network board information are transmitted and received;
a printer interface over which requests for printer information are transmitted and over which printer information is received; and
a processor which (a) runs a print server, a socket server and a surrogate server, and interleavedly advertises, at periodic intervals, services of the print server and the socket server by broadcast over said LAN interface via the surrogate server, (b) receives and responds to the requests for network board information via said LAN interface, and (c) receives the requests for printer information, queries the printer for the printer information via said printer interface, receives the printer information from the printer via said printer interface and transmits the printer information to the LAN via said LAN interface.

17. An apparatus for advertising first and second network servers resident on a single network node from the single network node in a local area network (LAN) communication system which supports advertising only a single network server from each node, said apparatus comprising:
configuring means for configuring a surrogate server, resident of the single network node, to listen for network broadcasts from the LAN communication system to a proprietary socket;
advertising means for advertising at periodic intervals, from the surrogate server by broadcast over the LAN, the services of both the first and second network servers, wherein advertising for the first and second network servers is interleaved;
receiving means for receiving a request addressed to the proprietary socket, the request requesting network services;
responding means for responding, from one of the first and second network servers, to the request received by the receiving means if the request is directed to one of the first and second network servers, wherein said advertising means continues to interleavedly advertise, from the surrogate server and by broadcast over the LAN, for the first and second network servers.

18. An apparatus according to claim 16, further comprising a printer directly coupled to at least one of the first and second network servers.
Description
BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a circuit board which is coupled to a local area network peripheral (e.g. a printer) and which allows the peripheral to be an intelligent, interactive network member eliminating the necessity of dedicating a personal computer to manage the peripheral. More particularly, the present invention relates to such a circuit board in which two network servers are multitasked for concurrent execution, such as a print server and a communications socket server, and in which the services of both network servers may be advertised from a single network node.

2. Related Art

Local Area Networks ("LANs") are known for coupling together a plurality of personal computers with peripheral devices such as printers, copiers, etc., to provide for enhanced communication and shared resources. Heretofore, peripherals such as printers coupled to a LAN were rather unintelligent, merely accepting information from the LAN and printing such information on a hard copy. Moreover, such printers usually required a host personal computer ("PC") to effectively manage the flow of data to the printer, i.e., to act as a "server" for the printer. This almost always required that the host PC be dedicated solely to the printer server task.

A number of products have recently appeared which ostensibly eliminate the need for such a dedicated PC by incorporating hardware and software into a circuit board which may be coupled into the peripheral in order to perform limited server functions. For example, ASP Computer Products, Inc. provides a device known as "JetLAN/P" which acts as a stand-alone print server for Novell networks. The JetLAN/P.RTM. device couples to a LAN using a 10Base-2 thin coaxial cable or a 10Base-T twisted-pair cable. However, the JetLAN/P.RTM. couples to the printer only through the printer's parallel port. Thus, while print information can be sent to the printer, the amount of printer status information which can be returned from the printer is severely restricted. For example, such a device may obtain "off-line" and "out of paper" status from the printer, but little else. Such a device does very little toward making the printer a truly intelligent, responsive member of the network.

Other known devices for coupling a printer to a LAN include the Hewlett-Packard Jet Direct.RTM. C2071A/B and C2059A, the Extended Systems EtherFlex.RTM., the Intel NetPort.RTM. and NetPort II.RTM., the Castelle LANPress.RTM. and JetPress.RTM., and the MiLAN FastPort.RTM.. However, all of these devices suffer from the same disadvantages as the ASP JetLAN in that they do not allow the printer to transmit sufficient amounts of data to the LAN to enable the printer to be an effective and intelligent member of the network.

Moreover, those products have processors that execute only a single server such as a Novell-compatible print server or remote printer adaptor. Heretofore, it has not been possible to provide more than one server at the network communication board, and also to have both of those servers advertise to other devices on the network that the services of those servers are available. This is because the Novell-compatible Server Advertising Protocol ("SAP") assumes that each network node is the host to only a single network server. Accordingly, even if more than one server were provided in a single network node, both of those servers would not be able to advertise their services simultaneously from the node.

SUMMARY OF THE INVENTION

The present invention overcomes the drawbacks noted above by providing structure and function on a circuit board coupled to a peripheral which will permit the peripheral to be a responsive, intelligent member of a network.

In one aspect, the present invention comprises a method and apparatus for advertising the services of two network servers (the "client servers") from a single network node by configuring a surrogate server to interleavedly advertise for the first and second network servers. The surrogate server monitors the LAN communication bus for requests for network services and, if the request is directed to one of its client servers, it responds to the request so as to permit establishing direct communication from the respective one of the first and second network servers.

According to this aspect, the invention comprises a method and apparatus for advertising two network servers from a single network node in a LAN communication system that supports advertising only a single network server from each node, in which a surrogate server is configured at the network node to listen for broadcast requests to a proprietary socket number. The surrogate server receives requests from first and second network servers at the node (hereinafter the "client" servers) to advertise that the clients' services are available. In response, the surrogate server interleavedly advertises on the LAN for the first and second network servers. When a broadcast request addressed to the proprietary socket is received, the surrogate server determines if the broadcast request is directed to one of its clients. If the broadcast request is directed to one of its clients, the surrogate server responds to the request and provides a communication socket by which direct communication can be established between the designated client server and the broadcast requestor. More specifically, the surrogate server may respond with an IPX packet on the proprietary socket that designates the communication socket thereby permitting the client server to establish a direct SPX connection over the communication socket.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-noted advantages and features of the present invention will become more readily apparent from the following detailed description of the preferred embodiments when taken in conjunction with the Drawing in which:

FIG. 1 is a block diagram of a Local Area Network according to the present invention;

FIG. 2 is a block diagram of a plurality of Local Area Networks coupled together;

FIG. 3 is a block diagram showing the Network Expansion Board according to the present invention coupled between the Local Area Network and the printer;

FIG. 4 is a block diagram of the Network Expansion Board according the present invention;

FIGS. 5A, 5B and 5C comprise a top-level flowchart showing the basic functions of the Network Expansion Board according to the present invention;

FIG. 6 is a diagram showing the sequence in which software modules are loaded from the Network Expansion card ROM to RAM;

FIG. 7 is a block diagram showing hardware and software interfaces between the LAN and the Network Expansion Board;

FIG. 8 is a flowchart showing how the EPROM firmware is configured for placing the Network Expansion Board in an operational mode;

FIG. 9 is a chart showing the physical construction of different frame packets used on Ethernet;

FIG. 10 is a flowchart showing the operation of a PRESCAN software module;

FIG. 11 is a chart showing that the PRESCAN module may be used with other software protocols;

FIG. 12 is a chart for explaining the software structrue of the SAPSERVER program;

FIG. 13 is a flowchart showing the operation of SAPSERVER;

FIG. 14 is a flowchart showing the operation of a CPINIT program;

FIG. 15 is a flowchart showing the operation of a CPCONSOL program;

FIGS. 16A and 16B comprise a flowchart showing the operation of a CPSOCKET program;

FIGS. 17A and 17B comprise a flowchart showing the automatic logging of peripheral statistics;

FIG. 18 is a flowchart showing how multi-tasking processing is performed;

FIG. 19 is a flowchart showing how to place the printer in a safe, default configuration;

FIG. 20 is a flowchart showing the downloading of executable files to the Network Expansion Board from the local area network;

FIG. 21 is a flowchart showing the loading of independently-executable modules in the EPROM of the Network Expansion Board;

FIG. 22 is,a block diagram showing Network Expansion Board EPROM flash protection circuitry;

FIG. 23 is a flowchart showing the operation of the circuitry of FIG. 22;

FIG. 24 is a flowchart showing the operation of remotely loading firmware in the Network Expansion Board EPROM;

FIG. 25 is a block diagram showing a hardware configuration for testing the Network Expansion Board; and

FIGS. 26A and 26B comprise a flowchart showing a method of testing the Network Expansion Board using the test configuration of FIG. 25.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In its general aspects, the present invention provides hardware and software solutions for making a network peripheral, such as a printer, an interactive network member capable not only of receiving and processing data received from the network, but of transmitting to the network significant amounts of data such as detailed status information, operational parameters, and even data input to the peripheral through other modalities such as scanning, facsimile reception, etc. By integrating such hardware and software with the peripheral, it is possible to eliminate the requirement for dedicating a personal computer to the peripheral to act as a peripheral server.

1. ARCHITECTURE

FIG. 1 is a block diagram showing the present invention incorporated into a Network Expansion Board ("NEB") 2 coupled to a printer 4 which has an open architecture (to be discussed below). The NEB 2 is coupled to the LAN bus 6 through a LAN interface 8, for example, Ethernet interfaces 10Base-2, 10Base-T, or 10Base-5, respectively, with a Coax connector, an RJ45 connector, or a DB15 connector (AUI). Also coupled to the LAN 6 may be such network members as PC 10, PC 12, PC 14 (which in this case acts as the network administrator if the administrator has logged in at that PC; to be discussed below), and a printer 16 (with embedded QSERVER functionality; also to be discussed below). Other LANmembers may include PC 18 (acting as a print server; to be discussed below) with attached printer 20, PC 22 (acting as an RPRINTER; to be discussed below) with attached printer 24, and printer 26 which is coupled to the LAN 6 through a NetPort device 28 (discussed in the Background of the Invention above). A file server 30 is coupled to the LAN 6 and serves as a "library" for files to be transmitted and processed on the LAN. The file server 30 may have attached printers 32 and 34.

In more detail, the network depicted in FIG. 1 may utilize any network software such as Novell or Unix software in order to effect communication among the various network members. The present embodiments will be described with respect to a LAN utilizing Novell NetWare.RTM. software (to be discussed in greater detail in section 3a below) although any network software may be used. A detailed description of this software package may be found in the publications "NetWare.RTM. User's Guide" and the "NetWare.RTM. Supervisor's Guide" by M&T Books, copyrighted 1990, incorporated herein by reference. See also the "NetWare.RTM. Print Server" by Novell, March 1991 edition, Novell Part No. 100-000892-001. Briefly, the file server 30 acts as a file manager, receiving, storing, queuing, caching, and transmitting files of data between LAN members. For example, data files created respectively at the PCs 10 and 12 may be routed to the file server 30 which may order those data files and then transfer the ordered data files to a printer 24 upon command from a print server in PC 18. The file server 30 may include or may be coupled to a large capacity storage member such as a 10 Gigabyte hard disk subsystem, Furthermore, the printers 32 and 34 may be coupled to the file server 30 to provide additional printing stations, if desired.

While personal computer equipment is illustrated in FIG. 1, other computer equipment may also be included, as appropriate to the network software being executed. For example, Unix workstations may be included in the network when Unix software is used, and those workstations may be used in conjunction with the illustrated PC's under appropriate circumstances.

PCs 10 and 12 may each comprise a standard work station PC capable of generating data files, transmitting them onto the LAN, receiving files from the LAN, and displaying and/or processing such files at the work station. The PCs 10 and 12, however, are not capable of exercising control over LAN peripherals (unless the network administrator is logged into that PC).

A PC capable of exerting limited control over LAN peripherals is PC 22 which includes an embedded RPRINTER program. The RPRINTER program is a MS-DOS Terminate and Stay Resident ("TSR") program which runs on a work station to allow users to share the printer 24 connected to the work station. RPRINTER is a relatively unintelligent program that does not have the ability to search printer queues for work. RPRINTER gets its work from a PSERVER (to be discussed below) that is running elsewhere in the network. Because they communicate with the attached printer over the printer's parallel port, RPRINTERs are able to obtain only limited status and to return that status information to the responsible PSERVER over the LAN 6. From a control standpoint, an RPRINTER allows stopping of a print job and little more. Some printers include RPRINTER features by offering internal or external circuit boards that provide the same limited features of the RPRINTER TSR program running in a personal computer.

Another network entity capable of exercising limited control over LAN peripherals is a printer 16 with attached circuit board 36 having an embedded QSERVER program. Here, the QSERVER program runs inside an HP LaserJet III.RTM. SI printer, and has the capability of searching the file server 30 print queues for eligible print files. The QSERVER's search queues cannot be dynamically altered nor does the QSERVER respond to any form of status inquiry. The benefit of the QSERVER is its ability to autonomously search for work. The QSERVER does not require a PSERVER running elsewhere in the system to feed it work. Since the QSERVER does not have a corresponding PSERVER and it does not itself have any status and control capabilities, it offers less control than even the RPRINTER. A QSERVER also differs from a PSERVER in that it has extremely limited notification features and cannot print banners at the beginning of each print job.

Another network member having a QSERVER capability is printer 26 which is coupled to the LAN 6 through an external NetPort device 28.

Other peripheral server programs may be executed to service various peripherals, such as scanners, copiers, facsimiles etc., and servers may also be provided based on network software protocol such as a Unix-compatible Line Printer Remote server ("LPR").

ALAN member capable of exercising significant control over LAN peripherals is the PC 18 having a PSERVER program embedded therein. PSERVER has the ability to service multiple user-defined print queues, perform dynamic search queue modification, and provide defined notification procedures for exception (failure) conditions and status and control capabilities. PSERVER is provided in several forms. PSERVER. EXE is a program that runs dedicated on a work station and controls both local and remote printers. The local printers can be connected to either serial or parallel ports, and the remote printers are printers running elsewhere in the system. Two other forms of the PSERVER program are the PSERVER.VAP and the PSERVER.NLM. These are PSERVER versions that run on the file server 30 itself. The .YAP version is for NetWare.RTM. 286, and the .NLM version is for NetWare.RTM. 386. While the PSERVER provides much more capability than the RPRINTER and QSERVER, one of its drawbacks is that the .EXE version requires a dedicated personal computer.

A dedicated personal computer running PSERVER.EXE can control as many as 16 local/remote printers and can request print information from many file server queues. However, there are several drawbacks to relying on PSERVER to control network printing services. The first drawback is that multiple printer streams must all be funnelled through a single network node and personal computer processor. This can become a bottleneck. The second drawback is that for the most efficient operation, the printers should be connected to the computer locally, as with the printer 20. This can be an inconvenience for users since it requires the printers to be clustered around PC 18. The third drawback is that if the controlled printers are remote as in the case of printer 24 which is serviced by RPRINTER, then the print data must make the trip from the file server 30 to the PSERVER PC 18 and then be retransmitted to the printer running RPRINTER. This is inefficient.

The fourth drawback is the limited amount of printer status and control information offered through PSERVER. It has already been stated that RPRINTER does not allow for much more than rudimentary status such as "out of paper" and "off line". PSERVER itself for locally and remotely connected printers does not offer much more than this because it was designed with consideration of the limitations of the personal computer parallel port. The PSERVER program also allows for its own status and control.

The Network Expansion Board 2 installed in the printer 4 provides many advantages and enhanced flexibility over the network peripheral control entities discussed above. In particular, the NEBembedded controller offers RPRINTER, PSERVER and LPR (Line Printer Remote) functionality (through CRPRINTER, CPSERVER and CLPR programs to be discussed in section 3d below). There is an initialization program named CPINIT (to be discussed in section 4h below) which allows the network administrator's PC 14
complete control over the configuration of NEB features. Due to its embedded nature and the open architecture of printer 4, the NEB will have the ability to offer a wide variety of status and control features to the network. That is, verbose amounts of status information may be provided from the printer 4 to the LAN 6, and a great deal of control information may be provided from the LAN 6 to the printer 4 (for example, exercising printer front panel functions from the PC 14).

To access the extended amount of information available in the NEB, a program called CPCONSOL is resident in the network administrator's PC 14 and allows the system administrator to view all of the printer information which is exported from the printer 4 by the NEB 2. The printer information is available even if the RPRINTER functional configuration (CRPRINTER) of the NEB 2 is selected. The PSERVER functional configuration (CPSERVER) of the NEB 2 will control the printer 4 that contains the board. This option will have all of the standard PSERVER queue search capabilities as well as the notify and status features. All of these features can be dynamically controlled from a remote work station. The NEB environment and its ability to export extended status and control information from the printer 4 makes the combination of the NEB 2 and the printer 4 much more powerful than the standard RPRINTER, QSERVER, or PSERVER print methodologies currently available.

The CPCONSOL program (to be discussed in greater detail in section 4i below) provided in the network administrator's PC 14 is capable of interfacing with the NEB 2 (and other network members) to perform such functions as displaying current information for a selected network device (interface information, control information, font information, layout information, quality and common environment information, duplex information, and miscellaneous information). CPCONSOL is also capable of setting or modifying the safe (default) condition of a network device. CPCONSOL may also activate or deactivate applications of the NEB 2 such as CPSERVER or CRPRINTER (to be discussed below, but generally similar to the PSERVER and RPRINTER software packages discussed above). Furthermore, the CPCONSOL enables the PC 14 to display a log file, clear the log file, or write the log file to memory such as a local or a file system disk. CPCONSOL can also display such printer-related information on PC 14
as the number of jobs, the number of pages per job, the number of pages per minute, the time per job, the number of total pages per day, the number of total jobs per day, and the number of days. The CPCONSOL program is also capable of displaying on the PC 14 such network-related information as media related and non-media related information, and of clearing such network statistics.

The CPINIT program (to be discussed in greater detail in section 4h below) resident in the network administrator's PC 14 can set up application information print services such as CPSERVER and CRPRINTER and configure those applications. CPINIT is also capable of setting and/or displaying device information such as time/date/time zone, buffer size, disk size, logging flag, log limit, and a safe (default) environment flag. CPINIT can also restore default service headings, reset the NEB 2, reboot the NEB 2, command a font download, command an emulation download, display a NEB power-on-self-test ("POST") error, display the NEB 2 firmware level, display the current log file size, etc.

By providing the NEB 2 with PSERVER and RPRINTER capabilities, the present invention achieves, with a single circuit board, enhanced functionality for the printer 4 with respect to the LAN 6. Therefore, the printer 4 is a true "networked" printer and not just a printer connected to a network.

While the present invention offers unique advantages on the LAN 6, these advantages are also realized when the LAN 6 is coupled to one or more other LANs in a Wide Area Network ("WAN"). FIG. 2 depicts such a WAN which includes a first LAN 41
including a server S1 40, PC's 42, 44, and 46, and a printer 48. The server S1 40 is coupled to a backbone 50 over a bus 52. The backbone 50 is nothing more than an electrical connection between a plurality of buses. Also connected to the WAN is a second LAN 61 comprising server S2 60, PC's 62, 64, and 66, and a printer 68. Server S2 60 is coupled to backbone 50 over bus 54.

The WAN may also include a remote LAN 71 comprising server S3 70, PC's 72, 74 and 76 and a printer 78. Since the LAN 71 is remote from the remainder of the system, it is coupled to backbone 50 through a bus 56, a transponder (which may include a modem) 58, and a communication line 59.

In such a WAN, assume that PC 42 is a PSERVER requesting the use of printer 78. If the printer 78 is equipped with a NEB according to the present invention, a direct communication link can be established between the PC 42 and the printer 78
whereby job information can be sent to printer 78, and status and control information can be sent from printer 78 to the LAN 41. Therefore, the NEB according to the present invention achieves its enhanced functionality even when installed in a peripheral coupled to a WAN.

FIG. 3 is a block diagram depicting the connection of the NEB 2, according to the present invention, with the printer 4 and the LAN 6. The NEB 2 is directly connected to the LAN 6 via LAN interface 101, and also to the printer 4 via a bi-directional interface, here a Small Computer System Interface ("SCSI") 100. The SCSI interface 100 is coupled to an SCSI bus 102 of the printer 4.

The NEB can also service additional SCSI devices, such as other printers (RPRINTERs) or other peripherals, daisy-chained on the SCSI bus using standard SCSI connectivity protocol. Also, the NEB may be used to drive other peripherals across the LAN itself.

The printer 4 is preferably an open-architecture printer including the SCSI bus 102 and SCSI interfaces 104 and 106. Printer 4 also includes a processor 108 such as a REDUCED INSTRUCTION SET COMPUTER ("RISC") which communicates with a RAM Memory
110 and with a printing engine 112 which actually drives the printing mechanism. The RISC processor also communicates with NVRAM 111 for storing information which needs to be maintained between power cycles, such as user-defined information, and with ROM 113 from which RISC processor 108 executes printer control. The printer 4 may also include a hard disk 114 capable of holding large amounts of data in a non-volatile way. Printer 4 also has a front panel display 116, and a keyboard 115 for inputting control commands to the printer.

Preferably, the printer 4 includes an open architecture which takes advantage of the bi-directional nature of the SCSI interface 100 to provide a great deal of status (and other) information from the printer 4 to the LAN 6 via the NEB, and also to allow fine control of the printer from a remote location. For example, such open architecture when used with the bi-directional SCSI interface permits most or all of the information on the front panel display 116 of printer 4 to be exported to a remote location, and also permits most or all of the control functions of the printer front panel keyboard 115 to be activated from the remote location.

Briefly, the open-architecture printer 4 comprises four major subsystems: Communication; Job Pipe; Page Layout and Raster functions; and Systems Services. The Communication subsystem handles the different communication devices and initiates the start of a job application; When the printer starts to receive data, the Communication subsystem sends the first part of the incoming data to each emulator for examination. The first emulator that can process the data becomes the Job Pipe driver. The system then constructs a Job Pipe to process the data (data flows into one end of the pipe, and page images flow out of the other end). This Job Pipe comprises many segments one of which is the Job Pipe driver.

The Job Pipe subsystem has a Pipe driver segment (the application for an emulator) and input and output segments. The input and output pipe segments have at least two other segments: for input, source and source filter segments; and for output, an output filter and a data sink. The input segment of the Communication subsystem delivers the input data which can be supplemented by information from a file system. The Pipe driver processes input and supplemental data. It also generates imaging commands and page layout information that it sends to the output segment. The Pipe driver may store this information to the printer disk (if present). The output segment sends this data to the Page Layout and Raster subsystem.

The Page Layout and Raster subsystem takes the imaging and page layout information and converts it to a raster image for the print engine 112. This section operates completely separately from Job Pipe.

The System Services subsystem provides file system access, console access, font services, basic system services, and image generation services. Therefore, a printer 4 having such an open architecture will take full advantage of the intelligent, interactive NEB 2 to provide increased functionality to the printer 4 and the entire network.

2. HARDWARE

FIG. 4 is a block diagram of the NEB 2 showing the major components thereof. The NEB 2 is coupled to the LAN 6 through network connectors 202, 203, and 204. Preferably, the connector 202 is an RJ45 capable of accepting a 10Base-T connection. The connector 203 may comprise a DB15 connector for accepting a 10Base-5 connection, while the connector 204 may be a simple Coax connector capable of accepting a 10Base-2 connection. All of the connectors 202, 203, and 204 are coupled to a network controller 206 (preferably an Ethernet Network Controller). However, the connector 204 is first coupled through a transceiver 208.

Power is supplied to NEB 2 from a +5 V power source in printer 4 through the printer expansion port 226. The +5 V power is also provided to the power converters 210 and 212. The power converter 210 provides -9 V power to transceiver 208, while the power converter 212 provides +12 V power for "flashing" (loading; to be discussed in section 4q below) the EPROM 222. Also, the network controller 206 is coupled to an 8 KB static RAM 214.

The heart of the NEB 2 is a microprocessor 216, preferably an NEC V53. The microprocessor 216 is coupled to a serial port 218, currently used for testing. Also coupled to the microprocessor 216 are a 512 KB dynamic RAM 220, a 256 KB flash EPROM
222, an SCSI controller 224 (corresponding to SCSI interface 100 of FIG. 3) a printer expansion port 226, a diagnostics/failure LED 240, a 256 Byte non-volatile RAM 228, a control register 230, and a PROM 232 which stores the Media Access Control ("MAC") address which is the unique name for every EtherNet board.

The architecture of the NEB 2 provides an advantage in that it has unique support features for administration and management of large, multi-area networks. These support features include, for example, printer control and status monitoring from a remote location on the network, (i.e., from the network administrator's office), automatic management of printer configuration after each print job to provide a guaranteed initial environment for the next user, and logs of printer usage statistics accessible across the network for characterizing printer workload and scheduling toner cartridge replacement. A key parameter in the NEB design is the ability to access the printer control state from the NEB 2 through a bi-directional interface, here the SCSI interface 100. This allows the printer console information to be exported to the NEB or to an external network node for the programming of many useful printing support functions.

Table 1 below provides a description of the functions, implementation, and operational notes with respect to the major hardware elements of NEB 2.

TABLE 1 ______________________________________ Function Implementation Notes ______________________________________ Network Controller National DP 83902 With DP8392 Coax (206) Transceiver Ethernet Interfaces: 10Base-2 (202) Coax connector 10Base-T (204) RJ45 connector 10Base-5 (203) DB15 connector (AUI) Embedded Processor NEC V53 16-bit/16Mhz MPU (216) with DMA, timers, Interrupts EPROM (Flash) 256K Bytes Network program (222) code, board BIOS (Basic Input Output Subsystem), diagnostics NVRAM 256 Bytes Printer (220) Installation Configuration on Network DRAM 512K Bytes Code execution and (220) data buffering for exp.port SRAM 8K Bytes Buffering of (214) incoming Ethernet packets SCSI Controller NCR
53C90A 30-pin, internal (224) I/F configuration with power MAC Address and 32 Bytes Stores MAC ad- Hardware ID PROM dress and Hardward (232) ID information Board Size 100 mm .times. 125 mm Type 2 EXP-I/F PCB, double-sided SMT Power 5vdc, 710
ma DC converter on board for Ethernet +12vdc/-9vdc ______________________________________

Preferably, the NEB 2 is installed inside the printer 4 in an expansion or options slot. The NEB 2 is thus an embedded network node with the processing and data storage features described above.

The microprocessor 216 implements a data link layer of network packet transmission and reception. Network data transfer overhead is minimized through the use of a dedicated static RAM packet buffer 214 managed directly by the network controller
206. The microprocessor 216 accesses blocks of SRAM packet data and network messages through the network controller 206, and moves them into the large DRAM memory 220.

Blocks of print image data and control information are assembled by the microprocessor 216 for transmission to the printer 4 by the SCSI controller 224 using the SCSI transfer protocol of the printer expansion port. Likewise, printer status information is transferred from printer 4 back to the NEB 2 in SCSI block format. The SCSI controller 224 operates concurrently with the network controller 206 for increased data throughput for overall NEB performance.

The microprocessor 216 is preferably an NEC V53 chip which is a fast, highly-integrated microprocessor with a 16-bit Intel-compatible processor in support of Direct Memory Access ("DMA"), interrupt, timers and DRAM refresh control. Data bus structure on the NEB 2 is implemented 16-bits wide to take advantage of the 8-Bit/16-Bit dynamic bus sizing during microprocessor I/O transfers. Control firmware and printing application software for the microprocessor 216 are stored on the NEB 2 in EPROM 222. After power-on self-test, the firmware code is selectively moved to the higher-performance DRAM 220 for actual execution. Network and printer configuration parameters are written into NVRAM 228 when the printer is first installed onto the network. Thus, NVRAM 228 allows the NEB software to recover the installation parameters after printer power has been cycled off and on.

3. SOFTWARE

software for the LAN comprises a combination of network software, and NEB-customized software such as NEB-embedded software and software resident on the network administrator's PC.

3a. Network Software

In the present embodiment, NetWare.RTM. network software is used to manage interactions between nodes of a network such that the client work stations can share and receive services from server nodes such as disk file servers, database servers, print servers, etc. NetWare.RTM. itself is a combination of software modules running on these server nodes and on each work station node. At least one file server may be provided in a Novell network. NetWare.RTM. runs as the operating system for the PC of the file server to provide basic network core services and utilities. File servers can connect to more than one LAN by using up to four network interface cards (preferably Ethernet or Token Ring connections). In these configurations, "bridging" or "backbone" services are provided between a plurality of LANs, as shown in FIG. 2, such that resources, including printers, can be shared "internet" i.e., from one LAN to another.

On work stations, NetWare.RTM. runs in cooperation with the work station operating system (DOS or OS/2) as a NetWare.RTM. "shell" of control software. This shell has the effect of extending the services of the workstation operating system onto the network to make network resources appear local to the work station.

Novell PSERVER software has the job of controlling a group of printers (up to sixteen) in order to service printing requests from network nodes. Requests are structured in a form of print queues that are held on the network file server using network queue management services. Queue entries contain a list of files to be printed. The files contain data to be printed such as tabs, formfeeds, and other Printer Description Language ("PDU") commands. Several queues can be serviced by a single PSERVER.

Standard Novell servers are available in different versions depending on the type of network node they are to execute on. Print server programs can reside on the file server itself. A version of print server software may also be loaded on a stand-alone DOS station node to make that node a dedicated print server.

By providing print server functionality (CPSERVER) to NEB 2 of the present invention, the NEB and attached printer will offer all the printing services of a standard Novell print server without the need for an attached PC.

Printers themselves are considered to be either "local" or "remote". A local printer is one that is physically connected to the print server node. In the case of the NEB 2, the local printer is the printer housing the NEB. A remote printer is managed by RPRINTER programs running in the PCs they are connected to. RPRINTERs receive print data from PRINTSERVERS running elsewhere on the LAN. The NEB 2 of the present invention can be provided with RPRINTER functionality (CRPRINTER) to offer its printer as a network remote printer. In this mode, it is fully compatible with standard versions of Novell print servers.

Novell NetWare.RTM. provides a number of print utilities to configure and control file server or work station-based print servers and their attached printers. The Novell program PCONSOLE is a menu-driven utility that allows a user (the printer console operator) to create a new print server, configure up to sixteen local or remote print ports, create print queues, assign queues to printers, and start/stop printer and server operations.

3b. NEB-Customized Software

The NEB 2 is bundled with software modules that implement the full range of printing services offered by NetWare.RTM.. This includes external NetWare.RTM.-compatible modules that execute on work station nodes of the network in addition to internal NetWare.RTM.-compatible modules running on the NEB 2 inside the printer. The specific NetWare.RTM.-compatible programs developed for use with the NEB 2 (e.g., the customized CPSERVER and CRPRINTER programs to be discussed below) are provided with the same general operational interfaces as standard printing modules from Novell so as to be familiar to Novell users and network administration personnel. The customized versions include functional extensions that make use of the open architecture of the printer 4 to enhance print service management across the network.

Table 2 shows the functions, implementations, and operational notes for the customized software developed for the NEB.

TABLE 2 __________________________________________________________________________ Function Implementation Notes __________________________________________________________________________ NEB-specific CPSERVER (92KB) Customized Print functions in NEB Server EPROM CRPRINTER (40KB) Customized Remote Printer NEB-to-Network CPSOCKET (30KB) Concurrent multi- communication in protocol operation NEB EPROM NEB Environment in (15KB) Monitor, loader, NEB EPROM POST, etc. Extensions to CPCONSOL.EXE (180KB) Remote Control & NetWare .RTM. Stats, Auto- PCONSOLE for Printer CPINIT.EXE (120KB) Reconfiguration, Control/Configuration Print Job in Administrator's Logs/Statistics PC 14 __________________________________________________________________________

3c. NEB-Embedded Software

The software developed for the NEB 2 includes software embedded in the NEB and software loaded into the network administrator's PC 14. The NEB-embedded software provides both the NetWare.RTM.-compatible node and NetWar.RTM.-compatible print services directly inside the printer 4 without the overhead of a work station PC and its DOS operating system. The NEB-embedded software comprises a plurality of application modules (CPSERVER, CRPRINTER, etc.), real-time service modules, network protocol stacks, and a MONITOR program which performs application switching, process extension, device semaphores, and shares buffer-pool management. The functionality of the NEB is determined by the types of application modules and the number of protocol stacks of network layered communication software that are configured into the NEB 2. Interaction between the printer 4 and the network is coordinated by the MONITOR program which responds to real-time events while allocating NEB processing time to each application module on a multi-tasking basis.

The NEB software functions at two layers: a "run-time" or real-time layer; and a "soft-time" or applications layer. The run-time layer is comprised of components of NEB software that respond to microprocessor interrupts. This layer services devices such as a timer, queued data transfer requests from the SCSI port, or LAN data through the protocol stack routine, and the CPSOCKET (to be discussed in section 4j below) communication mechanism.

The soft-time layer is arbited and controlled by the MONITOR program (to be discussed in section 41 below) which gets control of the NEB microprocessor 216 after all real-time events have been serviced. A non-preemptive (cooperative multi-tasking) approach is used to divide the processor between the various application modules that are loaded such that no one application module can preempt other modules by capturing the microprocessor.

The NEB EPROM 222 contains up to 256 KB of application module programs and NEB initialization code. At power-up or during a programmed reset, the NEB 2 executes a POST from the EPROM 222 before selectively transferring its EPROM code to NEB DRAM
220. If the POST is successful, the NEB 2 will load its protocol stacks and application modules into DRAM, and begin execution of its application modules.

In its basic configuration, the NEB 2 contains NetWare.RTM.-compatible application modules comprising embedded versions of two configurations: the Customized Remote Printer ("CRPRINTER"); and the Customized Print Server ("CPSERVER"). Preferably, the NEB acts in only one of these configurations at a time. Further, these application modules require that a network protocol stack be loaded and functioning within the NEB.

When configured with RPRINTER functionality, the NEB operates its printer as a slave to an external print server using a CRPRINTER module. In this configuration, the NEB exports to the LAN only limited printer status information in emulation of what the standard Novell print server expects from a standard Novell RPRINTER. However, extended status information about the printer will still be available if the CPCONSOL utility (discussed above) is executed in the network administrator's PC 14.

As mentioned above, the NEB 2 includes embedded software programs CPSERVER and CRPRINTER which enable the NEB to act with either PSERVER or RPRINTER functionality on the network. The customized NEB-embedded software which permits peripheral status and control information over the LAN is CPSOCKET (to be discussed in section 4j below). CPSOCKET runs on the NEB and monitors the LAN for communications addressed to both the NEB 2 and the attached printer 4. Further, CPSOCKET communicates with CPINIT and CPCONSOL when they are running. CPSOCKET will maintain a table of default settings for the device environment, download basic configuration information (fonts and emulations) at power-up, provide device information, statistics, and log information for CPCONSOL displays, and provide reset, reboot, and download capabilities. CPSOCKET will also be responsible for the configuration of the NEB 2. Further, CPSOCKET will configure and activate applications on the NEB at the request of CPINIT. CPSOCKET also insures that the correct protocol stacks are available for each configured application. CPSOCKET will handle the settings of the NEB 2 and the printer variables at the request of both CPINIT and CPCONSOL. Finally, the download facility (e.g. the network administrator's PC 14) will contact CPSOCKET to carry out any firmware downloading, such as flashing EPROM 222, that is required.

Upon initialization, programs such as CPINIT and CPCONSOL will issue a Service Advertising Protocol ("SAP") on the LAN looking for all network devices having the customized software of NEB 2. CPSOCKET will receive this broadcast signal and will respond. CPINIT or CPCONSOL then establishes a special connection with CPSOCKET using a customized client socket. CPSOCKET will then post multiple listens and will provide client service transactions such as NEB control, device information, basic configuration information, application information, statistics, and logging. For example, CPINIT can request that an application be configured, and CPCONSOL can request that an already-configured application be activated or deactivated. CPSOCKET will insure that the appropriate option (protocol stack) is available and configured for an application before allowing the application itself to be configured. Within the NEB, the CPSOCKET operational module is always activated.

Additional print service applications may be utilized after loading further application modules into the NEB, for example, UNIX print services and associated protocol implementation.

3d. PC-Resident Customized Software

To further enhance the functionality of the NEB 2, customized software is also provided to the network administrator's PC 14. For example, a Customized PCONSOLE ("CPCONSOL"; to be discussed in greater detail in section 4i below) utility provides extensions to Novell's PCONSOLE printer utility to enable access to the powerful control and monitoring features of the open-architecture printer 4. For example, the following are typical status control information available to the network from the printer through the use of CPCONSOL: (A) status and control information such as online/offline, no response, time/date/time zone, language, offsets, error skip settings, timer, buzzer enable, toner low, paper full, paper counter, count since last service, paper out, paper jam; (B) font information such as primary, secondary, graphic set, scaling, rotation, elite; (C) layout information such as page orientation, line pitch, character pitch; (D) quality and common environment information such as number of copies, overlay, job complete, command mode, default paper size, current paper size; and (E) configuration information such as interface, buffer size, feeder select, duplex print, page stack order, etc.

Furthermore, configuration data for the printer accessible to the network through the use of CPCONSOL includes: (A) network group information such as protocol type, the node name, the file server name, routing, POST error code, NEB firmware level, MAC address, server mode; and (B) printer group information such as safe (default) environment, font, disk present, disk size, initial environment, logging on/off, log file size, configured/nonconfigured, and net name. Additionally, logs can be kept of print job flow, print engine usage, and network behavior. Examples of such usage and statistical log entries include: (A) network group information such as receive statistics, transmit statistics, and non-media related information; (B) job entry information such as date/time/time zone, log-in (user's name), job name, pages, copy count, and print status; (C) initialization entry information; (D) error condition entry information; (E) clear log entry information; and (F) printer group information such as the number of jobs, pages/job, pages/minute, time/job, total pages/day, total jobs/day, number of days and total resets.

CPCONSOL is a menu-driven DOS executable program whose function is to provide extensions to the Novell PCONSOLE printer utility. The CPCONSOL extension enables access to the additional control and monitoring features of the open-architecture printer 4. These features will enhance print service management across the network by allowing the network administrator's PC 14 to control and maintain the printer from a remote location. In summary, CPCONSOL is the utility that exports printer control features to the network administrator, allows reconfiguration of the safe (default) environment, and allows the network administrator to view network and printer status, job statistics, and a log of the previously-processed jobs and error conditions. CPCONSOL gathers the requested information by communicating with the NEB-embedded software program module CPSOCKET.

Another customized software program resident on the network administrator's PC 14 is Customized Peripheral Initializer ("CPINIT"; to be discussed in section 4h below) which is also a menu-driven DOS executable program. The function of the program is to configure, reconfigure, and initialize the printer 4 attached to the NEB 2.

The CPINIT module will configure the NEB to act as a print server with one attached printer and specifies its primary file server by which the NEB will determine which queues to service. CPINIT is the program that supervises all like-customized devices on the LAN (e.g. other NEBs installed in other open-architecture printers). CPINIT accomplishes this task by communicating over the network with other NEBs that reside within open-architecture peripheral devices. CPINIT is used to configure each NEB with the appropriate basic configuration information such as configuring the NEB as CPSERVER or CRPRINTER. The basic configuration information comprises NEB environment settings (including which print server applications are active), as well as device environment options (e.g. a list of fonts and emulations to download printer initialization time), and device default settings (such as the internal device time/date/time zone, buffer size, disk and logging information, and printer name). The CPINIT program also displays status information about the NEB (such as the firmware level loaded in the NEB and reports latent POST errors).

The CPINIT program will broadcast over the network to see which other customized devices are available on the LAN. The NEBs attached to such other customized devices will respond with their identification numbers, their device types, and their configuration states. CPINIT will construct a list of these NEBs and devices that will be presented to the netwrok administrator to allow their configuration or reconfiguration.

A DOWNLOADER program may also be loaded into the network administrator's PC 14 to download executable files to the NEB across the network (to be discussed in greater detail in section 4n below).

Another customized program which may run on the network administrator's PC 14 is CPFLASH which may be used to remotely flash new firmware into EPROM 222, as will be discussed in greater detail in section 4q below.

4. OPERATION

At first, an overview discussion of the NEB structure and functions will be provided with respect to the flowchart of FIGS. 5A, 5B and 5C. Thereafter, more detailed descriptions of various aspects of the NEB hardware and software will be provided with respect to sections 4a to 4q.

The present invention takes advantage of the bi-directional nature of the communication between the printer and the NEB, and the NEB's ability to process information on a multi-tasking basis. That is, the bi-directional SCSI bus can transmit large quantities of data both to and from the printer, enabling the NEB to receive large quantities of specific status data from the printer or even data input from the peripheral (such as image data input from a scanner). The NEB microprocessor processes information on a multi-tasking basis (sequential but shared) effectively parallel processing information received from the network and information received from the printer. This multi-tasking processing insures that the NEB is responsive to both the network and the printer on a near real-time basis.

FIGS. 5A, 5B, and 5C comprise a top-level flowchart depicting a notional sequence of events which may occur when the NEB and its associated software is installed in a printer coupled to a local area network. Overall, the printer renders print information and is coupled to the NEB through a bi-directional SCSI interface. The printer may also have a parallel port and/or a serial port for receiving print information from other sources. The NEB is connected to the printer via the bi-directional SCSI interface, the board receiving printer information from the local area network. The board sends print jobs and printer status inquiries to the printer over the SCSI interface, receives printer status from the printer over the SCSI interface, and reports printer status over the network.

Where the NEB is coupled to a data generating device such as a scanner, the board is connected to the scanner through the bi-directional SCSI interface and is coupled to the network via the LAN interface. The board receives status request information from the network and will pass this information to the scanner over the bi-directional interface. The board will also receive the data generated by the scanner over the bi-directional interface, and will pass that data onto the network over the LAN interface.

Illustrating a sequence of events which may occur when the NEB is installed in a printer, FIG. 5A begins when power is applied to the NEB at Step S1. At Step S2, the NEB executes a power-on-self-test ("POST") from EPROM 220. At Step S3, if the POST is successfully completed, the process moves to Step S5 where the NEB EPROM 222 operational code reads the network and printer configuration code from NVRAM 228. If the POST is not successfully accomplished at Step S3, a failure indication is logged at Step S4 and this information may be transmitted to the network over the LAN interface. An LED failure/diagnostics light on the NEB or printer may also be activated.

After the network and configuration code have been read from NVRAM 228, the procedure advances to Step S6 where the NEB EPROM operational code reads selected configuration modules, protocol stacks, housekeeping modules, etc., (e.g., the MONITOR multi-tasking module, CPSOCKET, CPSERVER, etc.) from EPROM 222, and downloads the selected modules to DRAM 220. In Step S6, a configuration is selected (in accordance with the configuration set by CPINIT) which defines an operational mode (e.g. CPSERVER or CRPRINTER) of the interactive network board. As will be discussed in greater detail in section 4d below, a binary configuration code is sent over the LAN and stored in NVRAM 228. After the NEB is booted up, the configuration code is read from NVRAM using ROM-resident power-up process steps. Using the ROM-resident process steps, ROM-resident executable modules are selected in accordance with the configuration code read from NVRAM. The modules are selected in bit-wise correspondence to the binary digits of the configuration code in NVRAM. The selected modules are then stored into DRAM and execution control for the modules is passed to DRAM whereupon the selected modules are executed. In this manner, multiple configurations can be defined and selectively changed.

At Step S7, the EtherNet frame type of the information packets transmitted on the LAN is determined (as will be discussed in greater detail in section 4e below). That is, EtherNet supports four different frame types: EtherNet 802.3; EtherNet II; EtherNet 802.2; and EtherNet SNAP. To determine the EtherNet frame type, a pre-scan process ("PRESCAN") determines what frame type is resident on the LAN (from any LAN broadcast data), and configures the appropriate NEB-resident protocol stack for that data. The pre-scan process strips away bytes of data from a received LAN packet until the bytes which indicate frame type are reached. Briefly, Step S7 provides the NEB with the capability of processing LAN packets of different frame types by: receiving from the LAN a frame of data, pre-scanning the frame to determine the frame type, and processing, on the NEB, the identified frame, using an appropriate processing program. The pre-scanning operation includes the sub-steps of stripping a predetermined number of bytes from the head of the frame, processing the stripped frame to identify an identification code indicative of the frame type, and transmitting the identified frame to the processing program.

At Step S8, a timer module which was downloaded in Step S6 finds the nearest LAN server and requests the current time. After receiving the current time, the process proceeds to Step S9 where it is determined whether it is midnight, i.e. whether the returned time indicates a new date.

Steps S9 through S12 comprise a so-called "autologging" function which is carried out in the NEB by the CPSOCKET program in order to automatically and systematically provide status information from the printer to the LAN (autologging will be discussed in greater detail in section 4k below). In Step S9, if midnight has not been reached the procedure advances to Step S13. However, once midnight is reached, the NEB microprocessor 216 transmits a request to the printer over the SCSI bus for the printer to return current status to the NEB. For example, the printer may return the cumulative number of pages printed to the NEB. In Step S11, the NEB microprocessor 216 calculates printer statistics such as pages per job or pages per day, the NEB having kept track of the number of jobs sent to the printer and the date. At Step S12, the printer statistics are transferred to a non-volatile memory such as the printer's hard disk 114 or NVRAM 111, or the NEB's NVRAM 228. Alternatively, Steps S10, S11, S12 may be performed before Step S9, so that statistics are stored every minute.

Summarizing Steps S9 through S12, a method for logging system statistics of a printer connected via a bi-directional interface to an interactive network board for LAN communication includes the steps of counting in the printer the number of pages printed, and counting on the board the number of jobs printed. The printer is interrogated daily over the bi-directional interface for the number of pages printed, and the board then calculates daily statistics using the number of pages, the number jobs, and other status information. The daily statistics are then stored and may be accessed and remotely displayed using CPCONSOL from the network administrator's PC 14. An additional feature of the "autologging" function is that different levels of statistics may be logged. For example, at a basic level, only the number of pages for each job may be logged. At more advanced levels, the number of pages per job plus a log of failure conditions may be logged; or the job start and end times may be logged in addition to the failure conditions and the number of pages per job. The logging level is set by CPINIT.

In FIG. 5B, at Step S13, the SAPSERVER program (to be discussed in greater detail in section 4 g below) advertises the NEB as having both CPSERVER and CPSOCKET identities. Thus, the NEB and attached printer can function in its twin roles of PSERVER and customized entity (CPSOCKET; i.e., similar to other LAN peripherals having a NEB installed therein). SAPSERVER is a NEB-resident TSR program that allows more than one server to advertise network services at the same time on the same node. Thus, CPSOCKET and CPSERVER both advertise their services through SAPSERVER and respond to inquiries from other network applications. Since each EtherNet board can have only one SAP socket number, SAPSERVER will function to advertise both NEB identities without confusion to the LAN.

In summary, Step S13 is a method of identifying a single interactive network board as two network servers (e.g. CPSERVER and CPSOCKET) comprising the steps of transmitting to the network at a predetermined time interval a signal indicating that the board is a first type of network entity, the signal including an identification signal unique to the board; then, transmitting a second signal to the network at the predetermined time interval to indicate that the board is a second type of network entity, the second signal also including the same unique identification signal. Once a signal is received from the network requesting that the board perform functions of one of the types of network entities, direct communication is established between the board (acting as the requested type of network entity) and the network entity which generated the request. When the direct communication is established, the NEB will utilize a new unique identification signal.

At Step S14, both the LAN and the SCSI interfaces are checked for data that is being directed to CPSOCKET (to be discussed in greater detail in section 4j below). The SCSI interface will typically have printer status data which is to be passed to the LAN in response to a previously-received request for status. CPSOCKET is the NEB-resident TSR program that responds to such requests for connection, requests for data download, or requests for services from remote utilities. CPSOCKET gathers information from the NEB or the printer, as needed, monitors requests to write to the log file, monitors application requests for device status, and maintains job statistics, as discussed above.

Briefly, the CPSOCKET program is a method of interfacing an interactive network board between the network and a peripheral device, comprising the steps of transferring a program from board ROM to board RAM for execution from the RAM; and monitoring, with the program, a board network interface to detect a network communication directed to the peripheral device. The program then commands the peripheral device to perform a function in response to the network communication, and monitors a board bi-directional peripheral interface to detect and store status information of the peripheral device. Finally, the program outputs the peripheral device status information onto the network through the network interface in response to another network communication.

In FIG. 5B, Steps S15 and S17 indicate "run-time" layer functions, and Step S20 represents a "soft-time" application layer. First, Step S15 determines whether data is being received over the LAN. When LAN data is received, the process proceeds to Step S16 and the software protocol type is determined (to be discussed in greater detail in section 4f below). For example, the Ethernet data received over the LAN may be one of the following software protocols: e.g. NetWare.RTM. over SPX/IPX; UNIX over TCP/IP; or Mac Systems 7 over AppleTalk. Basically, the software protocol type may be determined according to the frame packet type sensed in Step S7 above.

If CPSOCKET determines that LAN data is not being received in Step S15, Step S17 determines whether SCSI data is being received, and if SCSI data is being received, it is input from the printer in Step S18, and then stored in DRAM 220 in Step S19.

After the storing of printer data in Step S19, or if SCSI data is not being received in Step S17, the process proceeds to Step S20 where "soft-time" tasks are performed on a multi-tasking basis as controlled by a multi-tasking software program called "MONITOR" (to be discussed in greater detail in section 41 below). Step S20 is therefore a "background" process which runs concurrently throughout the flowchart depicted in FIGS. 5A, 5B and 5C. That is, whenever "soft-time" tasks are being performed, the microprocessor 216 will ensure time-shared, parallel, non-preemptive processing of the "soft-time" tasks.

More particularly, MONITOR is a software module downloaded from EPROM 222 to DRAM 220 in Step S6. MONITOR is a non-preemptive multi-tasking monitor which distributes the processor usage among the several application tasks which are currently active. The non-preemptive nature of the monitor requires that each application task periodically relinquish control so that other tasks gain the opportunity to execute. The relinquish control mechanism is implemented using a software interrupt to pass control to the MONITOR. At an interrupt, MONITOR saves the state of the current task, restores the state of another active task, and resumes (or commences) execution of the new task. The task which originally relinquished control eventually regains control at the interrupt point, i.e. with its context restored to the same condition as when it relinquished control.

In summary, Step S20 comprises-the step of monitoring a plurality of application tasks in a multi-tasking interactive network board to distribute processor resources. A memory stores a first application task which may queue a file server to get a network interface to obtain a queue of print files to be printed, and which channels the print files to a printer coupled to the board through an interface. The memory also stores a second application task which may receive remote status inquiries over a LAN interface, interrogate the printer over a bi-directional interface to obtain printer status and a response to the received status inquiry, and provide the status information over the LAN interface to the status requester. The first and second application tasks each include a relinquish command which causes the currently executing application task to periodically relinquish control to the MONITOR. The MONITOR saves the state of the relinquishing task, restores the state of the non-relinquishing task, and resumes execution of the non-relinquishing task.

In FIG. 5C, presuming that data has been received over the LAN at Step S15, Step S21 determines whether the received data is for a print job or not. If it is for a print job, microprocessor 216 acts as the LAN file server for an active print file and transfers print job blocks to DRAM 220 at Step S22.

At Step S23, microprocessor 216 assembles blocks of image data and control information, and sends the blocks to the printer through the SCSI interface. In this step, the microprocessor 216 effectively adds "beginning of job" and "end of job" indications to the data stream received over the LAN. It does this by opening the XP (data) channel at the beginning of a print job, and by closing the XP channel at the end of a print job.

At Step S24, the process waits until the print job is complete. Once the print job is complete, Step S25 will unambiguously set the printer to a default environment. It is also possible to set the default configuration before (or during) the print job. That is, the NEB itself will ensure that the attached printer is set to a default environment which specifies, for example, default fonts, papers trays, collation, stapling, etc., to insure that the next print job will be started with the printer in a known configuration (to be discussed in greater detail in section 4m below).

Step S25 may be thought of as guaranteeing a safe environment for the printer by ensuring that the printer settings (e.g. portrait mode, duplex, etc.) are returned to between logical printing jobs. For example, while Novell NetWare.RTM. includes the ability to prefix every job with printer escape sequences to reset the printer environment, such escape sequences reside in a database on the network file server, and the print job in question might not originate from that file server. In order to ensure a guaranteed safe environment, the NEB will store the requisite configuration parameters, and will be responsible for resetting the printer environment between print jobs.

In summary, a method for providing a default configuration to a LAN printer having an interactive network board coupled thereto includes the step of receiving a default configuration over a LAN interface at the interactive network board. The default configuration may be stored in NVRAM 228 in the NEB or stored in an NVRAM or disk in the printer over the bi-directional interface between the board and the printer. Then, the default configuration is downloaded from the NVRAM in the printer to the DRAM 220 on the board over the bi-directional interface. When the board receives print information over the LAN interface and provides the print information to the printer over the bi-directional interface, the board detects an end of print job. In response to this detection, the default configuration is sent to the printer whereby the printer is set in its default configuration.

Additionally, a plurality of default configurations may be stored, and an appropriate default configuration may be selected remotely from another LAN entity. For example, a method of setting one of a plurality of default configurations may include a step of detecting, at the board, the origination of a print job and identifying the source of the job. Subsequently, an appropriate default configuration is selected from among the stored configurations, and the selected default configuration is then sent to the printer at the beginning or end of the print job.

In FIG. 5C, if it is determined that a print job is not required at Step S21, Step S26 determines whether a status request has been made over the LAN requesting the status of the attached printer. If it is determined that a status request has been received, Step S27 determines the type of status request. For example, printer status such as error codes, the number of pages printed, the toner status, etc., may be requested.

At Step S28, the microprocessor 216 retrieves the requested status data from DRAM 220, assembles the status data, and sends it to the LAN through the LAN interface (to be discussed in greater detail in section 4i below). Thus, in Step S28, more than simple "on/off" information may be transmitted to the LAN so as to inform the LAN of the detailed status of the printer. In a broad application, Step S28 encompasses the export of printer front panel status over the LAN, and the import of front panel control commands from the LAN. That is, the network administrator at the PC 14 may request and receive a display indicating all of the printer information included on the printer front panel display 116. The network administrator may then activate different printer front panel functions on his/her PC, and such functions will be transmitted to the printer where the selected control will be effected.

In summary, at Step S28, a method for remotely controlling a manually-operable function of a networked printer through an interactive network board having a LAN interface for LAN communication, comprises the step of issuing, at a remote location, a command to the board that will cause the board to transfer printer status information through the board to the remote location through the LAN interface. At the remote location, a printer status may be displayed, and a second command may be issued at the remote location to the board through the LAN interface to cause the board to perform a manually-operable function.

If the received LAN data is neither a print job nor a status request, it is determined at Step S29 that the received data may be a download operation, i.e., a transfer of data into the NEB for updating the ROM or RAM applications, e.g. download may be utilized for transient diagnostics to be run on the NEB.

First, at Step S30, the data is downloaded from the LAN to the DRAM 220 (to be discussed in greater detail in section 4n below). That is, the download is a process by which data may be loaded into a network node and then acted upon or executed. For example, anything from patch code, to manufacturing test routines, to firmware updates for the EPROM may be downloaded. Also, application modules may be stored in the LAN file server and then downloaded to the NEB every morning.

In summary, the downloading of data from LAN to DRAM comprises a method for altering an operational mode of an interactive network board having a LAN interface, including the step of activating a LAN communication program for execution from DRAM, the communication program channelling print information on the LAN to a peripheral printer. Executable instructions which correspond to the altered operational mode are then downloaded into DRAM via the LAN interface. The board is then commanded via the LAN interface to begin execution of the altered operational mode.

At Step S31, it is determined whether the downloaded information is destined for EPROM 222 or DRAM 220. If the information is destined for EPROM, a ROM image is assembled at Step S32 (to be discussed in greater detail in section 40 below). For example, downloading of EPROM firmware from a remote location provides unique flexibility. In particular, downloading of on-board test routines, and changing EPROM configuration firmware can be performed from a remote location after the board is installed in the printer.

Step S32 is the process which constructs the binary image file which is to be programmed into the EPROM 222. The data destined for the EPROM is first downloaded to DRAM 220 where a utility reads a configuration file containing the names of the modules to be placed in the ROM image. Then, a complete binary image file is constructed containing all of the specified modules. A header precedes each module in the image, the header identifying the module, describing its attributes, and pointing to the succeeding header to aid in locating the modules during loading. The last module loaded in the EPROM is the EPROM-resident code. It is placed at the end of the ROM image so that the power-up initialization code resides at the address expected by the microprocessor 216.

In summary, Step S32 comprises a process for formatting a binary image file which contains executable code modules for storage in the EPROM. First, a configuration file is read which specifies the code modules which form the binary image. Next, a header is formed for each module specified in the configuration file, the header including an identification of the module, a definition of the module's attributes, and a pointer to a header for a succeeding module. The binary image file is then constructed containing the specified modules and their associated headers. Finally, a module of ROM-resident code is appended to the binary image, the ROM-resident code receiving control at power-up, providing POST, loading at least some of the modules from the binary image file into DRAM 220, and providing basic board I/O services.

Before writing new data into EPROM 222, it is first necessary to unequivocally ensure that a write operation is, in fact, intended. Obviously, any accidental writings into EPROM 222 could render the NEB unusable. Therefore, before information may be "flashed" to EPROM 222, a specified sequence of events will occur in Step S33 in order to access the EPROM (to be discussed in greater detail in section 4p below). In the present embodiment, unless two data bits are changed in two separate I/O locations, the +12 Volts necessary to write to the EPROM will not be provided.

Briefly, a method of ensuring that the EPROM is not accidentally written into comprises a method of performing a flash operation on an EPROM resident on an interactive network board having a processing unit and a memory, including the step of sending an I/O write signal to the processing unit. Then, the processing unit generates a first address in the memory to cause a first bit to be in a predetermined state in response to the I/O signal. A power unit is then caused to provide +12 Volts to a transistor in response to the first bit being placed in the predetermined state. Then, an I/O receive signal is sent to the processing unit which generates a second address in the memory to cause a second bit to be in a preselected state in response to the I/O receive signal. Then, the transistor is turned on in response to the second bit being placed in the preselected state causing the +12 Volts to flow to a power terminal of the EPROM, allowing a write operation to take place.

Before the new ROM image is actually stored in EPROM 222, at Step S34 the new ROM image must be checksummed and verified with a checksum value sent after the ROM image is received. Prior to erasing EPROM 222, data and modules to be preserved, such as the MAC address, must be loaded into DRAM 220 within the new ROM image.

After determining that the ROM image is verified and after preserving all required data into the new ROM image stored in DRAM 220, it is necessary to clear and erase EPROM 222 to ensure corruption of data upon loading of the new ROM image. Accordingly, at Step S35, EPROM 222 may be erased a plurality of times before the new ROM image is stored therein.

After erasing EPROM 222 at Step S35, the new ROM image is "flashed" into EPROM 222 in Step S36 (to be discussed in greater detail in section 4q below).

In summary, Step S36 relates to a method for remotely altering programmable firmware on an interactive network board having a LAN interface including the step of activating a LAN communication program for execution from DRAM on the board, the communication program channelling print information on the LAN to a peripheral printer. A ROM firmware image is then downloaded to the DRAM on the board via the LAN interface. It is next confirmed that the ROM image has been downloaded to the target board, and the integrity of the ROM image is confirmed. The board is then commanded to electronically erase the EPROM, and then the EPROM is flashed with the new ROM image. Additionally, a "flash complete" signal may be sent to the LAN after the flash operation, if desired.

After the information is flashed to the EPROM 222, the NEB is then re-booted from the new ROM firmware image in EPROM 222 at Step S37, and the process returns to Step S1.

In FIG. 5C, if Step S31 determines that RAM information is being downloaded, such information is first assembled in DRAM 220 via Step S38. Subsequently, Step S39 executes the RAM program, and the process returns to Step S13 wherein SAPSERVER advertises PSERVER and CPSOCKET entities.

This discussion concludes the overview of the NEB structures and functions when the NEB is installed in LAN-networked printer. A more detailed description of the operation of various aspects of the NEB hardware and software will now be provided.

4a. Power-On Sequence

Immediately following power-on, NEB 2 executes a power-on self test (POST), following which the NEB loads operational software from EPROM 222 into DRAM 220 for execution.

More specifically, immediately following power-on, microprocessor 216 accesses POST program modules located in EPROM 222. Microprocessor 216 executes POST directly from EPROM 222 to test the functionality of the microprocessor, integrity of the programs stored in EPROM 222 (for example, via checksum verification), operability of DRAM 220 (for example, through read/write cycles), operability of SCSI controller 224, data integrity of NVRAM 228, and operation of control register 230. POST may also include a comparison of the MAC address stored in PROM 232 with a MAC address downloaded into EPROM 222.

POST further includes operational checks of network-related hardware. More specifically, POST may include operability checks for SRAM 214 (for example, through read/write cycles), as well as a check of network activity to verify operation of network controller 206.

Operation of other hardware in NEB 2 may be determined directly through additional POST testing. In some cases, where it is not possible for microprocessor 216 to test operation of hardware directly, as in the case of connectors 202, 203 and
204, proper operation of that hardware may be implied through result codes received from direct testing.

Upon termination of POST, microprocessor 216 puts a checksum code onto serial port 218 and then enters a window of quiescent operation (for example, a one second window) during which microprocessor 216 can receive commands (e.g. for testing--see paragraph 5 below) via serial port 218. The POST checksum code may be obtained by a device coupled to serial port 218 to determine the outcome of POST. For example, a no error condition may be indicated by a POST checksum code of "0000h", while a POST checksum code indicating an error may be indicated by a non-zero hexadecimal value which indicates the area of failure. In the case of failure, microprocessor 216 may also illuminate LED 240 on NEB 2 to signal to a user that an error has been detected. Preferably, LED 240 is illuminated on power-up and is only turned off if POST is successful.

Following successful completion of POST and in the event that no commands are received via serial port 218 during the one second quiescent window of activity, microprocessor 216 begins to load software modules stored in EPROM 222 into DRAM 220. Microprocessor 216 does not execute those software modules directly from EPROM 222, but rather loads those modules into DRAM 220 for execution from DRAM 220. By virtue of this arrangement, it is possible to select the specific modules that are retrieved from EPROM 222 for execution out of DRAM 220 so as to permit flexible configuration of NEB 2 (see section 4d below). For example, in accordance with a configuration command stored in NVRAM 228, microprocessor 216 may retrieve selective modules from EPROM 222 for loading into DRAM 220 and for execution from the DRAM.

FIG. 6 shows the sequence by which different modules are retrieved from EPROM 222 and loaded into DRAM 220. In Step S6001, microprocessor 216 loads the SCSI driver from EPROM 222 into DRAM 220. The SCSI driver provides for operational sequence and control over SCSI controller 224 and permits interface with printer 4 so as to send printer 4 print data and so as to send and receive control information to and from printer 4.

In Step S6002, microprocessor 216 loads the link support layer, or "LSL", from EPROM 222 into DRAM 220, and in Step S6003 microprocessor 216 loads network driver software from EPROM 222 into DRAM 220, and thereupon microprocessor 216 begins to execute the link support layer and the network driver from DRAM 220. The link support layer and the network driver provide common access to LAN communications on LAN bus 6. More particularly, as shown in FIG. 7, all networked devices, including a device such as NEB 2, interface with LANbus 6 via an electrical interface 301 such as the network controller 206 used on NEB 2. The electrical interface 301 is driven by network driver 302 which in turn receives LAN frame data from link support layer software 304. Both the link support layer 304 and the network driver 302 are common to different kinds of network software. For example, as further shown in FIG. 7, network application programs, such as those provided in NetWare.RTM. software by Novell (as illustrated at Arrow A) interface with the link support layer and the network driver via an internetwork packet exchange program, or "IPX", 305 and a sequenced packet exchange program, or "SPX", 306. On the other hand, network application programs from UNIX provided by AT&T (as illustrated at Arrow B) interface to the LSL through "IP" module 315 and "TCP" module 316.

In NEB 2, only one type of network application programs is normally executed at any one time (although multiprotocol operations are possible as discussed in section 4f below). Explanation here will be made for NetWare.RTM. network application programs although it is also possible for UNIX network application programs to be executed as well.

In Step S6004, microprocessor 216 loads a PRESCAN program from EPROM 222 and stores it into DRAM 220, and thereupon begins executing the PRESCAN program from DRAM 220. PRESCAN software interfaces with the link support layer to determine the frame packet type being transmitted on LAN bus 6. More particularly, as described above, there are four different possible frame packet types on an Ethernet-type network LAN bus: Ethernet 802.3, Ethernet II, Ethernet 802.2, and Ethernet SNAP. As described more fully below in section 4e, the PRESCAN software module monitors network communications on LAN bus 6 to determine the frame packet type. The frame packet type, once determined by PRESCAN, is stored in a predetermined common location in DRAM 220 for use by other network communication modules in the NEB. After determining the frame packet type, PRESCAN signals microprocessor 216 that its tasks are completed and allows microprocessor 216 to overwrite the memory occupied by the PRESCAN program with another program module.

In Step S6005 microprocessor 216 retrieves the IPX and SPX program modules from EPROM 222 and stores them in DRAM 220, and thereupon begins executing the IPX and SPX modules from DRAM 220. Both IPX and SPX use the frame packet type determined by the PRESCAN module.

In Step S6006 microprocessor 216 retrieves the CNETX program module from EPROM 222 and loads that module into DRAM 220 and thereupon begins execution from DRAM 220. CNETX provides localized DOS-like functionality to the NEB.

In Step S6007, microprocessor 216 loads the SAPSERVER program module from EPROM 222 into DRAM 220 and begins executing the SAPSERVER module from DRAM 220. As described more fully below in section 4g, SAPSERVER is a program module which allows two network server entities, such as CPSOCKET and CPSERVER, to advertise simultaneously from the single network node assigned to the NEB board, even though conventional network application programs such as those provided by NetWare.RTM. only permit advertising of a single network server entity from each network node.

In Step S6008 microprocessor 216 retrieves the non-preemptive multi-tasking MONITOR (see section 41 below) from EPROM 222 and stores it into DRAM 220 and begins executing the multi-tasking monitor from DRAM 220.

In Step S6009 microprocessor 216 retrieves the CPSOCKET server software module from EPROM 222 and loads it into DRAM 220 and begins executing the CPSOCKET server from DRAM 220. As will be described more fully below in section 4j , CPSOCKET initiates a request to SAPSERVER to advertise on behalf of CPSOCKET, and SAPSERVER begins making SAP advertisements on LAN bus 6.

In Step S6010 microprocessor 216 retrieves print application servers such as CPSERVER or CRPRINTER from EPROM 222 and loads the print application servers into DRAM 222. In the case of CPSERVER, microprocessor 216 begins executing the loaded print application servers from DRAM 220 which in turn requests SAPSERVER to make SAP advertisements on behalf of the print server. As described more fully below in section 4g, SAPSERVER interleaves advertisements for the CPSOCKET server and for the print server thereby acting as a surrogate SAP entity for both the CPSOCKET server and the print server.

4b. Interfacing A Peripberal With A Local Area Network

According to the broad aspects of the present invention, a peripheral such as a printer is coupled to a LAN using an interactive network board having software programs embedded therein. Preferably, the connection between the printer and the NEB is an SCSI interface so that large amounts of print data and status data are carried bi-directionally between the NEB and the printer. EPROM 222 stores a plurality of software modules for operationally configuring the NEB in the PSERVER or RPRINTER or LPR functional configurations. The EPROM 222 also stores a number of status control software modules for exporting status information from the printer over the LAN, and for importing control information from the LAN to the printer. The EPROM-resident firmware is downloaded to the DRAM 220 upon power-up (as discussed in section 4a above), whereby the MONITOR multi-tasking program executes soft-time tasks until run-time interrupts are received from either the LAN or SCSI interfaces.

NVRAM 228 stores a configuration word which specifies which modules stored in EPROM 222 should be downloaded into DRAM 220 in order to configure the NEB with either a PSERVER or RPRINTER functionality. The microprocessor 216 executes the programs from DRAM 220, allowing print jobs to be received from the LAN and sent to the printer for printing, and allowing printer status to be returned over the LAN in response to a status request.

The particular details of the structure and functions for interfacing the peripheral to the local area network are set forth above with reference to FIGS. 4, 5A, 5B and 5C, and in the following sections.

4c. The Bi-Directional Interface Between The Local Area Network And The Printer

The provision of a bi-directional SCSI interface between the NEB 2 and the printer permits a large amount of status information to be extracted from the printer, while still providing the print data to the printer. Further, by utilizing the bi-directional SCSI interface, the printer can respond to control commands issued from a remote location over the LAN. For example, the network administrator may issue a control command from his/her PC 14 that requests a particular print job be printed a plurality of times, with high image density, and then stapled. Such control commands are sent to the NEB 2 over the LAN 6, and the NEB 2 transmits these control commands to the printer through the SCSI bus 102. At the same time, the actual print data is transferred from file server 30 to the NEB 2, where the print data is packaged in blocks and transferred to the printer over the SCSI bus 102. Preferably, the NEB 2 indicates the "start of print job" by opening the XP data channel to the printer. Likewise, the NEB 2 indicates "end of print job" by closing the XP data channel to the printer. Therefore, the NEB 2 can provide such indications to the printer.

The use of the bi-directional SCSI interface on the NEB 2 also permits other types of peripherals to be coupled to the LAN. For example, since the SCSI interface is capable of transmitting large quantities of data to the LAN from the peripheral, it is possible to couple the NEB to an image data generating device such as a scanner (e.g., where printer 4 is an Optical Character Recognition ("OCR") device) or a facsimile machine. Thus, data produced by the image generating device may be transferred to the NEB over the SCSI interface, and then put on the LAN for storage or retrieval by any of the LAN entities. As with a printer, large quantities of detailed control/status information can also be provided to/from the image data generating device.

The detailed structural and functional features of the bi-directional SCSI interface on the NEB are set forth above with reference to FIGS. 4, 5A, 5B and 5C, and in the following sections.

4d. ROM Firmware configuration

As described earlier with respect to FIG. 5A, Step S6 downloads selected software programs from EPROM 222 to the DRAM 220 for execution (see also FIG. 6 and section 4a). The EPROM 222 is delivered with firmware modules which permit the NEB 2 to be configured with either RPRINTER or PSERVER functionality. Therefore, the functionality of the NEB 2 will be determined by which of the stored programs are downloaded from EPROM 222 to DRAM 220 in accordance with the configruation code stored in NVRAM
228.

The NEB 2 firmware is configured initially, and can be reconfigured subsequently by running CPINIT on the network administrator's PC 14 (see section 4h below). However, even in an unconfigured state, NEB 2 itself will always activate those software modules needed to perform basic communication with the LAN. Using CPINIT, the network manager can determine, remotely, the current configuration of the NEB, or he/she can change the configuration as desired. Since the configuration information is stored in EPROM on the NEB board, the configuration information is retained across power cycles.

The process by which the software programs for a particular configuration are downloaded from the EPROM 222 to the DRAM 220 will be described below with respect to FIG. 8.

After the board has been powered up at Step S1, the process proceeds to Step S8001 where microprocessor 216 accesses EPROM-resident code in the EPROM 222 to read a configuration code (typically a word) from NVRAM 228. The configuration code will specify modules which can provide the NEB with either a PSERVER or RPRINTER functionality. Although the present embodiment includes only RPRINTER or PSERVER functional configurations, other configurations may be utilized where, for instance, the NEB 2
is installed in a different LAN entity, such as a scanner or a facsimile machine.

After reading the configuration code from NVRAM 228, the microprocessor, at Step S8002, forms a configuration mask whose bit pattern corresponds to the read configuration code. At Step S8003, a loader module resident in EPROM 222 compares the configuration mask to the plurality of firmware modules stored in the EPROM 222.

In detail, in Step S8004, a process begins whereby the EPROM-resident software modules are selected in bit-wise correspondence to the binary digits of the configuration code read from NVRAM 228. If it is determined in Step S8004 that the currently-examined bit of the bit pattern matches a stored module, then that module is selected (at Step S8005) for downloading to DRAM 220, and the process skips to the next bit at Step S8006. Likewise, if Step S8004 determines that a bit of the bit pattern does not match the stored module, the process skips to the next bit at Step S8006.

At Step S8007, it is determined whether the bit tested in Step S8004 is the last bit of the configuration mask bit pattern. If the tested bit is not the last bit, the process loops back to Step S8004, where the next bit of the bit pattern is tested with respect to the next stored module. When the last bit of the configuration mask bit pattern has been tested, the selected software modules are downloaded from EPROM 222 to DRAM 220 at Step S8008.

In the present embodiment, the software modules are loaded in the following sequence: SCSI Driver; Link Support Layer; Network Driver; Prescan; IPX/SPX; CNETX; SAPSERVER; MONITOR; CPSOCKET; and Print Applications (e.g CPSERVER, CRPRINTER) (see FIG. 6).

After all of the software modules which correspond to the configuration codes stored in NVRAM 228 have been downloaded to DRAM 220, the loader function will pass program execution control to the MONITOR multi-tasking program at Step S8009.

As discussed earlier, the configuration code stored in NVRAM 228 may be remotely altered using CPINIT. This provides greater flexibility for making minor modifications to CPSERVER or CRPRINTER, or where entirely new configurations are desired to be set. Therefore, at Step S8010, a new configuration is received over LAN 6, and is loaded into NVRAM 228 at Step S8011. Preferably, the old configuration code will be erased or overwritten with the new configuration code. Then, the NEB re-boots itself and returns to Step S1.

4e. Determining Frame packet Type Using PRESCAN

On any local area network, data is transmitted between network devices in packets or frames. But even in the context of a common network architecture, such as Ethernet, more than one format for the frame may be supported. Thus, even though it is known that Ethernet architecture is being used, it is not possible to determine the arrangement of data within each physical frame or packet of information on the Ethernet bus. In particular, as described above, Ethernet supports four arrangements of data, or formats, as follows: Ethernet 802.3, Ethernet II, Ethernet 802.2, and Ethernet SNAP.

In conventional network devices, which provide for a manually selectable operator interface, it is possible to advise the network device of the particular frame type being used on the Ethernet network. In the context of NEB 2, for which operator access is provided only via the network interface (or via the serial port 218 in a test configuration), it is not possible to set the frame packet type without first allowing operator access to the local area network which, of course, requires knowledge of the frame packet type.

The PRESCAN software module allows NEB 2 to automatically determine the frame packet type currently being used for LAN communication on the LAN bus by monitoring broadcast communications on the LAN bus until the proper frame packet type is recognized. PRESCAN makes this determination based on recognizable components that are common to all four frame packet types used on Ethernet.

In more detail, FIG. 9 shows the physical construction of different frame packets used on Ethernet. As shown in FIG. 9, a physical frame being transmitted on the LAN bus includes a 6-byte section 412 for storing the destination MAC address, and a 6-byte section 413 for storing the source MAC address. These 12 bytes comprise the first 12 bytes of LAN data packets regardless of the frame type being used for LAN communication. A data section 414 follows these 12 bytes. The data section is comprised of a variable number of bytes which are not used for the same purposes by the different frame packet types and which do not have the same number of bytes for the different frame packet types.

Following the indeterminate area 414, the LAN communication packet includes an IPX header 415 the first two bytes of which always has the value "FFFF" (hexadecimal). The remainder of the packet 416 follows the IPX header and comprises the data and other commands which characterize each different type of LAN communication packet.

PRESCAN operates by monitoring the LAN communication in accordance with each of the different packet types until the common area (such as IPX header 415) is recognized in one of those packet types. PRESCAN then stores that packet type for use by other network communication programs.

FIG. 10 is a detailed flowchart for showing operation of the PRESCAN module. In Step S1001, microprocessor 216 retrieves the PRESCAN module from EPROM 222 and loads it into DRAM 220 and thereupon begins execution of the PRESCAN module. The PRESCAN module is executed before the SPX and IPX modules, even if microprocessor 216 retrieves those latter modules from EPROM 222 and loads them into DRAM 220 before the operational sequence shown in FIG. 10 is complete. More particularly, proper operation of the SPX and IPX program modules depends upon the identification of the frame packet type by PRESCAN and therefore execution of SPX and IPX is deferred until after PRESCAN determines the proper frame packet type.

In Step S1002, PRESCAN simultaneously binds through LSL to all four frame packet types, namely, Ethernet 802.3, Ethernet II, Ethernet 802.2, and Ethernet SNAP. That is, PRESCAN configures LSL such that for each packet of LAN communication, LSL provides a data group corresponding to each of the four frame packet types. Thereafter, PRESCAN goes inactive pending reactivation by an interrupt from the network driver.

In Step S1003, the network driver monitors communications on the LAN bus for broadcast traffic. Broadcast traffic means that the destination MAC address 412 is unspecified or is given a global specification of "FFFFFFFFFFFF" (hexadecimal). The network driver continues to monitor communications on the LAN bus for broadcast traffic (Step S1004) until broadcast traffic is received, whereupon flow advances to Step S1005. In Step S1005, the MAC address fields 412 and 413 are stripped off the received data packet and the remainder of the data packet is provided to LSL. In Step S1006, LSL interprets the frame packet in accordance with each of the frame packet types and provides a data group in correspondence to each of the frame packet types. In Step S1007, the network driver reactivates PRESCAN which determines which data group provided by LSL has the proper first two bytes, of an IPX header, namely "FFFF" (hexadecimal). That is, because of the variable data area 414 (variable data area 414
corresponding to each of the different packet types (FIG. 9)), LSL will properly identify the IPX header 415 in accordance with only one of the frame packet types. In Step S1007, PRESCAN searches for the IPX header and, in accordance with which of the four data groups is provided by LSL, it is able to determine a frame packet type that is currently being used on the LAN bus.

In Step S1008 PRESCAN stores the corresponding frame packet type in a common area in DRAM 220 so that the frame packet type can be used by other network application programs such as SPX and IPX. Thereafter, in Step S1009, PRESCAN frees its storage area in DRAM 220 so that microprocessor 216 may overwrite that data area with other software modules, if desired.

4f. Multiprotocol Operation

In a multiprotocol operation, two different operating systems carry on LAN communications over a single local area network bus, but using respectively different operating protocols. For example, a Novell-compatible operating system communicates over a LAN bus using SPX/IPX operating protocol, while a UNIX-compatible operating system communicates over the LAN bus using a TCP/IP operating protocol. Other operating systems, such as the AppleTalk.RTM. operating system provided by Apple Corporation, use respectively different operating protocols for LAN communication over a single network bus in a multiprotocol network environment.

Ordinarily, NEB 2 is configured to communicate to a single network operating system, but it may also be configured to operate in a multiprotocol network environment, for example, a combined Novell/UNIX multiprotocol environment. In this configuration, NEB 2 includes a Novell-compatible peripheral server, such as the aforementioned CPSERVER, which checks job queues in a file server on a Novell operating system, as well as a UNIX-compatible peripheral server, such as the aforementioned CLPR (Custom Line Printer Remote), which, in coordination with checks made by CPSERVER, also checks for job queues in a file server for a UNIX operating system. Both servers, here CPSERVER and CLPR, service common peripheral resources, here a single peripheral such as a printer, and to avoid contention for control of the common resources, both servers are able to seize control of the peripheral to the exclusion of other servers, to signal other servers that control has been seized, and to relinquish control of the peripheral when the job queue has been emptied. It is also possible for each server to check with other servers to determine if other servers have a pending request for use of the peripheral. In the case where there is a pending request, the server can relinquish control of the peripheral at the end of a current job even though there are jobs remaining in the job queue, so as to allow alternating use of the peripheral by each server.

FIG. 11 illustrates NEB 2 configured for multiprotocol network operations. FIG. 11 illustrates a combined Novell/UNIX multiprotocol environment, but it is to be understood that other operating protocols may be substituted for or used in combination with those shown in FIG. 11. In FIG. 11, NEB 2 is interfaced to LAN bus 6 via electrical interface 321, network driver 322, and link support layer ("LSU") 324, much as illustrated above in FIG. 7. Novell-specific operating protocols are indicated at reference numerals 325, 326 and 327. More specifically, 325 and 326 are an SPX/IPX operating protocol stack (or tower) by which Novell-compatible applications programs communicate with the LAN bus through LSL. Novell-compatible applications programs, including a Novell-compatible server such as