Centralized queue in network printing systems

#The present invention is directed to a centralized queue for a network printing system that allows clients of the printer to make job requests and enter a spot in a job queue without transmitting the job print data to the network. More particularly, the present invention stores job information for all of the print jobs attempting to access a busy printer in the print queue so that the print jobs can be printed by the printer with a fair arbitration once the printer becomes available.

#As the size of networked systems increases from a few connected computers located near each other to several thousand machines of various types and sizes scattered at great distances from each other, the demands on the network printers also increase. One of the most challenging demands in the implementation of network printers is connectivity. Typically, the network printer is a stand-alone peripheral device which is desired to perform in an increasing number of network and non-network communication environments. In network environments, the printer is desired to provide “seamless plug and play” connectivity for the continuous expansion of network service protocol/ports. For example, known network service protocol/ports that are desired to communicate with network printers are: printer access protocol (PAP)/LocalTalk (aM); PAP/EtherTalk (EI); transmission control protocoVinternet protocol (TCP/IP); TCP/IP port 9100; “1pr”/TCP/IP; Novell remote printer or print server modes; bidirectional or unidirectional Centronics; AppleTalk Data Stream Protocol (ADSP)/EtherTalk; ADSP/LocalTalk; and Novell sequence packet exchange (SPX). These are just a few examples of the constantly increasing number of network protocol/ports that desire “plug and play” connectivity to the network printer.

#A printer is a peripheral device that can be shared on a network connected to a print server. Also, a printer can directly connect to the network by including a network interface card or the network interface into the printer which allows the printer to run its own print server software and function as a regular node. In a typical Windows environment, the network printer is a one-way printer. In a one-way printer, the only communication path is from the host computer to the printer. As a result, the data is sent from the host computer to the printer without any ability for the printer to notify the host computer of the job status such as whether the print job has been successfully completed.

#The present invention will become more fully understood from the detailed description given hereinbelow and the accompanying drawings which are given by way of illustration only, and thus are not limitative of the present invention, wherein:

#FIG. 1 illustrates a network using a conventional printing system;

#FIG. 2 illustrates the layers of the network architecture for an embodiment of the present invention;

#The embodiments of the present invention are directed to a network printing system which provides a print queue for storing job information of print jobs for requesting host computers without transmitting the actual job data. More particularly, the printing system queues job information from a wide variety of network protocol/ports in a print queue. Thereby, print jobs for all of the various network protocol/ports may be fairly arbitrated by the printer.

#In a preferred embodiment of the present invention, an imaging device protocol (IDP) provides an application layer network protocol that enhances the two way communication between a host computer and a network printer. IDP operates independently of the network layers below it and only requires that the transport protocol/port be bidirectional A wide variety of heterogenous network protocols may be supported by IDP which places all of the incoming print job information in the print queue regardless of the protocol. Print job information from both IDP and non-IDP protocol/ports may be placed in the print queue by emulating IDP on the non-IDP protocol/ports. By emulating IDP on the non-protocol/ports, every client will look like IDP clients to the printer and clients of non-IDP protocols will therefore be completely backward compatible. Although non-IDP clients will not be able to use all of the enhanced features provided by IDP, a sufficient amount of information will provided from the non-IDP protocol/ports so that all of the jobs in the print queue will be able to be fairly arbitrated. For example, complete job name information will not be provided to the print queue for non-IDP clients and only information that a print job has been sent from a particular port will be entered in print queue. Thereby, print jobs from non-IDP clients may be entered in the print queue without having to store the actual print job data at the printer. Accordingly, the printing system for the embodiments of the present invention enable a wide variety of heterogenous network protocols to be fairly arbitrated at the printer.

#In one example of a header format for IDP messages, the structure includes protocol,command, result code, message byte length, and data fields. IDP is a set of related protocols and the protocol suites are intended to map different cooperating servers that add value to a printing environment. A message can be initiated by either a host computer or the network printer. In a preferred embodiment of the present invention, IDP includes a core protocol, a print protocol, and a font protocol. The core protocol contains commands that are common to all servers and are independent of their type. Printers may support the print protocol and font servers may support the font protocol. Common printers maintain fonts locally and therefore support part of the font protocol as well. As new type of servers are identified, additional protocols can be added to the suite of related protocols for IDP. The protocol field indicates which protocol of the IDP suite that the message is intended for. The command field indicates which command that the message corresponds to. The result code is a result of the command that is ignored on request commands. The message byte length field is the number of data bytes in the message. The data field includes message specific data and parameters.