Filter interface for managing printer system information

Description Submit all comments and votes

BACKGROUND OF THE INVENTION

1. Field of Invention

This invention relates to a filter interface between a filter and a server in a document printing system. In particular, this invention is directed to a filter interface that allows a filter to send extracted attribute information to a server.

2. Description of Related Art

FIG. 1 shows an overview of the flow of document data and attribute information in a printing system. When the client 110 sends a print request to a server 120, the client 110 sends a document data package 200, as shown in FIG. 2. The document data package 200 includes master document data 220, which includes the text of the document, and document attribute data 210, which includes attribute information about the document. For example, the document attribute data 210 includes paper size (in this case, A3), the number of images printed onto one page (in this case, 2-up) as shown in FIG. 2. Other attribute information may include client source, page numbers, user name, job name, etc.

When the server 120 receives the print request, the server 120 stores the document attribute data 210 into the attribute database 130. The server 120 then invokes the filter 140. The server 120 then sends the master document data 220 and the requested attribute information (the document attribute data 210 may be included) to the filter 140.

After filtering, the filter 140 sends modified document data back to the server 120. The server 120 then sends the modified document data to the printer 160 as a print job. After completing the print job, the printer 160 sends a report back to the server 120. After the server 120 receives the report from the printer 160, the server 120 extracts document attribute information needed for the account log 150 from the attribute database 130 and writes that information to the account log 150.

FIG. 3 shows the interaction between the server 120 and the filter 140. The process of the server 120 is different from that of the filter 140. The filter is registered with the server 120 using a filter definition 310. The server 120 invokes the filter 140, based on the command element of the filter definition 310. When the server 120 invokes the filter 140, the server 120 checks the command element in the filter definition 310. If some attribute names (in this case, number-up and content orientation) are found in the command element, the server 120 sends the attribute information corresponding to each attribute name to the filter 140 as the argument of the command. Thus, the filter 140 gets the attribute information needed to perform the operation from the command line found in the filter definition 310. The input data and output data are sent and received using a pipeline between the server 120 and the filter 140. The filter 140 gets the master document data 220 from the standard input and sends the modified document data to the standard output.

According to the above description, the filter 140 can get attribute information (e.g., number-up, content orientation, etc.) indicated in the command element of the filter definition 310. However, the filter 140 has no way to send attribute information that has been extracted in the filtering operation back to the server 120.

In addition, all attribute information which needs to be written to the account log 150 is not always included in the attribute information 210 that the client 110 sends to the server 120 or the attribute database 130. Some needed attribute information (e.g., medium-size) may be embedded in the master document data 220. However, the filter 140 does not have any way to send the extracted attribute information to the server 120 or to the attribute database 130. Therefore, some attribute information may not be properly written into the account log 150. Thus, the account log 150 cannot keep the exact attribute information regarding the print job and the document.

SUMMARY OF THE INVENTION

This invention provides a filter interface that allows the filter to extract document attribute information from the master document data and send the extracted attributes to the server. The server can then store the received document attribute information into an attribute database.

In this arrangement, modification of extracted document attribute information for the attribute database is performed by the server and not by the filter. This provides an added measure of security by not permitting third parties to access the attribute database through the filter. After the document is printed, the server gets the requested attribute information for accounting purposes from the database and writes the attributes into the account log. The account log can keep the exact attribute information regarding the print job and the document.

These and other features and advantages of this invention are described or apparent from the following detailed description of the preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described in detail with reference to the following drawings, wherein like numerals represent like elements and wherein:

FIG. 1 is a diagram of the conventional flow of document and attribute data;

FIG. 2 shows a composite document data packet;

FIG. 3 shows the conventional filter model and an exemplary filter definition;

FIG. 4 is a diagram showing the flow of document and attribute data using the filter interface of the invention; and

FIG. 5 is a diagram of the filter interface function and an exemplary filter definition and call-back functions.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 4 shows an overview of the flow of document and attribute data in a printing system utilizing the filter interface of this invention. The client 410 sends a print request to the server 420 in the form of the document package 200, containing the master document data 220 and the document attribute data 210 related to the print request and the document, as shown in FIG. 2. When the server 420 receives the print request, the server 420 stores the attribute data 210 into an attribute database 430. The server 420 then invokes the filter 440. The filter 440 in turn, sends a request to the server 420 via a filter interface 470 for the master document data 220 and document attribute data 210. The server 420 then sends the requested information to the filter 440 through the filter interface 470.

By using the filter interface 470, the filter 440 can extract attribute information (e.g., medium-size) embedded in the master document data 220. The filter interface 470 allows the data to be sent and understood by the server 420. The server 420 then stores the received attribute data to the attribute database 430.

Using the filter interface 470, the server 420, rather than the filter 440, modifies the extracted attribute data for storage into the attribute database 430.

That is, the filter 440 is denied direct access to the attribute database 430. This is important in terms of computer system security.

After filtering, and after the filter 440 sends the modified document data to the server 420 through the filter interface 470, the server 420 sends the modified document to the printer 460 as a print job. The printer 460 reports the completion of the print job to the server 420. After the server 420 receives the report from the printer 460, the server 420 extracts the needed attribute information for accounting purposes from the attribute database 430 and writes the attribute data to the account log 450. Thus, the account log 450 can keep the exact attribute information regarding the print job and the document.

FIG. 5 shows the interaction between the server 420, the filter 440, and a filter interface 500, including a filter definition 510 and a function for the execution 520 which includes some call-back functions as the argument. In this case, a process of the server 420 is the same as that of the filter 440.

As shown by the filter definition 510, the filter 440 is implemented as a "library," which is a dynamically loaded module. The filter definition 510 indicates the interface type (i.e., executable-type) during registration. The server 420 checks the type of filter and controls the filter according to which type (library or execution) appears. For example, if the executable-type is "library", the command element for the filter is a path name of the library. In this case, the server 420 calls the execution function 520, which must be provided by the library, in order to invoke the filter. Alternatively, if the executable-type is "execution", the command element for the filter is a path name of the execution file. In this case, the server 420 invokes the filter 440 according to the manner used in the prior art.

In the "library" type, the filter 440 receives call-back functions in order to call and obtain any required attributes 210 and the master document data 220 from the server 420. In addition, the filter 440 can use the call-back functions to return printer-ready data and the extracted attributes to the server 420. The call-back functions may also include some functions to check cancel requirements of the operation, etc.

As shown in FIGS. 4 and 5, the server, including the filter interface, is preferably implemented on a programmed general purpose computer. However, the server, including the filter interface, can also be implemented on a special purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an ASIC or other integrated circuit, a hardwired electronic or logic circuit such as a discrete element circuit, a programmable logic device such as a PLD, PLA, FGPA or PAL, or the like. In general, any device on which a finite state machine capable of performing the functions of the server, including the functions of the filter interface, as shown in FIGS. 4 and 5, can be used to implement the server.

While this invention has been described with specific embodiments thereof, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the preferred embodiments of the invention as set forth herein are intended to be illustrative, not limiting. Various changes may be made without departing from the spirit and scope of the invention as defined in the following claims.

* * * * *