DETAILED DESCRIPTION OF THE EMBODIMENTS

[0008] Reference will now be made in detail to exemplary embodiments of the invention. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[0009] The following description will include exemplary embodiments describing image rendering devices. It should be appreciated that the phrase “image rendering device” is intended to include devices that generate a physical image on a media (i.e., an image applicator), such as ink jet printers, laser printers, photocopiers, facsimile machines, etc. Other image rendering devices that do not include image applicators (e.g., scanners) but store a rendered image in a computer readable file can also be used for various embodiments of the present invention, as would be readily apparent to one of ordinary skill in the art after reading this disclosure.

[0010] A printer 110 according to an embodiment of the present invention is shown in FIG. 1 . The printer 110 includes an image applicator 170 ( FIG. 2 ), such as a laser printing mechanism or an ink jet print head with an ink cartridge, configured to “render” an image on a media 130 . The image applicator 170 is electrically coupled to a processor 160 , which is configured to control the image applicator 170 so as to render the image when a print job has been generated by a computer 120 ( FIG. 1 ) coupled via link 140 (e.g., a cable or network connection) to the printer 110 . The processor 160 is further programmed to compile image rendering data from the print job, and to update a file name of the print job so as to include a “printing descriptor” of a “present printing status” as will be described in greater detail below.

[0011] The processor is also coupled to a memory 150 ( FIG. 2 ), such as a hard disk drive (HDD) or other persistent data storage media, which stores the print job at least while the image applicator 170 renders the image. It should be appreciated that the memory 150 may have a storage capacity substantially larger than the volatile memory found in conventional printers, because the memory 150 is designed to have a storage capacity of sufficient size to store an entire print job. By way of example, the memory 150 may have a storage capacity of at least 20 kilobytes, though it should be appreciated that the actual storage capacity will vary depending on the particular application at hand (e.g., 1 megabyte or greater, 100 megabytes or greater, 1 gigabyte or greater, 10 gigabytes or greater, etc.). Furthermore, software is provided such that the memory 150 can be rewritten or updated.

[0012] Operation of the aforementioned printer will now be described in reference to FIG. 3 . In step 300 , a user selects a print option from a software application running on the computer (e.g., a word processor). Alternatively, a print job may automatically be selected in step 300 , such as periodic report generation (e.g., maintenance log) by a network monitoring device. The software application then generates a print job in step 310 in response to step 300 .

[0013] The generated print job is then transmitted to the printer in step 320 , and stored in the printer's memory in step 330 . While some formatting may be performed by the computer (e.g., framing the data for transmission to the printer), the image rendering data is compiled by the printer in step 340 , rather than by the computer generating the print job in step 310 . The compiled image rendering data is then used by the printer to render the image in step 350 .

[0014] According to one embodiment of the present invention, the printer additionally tracks a “printing status” of the print job as shown in FIG. 4 . More specifically, after the print job has been stored in step 330 , the printer monitors the printing status in step 410 . Monitoring step 410 may be performed continuously or repeated periodically while the image rendering data is compiled in step 340 and/or the image is rendered in step 350 . As shown, monitoring step 410 is typically performed concurrently with both compiling step 340 and rendering step 350 .

[0015] By way of example, monitoring step 410 may include monitoring the compiling step 340 , such that a compiling status (e.g., how far along the printer is in the compiling process, which is part of the overall printing process) is monitored in the monitoring step 410 . The printer then associates a present printing descriptor (consistent with that compiling status) with the present printing status in step 420 . Hence, for a compiling status, a present printing descriptor may include “submitted for compiling”, “compiling initialized”, “compiling in progress”, and “compiling complete”. Once the present printing descriptor has been associated with the present printing status in step 420 , the printer then updates the file name of the print job in step 430 so as to include the present printing descriptor of step 420 .

[0016] As set forth above, the monitoring step 410 may be repeated as the printer continues to compile the image rendering data in step 340 and/or render the image in step 350 . Using the previous example, if the compiling step 340 progresses from a present compiling status of “compiling in progress” to a subsequent compiling status of “compiling complete”, the printer associates a subsequent printing descriptor (i.e., “compiling complete”) with the subsequent printing status in step 440 , and updates the file name of the print job in step 450 so as to include the subsequent printing descriptor of step 450 . Thus, the term “subsequent” refers to any printing status which occurs after the “present” (i.e., first) printing status.

[0017] An exemplary file naming progression for a print job being printed in accordance with the previous embodiment, is shown in the block diagram of FIG. 5 . As shown, the printing status descriptor may stored as part of a file extension, such as “new” in 500 , “spooled” in 510 , “printing” in 520 , “printed” in 530 , and “billed” in 540 . Alternatively, the printing status descriptor may be stored as part of the main file name portion, such as “10-Oct.-2003” representing a date the print job was submitted, and “11-23-34am” representing a time the print job was submitted. The present printing status descriptor may be replaced by subsequent printing status descriptors (see progression in the file extension from “new” in 500 to “billed” in 540 ), or may be concatenated with subsequent descriptors (see inclusion of both “10-Oct-2003” and “11-23-34am”).

[0018] According to one embodiment of the present invention, the file name may also be updated to include non-printing status descriptors. By way of example, an identification of a print job submitter (e.g., “Room531”), a print job priority, a print job distribution list, a billing code, or a print job archive history/version number may be included. Other non-printing status descriptors may also be used, as would be readily apparent to one of ordinary skill in the art after reading this disclosure.

[0019] It should be appreciated that the printing status descriptor and/or non-printing status descriptor can be generated by the printer itself, or retrieved from a memory in the printer, or obtained in some other convenient manner. By way of example, the printer may include a clock, and may correlate a time the print job is received with the print job file. The printer can then generate a printing status descriptor, such as a time the print job was received (e.g., “11-23-34am”).

[0020] According to one embodiment of the present invention, the aforementioned printing descriptor can be monitored for processing requirements in addition to the physical imaging. By way of example, a network server monitoring the printing of an item (i.e., “printed” in 530 of FIG. 5 ) may determine that the print job needs to be billed (i.e., a processing requirement) after the print job has “printed” by monitoring the file extension to determine when the print job has completed. The network printer may then cause the printer to update the file name to “billed”, thereby indicating that the appropriate billing has been processed and completed.

[0021] Similarly, a network server monitoring the printing of an item may schedule various print jobs to different printers on a network based on how far along a given printer is in printing the item. By way of example, if a given printer is in a “spooled” status thereby indicating the print job is relatively early on in the printing process, the network server may transmit the next print job to a different printer (e.g., one where the most recent print job has a “printed” present processing descriptor).

[0022] Additionally, a non-printing status descriptor can be used by the printer for various processing requirements. By way of example, a print job priority (e.g., “high”, “normal”, “low”, etc.) may be included as part of the file name when the print job is transmitted to the printer (see step 320 in FIG. 3 ), such that the printer prints high priority items before normal and low priority items. Similarly, the printer can be programmed to prioritize certain print job submitters over others (e.g., a manager's print job over a clerical print job), the print job submitter information (e.g., “Room 531 ” in FIG. 5 ) being included as part of the file name of the print job.

[0023] A printer including one or more of the aforementioned features thus allows for tracking a printing status with a file name of a print job. Hence, data related to a print job can be stored and tracked without having to maintain a separate table of job metadata and without storing metadata in a separate companion file next to the print data file. Additionally, specialized components in the print service can perform their print job processing tasks independently by each monitoring the file name or by having the printer automatically transmit information to the specialized component when a particular status is reached. By way of example, specialized components may monitor the file name to identify the need to print, bill, or delete the print job or to perform other processing tasks, such as exporting information about the job to support personnel or a network server. Other features and advantages are also plausible, as would be readily apparent to one of ordinary skill in the art after reading this disclosure. See, for example, co-pending application entitled “Method And Apparatus For Crash Recovery On An Image Forming Apparatus”, by Brian McKinley et. al., filed the same day as the present application, which is incorporated by reference herein in its entirety.

[0024] The foregoing description of various embodiments of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiments were chosen and described in order to explain the principles of the invention and its practical application to enable one skilled in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. Hence, additional applications, such as scanners, may also benefit from tracking a file processing status with a file name.