System for tracking and automatically communicating printer failures and usage profile aspects

[0002] The present invention relates to data capture and reporting capabilities, and more particularly to collecting, storing and sending out printer usage and failure data to user-selected destinations.

[0003] Printers are more complicated because they are being asked to do more. At the same time, more first-time or novice users are purchasing color printers. Both trends highlight the need for “smarter” printers which are easier to use and service. Many users cite the need for timely information about their printers. Prior solutions for this purpose have been to track usage of larger printer and copiers, with the goal being to spot potential problems before they happen and to track usage for tighter cost containment. However, such systems have not appeared in desktop printers.

[0004] In order to solve this problem, QMS Inc. developed CROWNVIEW which, as disclosed in the September 1998 issue of The Hard Copy Observer(Volume VIII Number 9), sends an error message via email to system administrator or to a designated mailing list. In addition, users can remotely view consumables usage data. However, in order to prevent or predict future service problems, there is a need for notification on regular intervals, not just on error condition. There is also a need for this communication on regular intervals to contain information of not only consumable usage but other usage information, and for patterns of usage to be communicated in a usable format to the manufacturer.

[0005] What is desired is an inexpensive system for tracking a wide range of printer usage aspects and failures and communicating such information upon a pre-determined condition and at regular intervals to the user and manufacturer in a format usable for spotting potential problems before they happen and tracking usage for: tighter cost containment, the improvement of future products and avoiding down time due to consumables reaching end of life.

[0006] Accordingly, the present invention provides an inexpensive system for tracking a wide range of printer usage aspects and failures. The system communicates such information upon a pre-determined condition and at regular intervals to the user and manufacturer in a format usable for spotting potential problems before they happen. Upon particular occurrences, such as a page being printed, a printer job done, an error event or a passing of a day, data is recorded to non-volatile memory (NVRAM) in the printer. Once a trigger event occurs, for example, an error or a passage of a certain amount of time, or a pattern of printer occurrences an email is automatically sent to a number of email addresses selected by the user. The email contains specially formatted encoded data that was previously recorded upon an occurrence as described above.

[0007] The objects, advantages, and other novel features of the present invention are apparent from the following detailed description when read in conjunction with the appended claims and attached drawing.

[0008] FIG. 1 is a block diagrammatic view of a system for tracking and automatically communicating printer failures and usage profile aspects.

[0009] FIG. 2 is a flowchart of the initial tasks of a system for tracking and automatically communicating printer failures and usage profile aspects.

[0010] FIG. 3 is a flowchart of the main tasks of a system for tracking and automatically communicating printer failures and usage profile aspects.

[0011] Referring to FIG. 1, a system for tracking and automatically communicating printer failures and usage profile aspects is shown. A Usage Profile Task 18 detects an occurrence of a printer condition which causes a data collection. In the preferred embodiment shown in FIG. 1, such an occurrence is an event occurrence (such as turning on power, opening a cover, a jam, a door open, tray removed, or button pushed), a page printed, a printer job completion, or a time event such as a day passing.

[0012] Once an occurrence as described above is detected by the Usage Profile Task 18, data is collected based upon what type of occurrence was detected. When there is a page occurrence, data is calculated about that page 10. When a printer job is completed, data is calculated about that printer job 12. When an event occurs, data about that particular event is collected 14. When an amount of time has passed, 1 day in the preferred embodiment, data is collected for that day. In the preferred embodiment, there are essentially five types of printer condition data collected: a quantity count (e.g. how many hours in state x?), a count of occurrences (e.g. how many times was the printer turned on?), a histogram of occurrences for each possible state (e.g. how many times was a door opened, categorized by top, middle, bottom?), a true histogram of possible values for one condition (e.g. for the pages per day distribution, 0 pages/day, 1 page/day, 2 to 5 pages/day, 6 to 10 pages per day, and so forth), and a “rolling” histogram that records the last few values of a certain condition (e.g. the last 5 jam locations and the media type used).

[0013] In the preferred embodiment, the data collected includes, but is not limited to: hours powered on, hours off-line, system reset log, pages imaged, pixels imaged, consumables gas gauges, jams, hours in Energy Star mode (an energy saving mode), temperature, humidity, consumable replacements, pages per day distribution, copies per job distribution, and feature usage.

[0014] All the above data is written to non-volatile memory (NVRAM) 8. When the printer is turned on for the first time, the NVRAM is initialized and a seal is stored on the NVRAM indicating this. Once this seal is in place, subsequent power-ups will not initialize the NVRAM.

[0015] Upon certain event triggers the data stored in NVRAM is formatted 20 and a report is sent containing the data, via email in the preferred embodiment 22, selectively to the manufacturer, and up to three other user-defined email addresses. In addition the data is retrieved upon demand by local service personnel through a parallel port, and the data is printed upon demand via a command through a printer front panel 24. The event triggers in the preferred embodiment include: major engine errors or jam sequences, a pattern of occurrences of printer conditions; a front panel request generated by a user, a POSTSCRIPT snippet sent to the printer, a manufacturer request for data via email (sends a snippet); a command via the Internet or World Wide Web (WWW), and every 3.5 calendar days or every 500 copies, whichever comes first. A POSTSCRIPT “snippet” is a piece of code written in the POSTSCRIPT programming language which usually performs some control function in the printer to which it is sent (as contrasted with code that actually specifies something to print). The number of pages or days in an event trigger is configurable by sending POSTSCRIPT snippets to the printer.

[0016] For an email report to the manufacturer 22, data will be encoded with tokens identifying each data item rather than textual messages. The casual reader will not be able to interpret the data without a token table. However this provides a moderate degree of security. However, a user may configure the email report sent to the user as textual or encoded.

[0017] The email portion of the invention is enabled or disabled by a command via the WWW, separately for the user and manufacturer and will be disabled initially. The data collection occurs independently of this.

[0018] An encoded report generated by any trigger uses the same format, which includes a full report on all statistics tracked. The format is a human-readable text message (7-bit ASCII) limited to the standard alphanumeric characters plus punctuation.

[0019] The report will consist of a series of data-items. Each item consists of a token-value pair, and is terminated by a semi-colon. The value is a scalar or a comma-separated list, or it may be empty.

[0020] There are two sections to the report, the header and the body. The header identifies the printer that is sending the report and when the report was created (note this will generally be different than the time stamp on the email itself, which indicates when the message was sent). The body contains a series of items for all defined data. Order is not significant. Each pre-defined token will appear exactly once in the list. In the preferred embodiment, every report generated has a syntax defined by the grammar below. White space in the message is not significant

[0021] The <data-token> shown above distinguishes between an item in the header (0<token<100) and an item in the body (token>100). A portion of a sample token table demonstrates this.

[0022] The <value> shown above is an integer in most cases, though may also be a string. The email report, however, is sent as plain ASCII text 22, not as binary, so the host side software reads each character up to the item terminator (;). Then, the <data-token> is parsed, and each <data-token> expects a specific data-type for its <value> list. If there is more than one <value>, commas (,) are used as value separators.

[0023] An example of a portion of an emailed report 22 is as follows:

[0024] 1=193DK374J32; 2=Phaser 740; 4=2015.105 (14); %%% 102=242;

[0025] 113=14,2500,1,1,534; End Usage Profile Report

[0026] Whereas the same data in a printed report 24 is as follows:

[0027] Printer ID=193DK374J32

[0028] Printer Name=Phaser 740

[0029] Printer Firmware=2015.105 (14)

[0030] Poweron=242

[0031] Prints Since Last Jam=14,2500,1,1,534

[0032] End Usage Profile Report

[0033] Referring to FIG. 2, a flowchart of the initial tasks that a system for tracking and automatically communicating printer failures and usage profile aspects performs is shown.

[0034] Upon powering on of the printer 26, the system checks for whether it is the first power on 28. If it is, then the first date is recorded (written to memory) 30 and the following steps 32, 34 and 36 are skipped. If not, then the hours that the printer was on the last time it was powered on is recorded 32. Next the system checks if there was a shutdown while the printer was in standby mode 34. If there was, then the hours the printer was on during standby are recorded 36. Next the system checks if there was a reset that had occurred 38. If there was, then that reset event is recorded 40. Next, the warmup start time is recorded 42 and the number of times the printer was turned on is incremented 44. The system then enters a main task loop 46.

[0035] Referring to FIG. 3, a flowchart of the main tasks that a system for tracking and automatically communicating printer failures and usage profile aspects performs is shown. After the system enters into a main loop 48 it determines whether the date has changed. If it has, then the new date is recorded and the number of pages printed the previous day is calculated and recorded 52. The system then determines whether the hour has changed 54. If it has, then the temperature and humidity readings are recorded 56. Next, the system determines whether there has been a transition either into or out of standby 58. If there has been, it is determined which standby transition was detected 60. If it was an enter into standby that was detected, then the time at which the transition occurred is recorded 62. If it was a leaving of standby that was detected, then the time the printer was in standby mode is calculated and recorded 64. Then the system determines whether a new page has been printed 66. If a page has been printed, then the number of pixels, media used, the page size and other page statistics as described above are recorded for that page 68. Then the system determines whether there is a new printer job 70. If there is, then the time recorded for the last job to complete, the source of the last job, and other job statistics are recorded as described above 72. Next, the system determines whether there was a button pressed on the printer 74. If there was, then a button count is incremented 76. Then the system determines whether there was a printer feature access by the user 78, such as calibrating colors, getting printer defaults and printing help pages. If there was, which feature was accessed is recorded 80. Then the system determines whether an exception has occurred such as an error, a jam or other event occurrence as described above 82. If there was, then that exception is recorded 84. Next, the system determines whether there is a report needed as determined by the conditions set forth above as event triggers 86. If there is, then a report is formatted and printed or emailed according to the particular event trigger as described above 88. After finishing the above step, the current time is recorded 90 and the system loops back to step 48. In the preferred embodiment, tasks above are functions called by other tasks where the data for a particular event is known. For example, when a new page is processed, instead of the task being performed directly in the main loop a printer engine task knows all of the relevant data about the page and will call the appropriate function to record those statistics.

[0036] Thus, the present invention provides an inexpensive system for tracking a wide range of printer usage aspects and failures and communicating such information upon a pre-determined condition and at regular intervals to the user and manufacturer in a format usable for spotting potential problems before they happen.

[0037] While the invention has been described with reference to the embodiment disclosed, it is not confined to the details set forth, but is intended to cover such modifications or changes as may come within the scope of the following claims.