Abstract:
A plug and play interface for output device used in a distributed computer network includes a front end module which submits print jobs to a document processor module. The document processor module processes the print jobs and forwards the print jobs to a back end module, which directs the print jobs to the appropriate output devices. The plug and play interface allows for the addition of various output devices connected by various protocols by simply bringing into to the back end a shared library corresponding to the new output device. Thus, various output devices may be used without requiring any revision of or stopping the system.

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The invention relates to a plug and play interface for use in computers and computer networks. More specifically, the invention is directed to a generic interface for use with a number of different output servers/devices. 
     2. Description of the Related Art 
     As shown in FIG. 1, the basic conventional printing system  10  uses a client/server architecture that includes a client  20 , a server  40  and an output device  50 . The client  20  conveys print and management requests to the server  40  and receives responses from the server  40  that arise from the submitted requests. 
     The server  40  receives these requests from the client  20 , performs the required actions for each request, and returns responses to the client  20 . One such request from a client is a print request, i.e., a request to print one or more copies of one or more documents, with the printed pages output using one or more features. The features can include simplex or duplex printing, stapling or binding, etc. Thus, a print request represents a collection of one or more documents to be printed as well as instructions for printing. The server  40  organizes the documents and instructions indicated in the print request submitted by the client into a print job. The server then sends the print job and any associated job control commands to the output device  50 . 
     The output device  50  is a physical device or hardware that is capable of rendering images or documents and producing hard copy output of the print jobs received from the server  40 . The output device  50  can then return responses to the server  40  regarding its current state or the status of the received print jobs. The output device  50  is commonly a printer. 
     These conventional systems, however, are designed assuming only one type of output device will be used. Thus, if a different output device is to be used, the entire document processing system must be revised. Such revisions require a great investment of time and money to accomplish. 
     Furthermore, the conventional systems do not allow a new output device to be added without extensive revision of the system and thus, interruption of the system operation. 
     SUMMARY OF THE INVENTION 
     This invention provides simple, generic interfaces with plug-and-play capabilities so that changes in the output device may be accomplished without drastically changing the document processing system. 
     This invention further provides simple, generic interfaces with plug-and-play capability to facilitate bringing into a running system new output devices connected by various networking protocols such as tcp/ip, serial, parallel, SNMP, DPA, etc., without interruption of the system operation. 
     The server system and method of this invention includes a print spooler server and a print supervisor server. The supervisor has a front end module, a back end module and a document processor. The spooler receives print requests from a client. The spooler generates print jobs from the print requests and sends the print jobs to the supervisor. The front end module of the supervisor receives the print jobs from the spooler and submits them to the document processor. The document processor processes the print jobs and forwards the print jobs to the back end module. The back end module directs the print jobs to the appropriate output devices. 
     The method and apparatus of this invention allow various types of output devices to be interchangeably used by simple alterations of the resident shared libraries of the back end module, so that the resident shared libraries reflect the required functions and channels for the particular types of output devices. In this way, a new output device or a new type of output device may be added to the system without having to extensively revise the entire system and without having to interrupt the operation of the system. 
     These and other features and advantages of this invention are described in or are apparent from the following detailed description of the preferred embodiments. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The preferred embodiments of this invention will be described in detail, with reference to the following figures, wherein: 
     FIG. 1 is a block diagram showing a conventional printing system; 
     FIG. 2 is a block diagram of a simplified printing system of the invention; 
     FIG. 3 is a block diagram showing the interaction of the front end module, the back end module and the document processor; 
     FIGS. 4A-4O are diagrams showing examples of possible combinations of functions and channels for the back end resident shared libraries 
     FIG. 5 is a flowchart outlining one preferred embodiment of the operation of the front end module, back end module, and document processor according to the invention; and 
     FIG. 6 is a flowchart outlining in greater detail the destination location determining step of FIG.  5 . 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     As shown in FIG. 2, the printing system of this invention includes a network printing system  100  comprising a server system  400 . The server system  400  of the network printing system  100  includes a spooler server  410  and a supervisor server  420 . The spooler  410  receives print requests from one or more clients  200 , either directly or via any other source of print requests, such as a storage disk  300 . The spooler  410  converts the print requests into print jobs. 
     The supervisor  420  delivers data to the various output devices  500 . The supervisor  420  receives the print jobs from the spooler  410 , interprets the print jobs for print instructions and parameters, passes the print data, instructions and parameters to the appropriate output device  500 , and handles any responses made by the output device  500 . Multiple supervisors  420  can be supported by a single spooler  410 . The supervisor  420  can also receive client management requests that apply to the supervisor  420  or to the output devices  500 . 
     As shown in FIG. 3, the supervisor server  420  includes three major components, a supervisory front end (FE) module  422 , a document processor (DP)  424 , and document processor back end (BE) module  426 . 
     The supervisory front end module  422  manages all print jobs. The document processor  424  supports all of the physical output devices  500  connected to the server system  400 , accepts the print jobs from the front end module  422 , and directs the accepted print jobs to a specified job submission channel  4262 . The document processor  424  performs periodic job and output device  500  status queries and uses the query results to determine the appropriate time to request the next print job and to balance the load on each output device  500 . The document processor back end module  426  communicates with different job submission channels  4262 , job cancellation channels  4267 , job status query channels  4266  and device status query channels  4268 . 
     The document processor  424  then calls the job submission channel  4262  of the appropriate back end module  426  and forwards the print job to that back end module  426 . The back end module  426  can support multiple job submission channels  4262 . Thus, the back end module  426  prepares the print job and submits the job through the specified channel  4262 . 
     Upon receiving a call, the back end module  426  requests the document attributes and document data from the document processor  424 . Depending on the submission channel  4262 , the back end module  426  may map the print job attributes or document attributes into the submission channel&#39;s attribute format. The back end module  426  may also modify the document data to embed information in the document data. 
     The back end module  426  then determines the destination location and address of the appropriate output device  500  and forwards the print job to that output device. An example printer address format for the invention is “hostName, printerName, Extension”. The “hostName” is the machine name to which the output device is connected. The “printerName” is the name of the output device (printer)  500 . The “Extension” is used to distinguish different kinds of job attribute conversion formats. 
     If the back end module  426  is unable to retrieve the job identifier from the print server or output device  500  via the job submission channel  4262 , the back end module  426  will generate a unique job identifier for monitoring the job. The back end module  426  allocates the memory for output and assigns this token job identifier to it. The document processor  424  frees these memory resources when it is done with them. 
     The document processor  424  specifies the job submission channel  4262  used to submit the print job. This attribute is used in the future to check if the job query channel  4266  or the job cancellation channel  4264  is compatible with the job submission channel  4262  used. 
     The back end module  426  then notifies the document processor  426  which in turn notifies the front end module  422  that the print job is in a printing state. The back end module  426  queries the document processor  424  for any job attribute changes. 
     Before checking the job status, the back end module  426  checks if the print job identifier that was generated is valid for the querying print job. The back end module  426  performs this function by checking the job submission channel used to ensure that this back end job query channel  4266  perform further job status queries. 
     As shown in FIG. 3, the back end interface  425  is positioned between the document processor  424  and the back end module  426 . Each back end module  426  includes a shared library of function calls and callback functions that are used with one or more corresponding output devices  500 . Table 1 shows an example set of back end function calls. 
     
       
         
               
             
               
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 Back End Module Function Calls 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 BE_Initialize 
                 Initializes the back end shared 
               
               
                   
                   
                 libraries. 
               
               
                   
                 BE_Shutdown 
                 Shuts down the back end components and 
               
               
                   
                   
                 frees resources for reuse. 
               
               
                   
                 BE_ProcessJob 
                 Forwards a job to the back end. 
               
               
                   
                 BE_JobStatus 
                 Queries job status. 
               
               
                   
                 BE_DeviceStatus 
                 Queries device status. 
               
               
                   
                 BE_CreateDevice 
                 Creates and registers an output device 
               
               
                   
                   
                 in the back end module. 
               
               
                   
                 BE_DeleteDevice 
                 Deletes and unregisters an output 
               
               
                   
                   
                 device in the back end module. 
               
               
                   
                 BE_CancelJob 
                 Stops processing of the job and 
               
               
                   
                   
                 deletes the job object. 
               
               
                   
                   
               
             
          
         
       
     
     Table 2 shows an example set of callback functions that are invocable by the back end shared library that is resident on each back end module  426 . The document processor  424  implements all of the callback functions. 
     
       
         
               
             
               
               
               
             
           
               
                 TABLE 2 
               
               
                   
               
               
                 Back End Module Callback Functions 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 BECB_ReportEvent 
                 Informs document processor of 
               
               
                   
                   
                 an event. 
               
               
                   
                 BECB_GetDocumentAttrs 
                 Retrieves attributes of a 
               
               
                   
                   
                 document from the document 
               
               
                   
                   
                 processor. 
               
               
                   
                 BECB_GetDocumentData 
                 Retrieves document data from 
               
               
                   
                   
                 the document processor. 
               
               
                   
                   
               
             
          
         
       
     
     Each back end module shared library  428  may have many combinations of function calls, some of which are illustrated by FIGS. 4A-4O, necessary for a particular output device  500  or type of output device  500 . Every back end shared library  428  includes the function calls “BE_Initialize” and “BE_Shutdown.” An example of the function calls “BE_Initialize” and “BE_Shutdown” is set forth in Appendix A. 
     When a new output device  500  is to be brought into the system, the document processor module will load the corresponding shared library  428 . This procedure does not interrupt any operation of system  400 . 
     After loading the shared library  428 , the document processor checks if the access pointer of the shared library exists in a linked list. If not, the document processor  426  loads the shared library  428  and saves the access pointer of the shared library  428  in the linked list, and calls the function “BE_Initialize” of this shared library  428 . If the access pointer does exist, the document processor  424  simply reloads the shared library  428  without recalling the function “BE_Initialize”. 
     The document processor  424  initializes each back end module  426  only once when the corresponding shared library gets loaded into the supervisor server  420 . The document processor  424  initializes a back end module  426  by calling the function “BE_Initialize” and passing a set of callback function pointers to the back end module  426  so that the back end module  426  can communicate with the document processor  424 . These callback functions allow the back end module  426  to retrieve the document and document data from the document processor  424  and to report any asynchronous events back to the document processor  424 . Examples of callback functions are set forth in Appendix B. 
     FIG. 5 is a flowchart outlining one preferred embodiment of the operation of the front end module  422 , the document processor  424  and the back end module  426 . The control routine begins in step S 500  and continues to step S 510 . In step S 510 , the document processor  424  receives a call from the front end module  422  to create a printer object. Then in step S 520 , the document processor  424  registers an output device  500  and loads the shared library  428  for that output device  500 . Next, in step S 530 , the back end module  426  establishes the output device connection, including the job submission channels  4262 , the job cancellation channels  4264 , the job query channels  4266  and the device query channels  4268 . 
     In step S 540 , the document processor  424  then determines if the output device  500  is in a correct state to process the print job. If the output device  500  is not ready, control loops back to step S 540 , and continues in this loop until the print device  500  is ready. Once the print device  500  is ready, control continues to step S 550 . 
     In step S 550 , the front end module  422 , via the document processor  424  forwards the print job to the back end module  426  via a job submission channel  4262 . The desired job submission channel  4262  is identified in the shared library of the back end module  426 . The back end module  426  can support multiple job submission channels  4262 . Thus, the back end module  426  prepares the print job and submits it through the specified channel. Appendix C sets for an example function for performing the print job processing. 
     Then, in step S 560 , the document processor  424  spawns a thread and notifies the front end module  426  that the print job is in a printing state. 
     Next, in step S 570 , upon receiving a request to process a print job, the back end module  426  requests the document attributes and document data from the document processor  424 . Depending on the submission channel used, the back end module  426  may convert the print job or document attributes into the submission channel&#39;s attribute format. The back end module  426  may also modify the document data to embed information in the document data. 
     Then, in step S 580 , the back end module  426  determines the destination output device  500  location and forwards the print job to that address/location. An example printer address format useable with this invention is “hostName, printerName, Extension”. The “hostName” is the machine name on which the print server is running. The “printerName” is the name of the requested output device  500 . The “Extension” is used to distinguish different kinds of lpr formats. 
     In step S 600 , the back end module  426  checks the status of the job. If the status indicates the job has been processed successfully, control continues to step S 610 , otherwise control jumps to step S 620 . In step S 610 , the back end module  426  reports the failure to the front end module  422  and document processor  424 . Control then jumps to step S 630 . In step S 620 , the back end module  426  reports the successful completion to the front end module  422  and the document processor  424 . Control then continues to step S 630 . 
     In step S 630 , the back end module  426  purges the job from the front end module  422  via the document processor  424 . Control then continues to step S 640 , where the operation of the front end module  422 , the document processor  424  and the back end module  426  stops. 
     FIG. 6 outlines in greater detail how the back end module  426  determines the destination device  500  location and forwards the print job in step S 580 . As shown in FIG. 6, starting from step S 580 , control continues to step S 581 . In step S 581 , the back end module  426  determines if a print job identifier is available from the output device  500 . If so, control continues to step S 583 , otherwise, control jumps to step S 585 . In step S 582 , the back end module  426  retrieves the print job identifier from the output device  500 . Control then jumps to step S 589 . 
     In step S 585 , if the back end module  426  is unable to retrieve the print job identifier from the output device  500  via the job submission channel  4262 , the back end module  426  generates a unique print job identifier for monitoring the print job. Then, in step S 587 , the back end module  426  allocates the memory for the print job identifier and assigns this unique print job identifier to it. Control then continues to step S 589 . 
     In step S 589 , the document processor  422  specifies the job submission channel  4262  used to submit the print job. Then, in step  591 , the back end module  426  notifies the document processor  424 , which in turn notifies the front end module  422 , that the print job is in a printing state. 
     Next, in step S 593 , before checking the print job status in step S 600 , the back end module  426  checks if the generated job identifier is valid for the querying job. The back end module  426  performs this function by checking the channel used to ensure that this back end module job query channel  4266  could be used to perform further job status queries. If the job identifier is valid, control continues in step S 595 , otherwise control jumps to step S 598 . 
     In step S 595 , the document processor  424  fills in the print job identifiers of the specified job(s) in the linked list and retrieves the latest print job information. Then, in step S 597 , the back end module  426  determines the number of jobs that are currently queuing on the output device  500 . The document processor  424  saves this value into its own memory space. This number is used to balance the load on the output devices  500 . Control then jumps to step S 599 . In step S 598 , the job status query for the print job is disabled. Control then continues to step S 599 . In step S 599 , control returns to step S 600 . 
     With this system and method, users may customize the system to the particular output devices  500  that are to be used by altering the back end module shared libraries  428 . FIGS. 4A-4O outline various possible combinations of functions to build value-added shared libraries. The only requirement for the shared libraries  428  is that they each must have the “BE_Initialize” and “BE_Shutdown” call functions. The implementation of the call function “BE_Processjob” is required for job submission, the call function “BE JobStatus” is required for job query and the call functions “BE CreateDevice”, “BE_DeleteDevice” and “BE_DeviceStatus” are required for device querying. 
     While this invention has been presented as a document processing system and method, various modifications and additions may be made without departing from the spirit and scope of the invention. In particular, the various functions described are not meant to be limiting but are rather illustrative of one particular embodiment and may be altered.