Users of shared devices, such as walk-up or peripheral imaging devices (e.g., printers, copiers, scanners, etc.), often experience problems with device use. These problems may comprise device errors that are detectable by the device including, for instance, paper jams. In addition, the problems may comprise device errors that are not detectable by the device including, for example, print quality flaws, operation noises, etc. Furthermore, such users may experience problems with achieving certain desired results (e.g., stapling, collating, etc.) due to the user's lack of knowledge as to how to operate the device to accomplish such results.
When such a problem is experienced by a user, the user will often attempt to work around the problem on the device or simply try using another device. In the case of a device error, if the error condition is not reported to an appropriate person (e.g., system administrator), the condition often times will persist for a significant amount of time and, therefore, will also be experienced by one or more subsequent users, thereby negatively affecting productivity for multiple persons at the device location (e.g., business office).
There are several reasons why device errors or other user problems go unreported. For one, there normally is no simple way to report the problem. For instance, although a user that discovered an error condition could consult a system administrator who is familiar with the device, the user may not know who that person is or how to get in touch with them, particularly in large corporate environments. Even when such a person is reached, the user may need to accurately convey the nature of the problem to the administrator, despite not being as familiar with its configuration or operation.
In an alternative solution, the user can obtain customer support from the device manufacturer. To do this, the user must go to a telephone, such as the user's office telephone, locate the customer support telephone number (e.g., via the Internet), call the customer support line, and wait in a queue until a customer support representative becomes available. This process may require a significant time investment. Furthermore, once the user reaches the representative, the user may be asked to provide various device information (e.g., device model number, serial number, firmware version, etc.) which may require the user to travel back to the device, collect the information, and return to the telephone, thereby wasting even more time.
As can be appreciated from the foregoing, the difficulty associated with reporting device errors results in many such errors not being reported for an extended period of time. Therefore, it would be desirable to have a system and method with which such errors could be reported more easily and thus more quickly fixed. Furthermore, it would be desirable to have a system and method with which other user problems, such as lack of knowledge as to how to accomplish a desired result, can be reported and, therefore, potentially remedied.
Disclosed are systems and methods for reporting device problems. In one embodiment, a system and method pertain to collecting device data relevant to diagnosing or fixing a problem encountered by a user of a device, collecting user input regarding the encountered problem, and generating a customized problem report that describes the problem and that includes the collected device data.
The disclosed systems and methods can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale.
As described above, device usage problems often go unreported, at least for some period of time, in large part due to the difficulty associated with reporting the problems. This phenomenon is unfortunate whether the problem pertains to a device error or simply to user ignorance as to proper device operation. In the former case, failure to report the error may result in multiple persons being inconvenienced by the error. In the latter case, the user may never receive the training he or she needs to accomplish the desired result.
As is described in detail the following, however, such problems can be quickly and easily reported, or the process required to report the problem initiated, by the user while at the given device. For instance, the user can generate a report using the user interface of the device and that report can either be transmitted to another device or stored in device memory for later access by an appropriate person (e.g., device technician). In another embodiment, the information needed to generate the report (e.g., device configuration information) can be transmitted from the device at which the problem is experienced to a suitable user computing device (e.g., desktop computer) so that the user can add various information to a message (e.g., email message) that will be sent to an appropriate person (e.g., system administrator). Irrespective of the particular process used, problem reporting is facilitated by the system, thereby making it more likely that such problems are reported promptly.
Disclosed herein are embodiments of systems and methods for reporting device problems. Although particular embodiments are disclosed, these embodiments are provided for purposes of example only to facilitate description of the disclosed systems and methods.
Referring now in more detail to the drawings, in which like numerals indicate corresponding parts throughout the several views,
The device 102 may comprise, for instance, an imaging device. By way of example, the device 102 comprises a printer, a photocopier, a scanner, a facsimile machine, or a multi-function peripheral (MFP) device which is capable of performing multiple tasks such as printing, copying, scanning, faxing, and emailing. Although particular types of devices have been explicitly mentioned, the device 102 of the system 100 may comprise any device with which a user may experience a problem that is suitable for reporting. Therefore, the device 102 could comprise a non-imaging device that is capable of walk-up and/or peripheral use.
The user computing device 104 can be a local computer that, for instance, shares a local area network (LAN) 110 with the device 102. By way of example, the user computing device 104 is a personal computer (PC) that is located in the user's office (e.g., remote from the device 102). Although a PC is shown in
The support computing device 106 can comprise, for example, a network server or other computer that is intended to receive problem reports that are generated by a user who experiences a problem with the device 102. The support computing device 106 may be local on the network 110 (e.g., in the case in which the report will be received by a network administrator) or may be remote to the network (e.g., in the case in which the report will be received by a remote support representative or technician) in which case the support computing device communicates to the network via an external network (not shown).
The portable devices 108 may comprise, for example, a personal digital assistant (PDA) 112 or a paging device 114 which is at least capable of receiving wireless (e.g., radio frequency (RF)) communications. As is described below, the portable devices 108 may be possessed and used by a local system administrator that is charged with the duty of receiving reports about problems experienced with the device 102.
The processing device 200 is adapted to execute commands stored in memory 202 and can comprise a general-purpose processor, a microprocessor, one or more application-specific integrated circuits (ASICs), a plurality of suitably configured digital logic gates, and other well known electrical configurations comprised of discrete elements both individually and in various combinations to coordinate the overall operation of the device 102. The memory 202 comprises any one or a combination of volatile memory elements (e.g., random access memory (RAM)) and nonvolatile memory elements (e.g., read-only memory (ROM), Flash memory, hard disk, etc.).
The user interface 204 comprises the tools with which the device settings can be changed and through which users can communicate commands to the device 102. By way of example, the user interface 204 comprises one or more function keys and/or buttons contained within a device control panel such as those already integral to the design. The keys and/or buttons may include a dedicated problem reporting button, the use for which being described below. Optionally, the user interface 204 can include a separate device, such as a PDA that is adapted to wirelessly communicate with the device 102. In addition, the user interface 204 may comprise an audio recording device, such as a microphone, which may be used to record spoken user comments regarding the problem that the user encountered.
The display 206 may also be provided in a device control panel. Regardless, the display 206 is configured to present visual information to the user, such as status notifications, error condition notifications, settings information, etc. As is described in more detail in the following, the user interface 204, and in some embodiments the display 206, can be used to report a problem that the user is having with the device 102, or to at least initiate the problem reporting process.
The one or more I/O devices 208 facilitate communications with other devices over the network 110 or wirelessly, and therefore may include one or more of a modulator/demodulator (e.g., modem), network card, wireless (e.g., RF) transceiver, or other such communication component.
The memory 202 includes various programs including an operating system 212, an embedded network (e.g., Web) server 214, and a problem reporting manager 216. The operating system 212 controls the execution of other programs and overall operation of the device 102. The embedded network server 214 is configured to post and/or transmit information concerning device configuration and status, and, in some embodiments, device problem reports. The problem reporting manager 216 comprises logic that is used to, for instance, collect data that is relevant to a problem the user is having, and at least initiate the problem reporting process. Examples of operation of the problem reporting manager 216 are described in detail in relation to
The processing device 300 can include a central processing unit (CPU) or an auxiliary processor among several processors associated with the user computing device 104, or a semiconductor based microprocessor (in the form of a microchip). The memory 302 includes any one of or a combination of volatile memory elements (e.g., RAM) and nonvolatile memory elements (e.g., hard disk, read only memory (ROM), tape, etc.).
The user interface 304 comprises the components with which a user interacts with the user computing device 104, such as a keyboard and mouse, and a device that provides visual information to the user, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor.
With further reference to
The memory 302 comprises various programs including an operating system 310, a communication program 312, and a further problem reporting manager 314. The operating system 310 controls the execution of other programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The communication program 312 enables the user to send communications to other devices, typically via the network 110. By way of example, the communication program 312 comprises an email or a facsimile program. The problem reporting manager 314 is configured to receive communications sent from the device 102, or a device acting on the behalf of the device 102, and generate an error report to be sent to an appropriate person (e.g., system administrator or support representative or technician). Examples of operation of the problem reporting manager 314 are described below in relation to
Various programs have been described herein. These programs can be stored on any computer-readable medium for use by or in connection with any computer-related system or method. In the context of this document, a computer-readable medium is an electronic, magnetic, optical, or other physical device or means that contains or stores a computer program for use by or in connection with a computer-related system or method. These programs can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions.
Example systems having been described above, examples of operation of the systems will now be discussed. In the discussions that follow, flow diagrams are provided. Process steps or blocks in these flow diagrams may represent modules, segments, or portions of code that include one or more executable instructions for implementing specific logical functions or steps in the process. Although particular example process steps are described, alternative implementations are feasible. Moreover, steps may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved.
As identified above, embodiments of the disclosed systems and methods can be used to enable simple reporting of problems experienced with use of a device, such as an imaging device.
Irrespective of the nature of the problem that the user is experiencing, the device can collect data relevant to diagnosing and/or fixing the problem, as indicated in block 402. The nature of the data that is collected can depend upon the specific type of problem that is being experienced. The type of problem being experienced can be determined by the device by, for instance, detection of a device error or receipt of a user input that identifies the problem to the device. The collected data may comprise, for example, the device model, the device serial number, the year the device was manufactured, the firmware version that the device is running, the configuration of the device (e.g., what auxiliary devices the device includes), the various settings currently selected for device operation, the Internet protocol (IP) address of the device, the media access control (MAC) address of the device, the various current page counts for the device (or other usage data), the type of media (e.g., paper) the device is using, the physical location of the device (e.g., building number and floor), device status/error log information, and the like.
Flow from this point may depend upon whether input is to be collected from the user, as indicated in decision block 404. In particular, flow may depend upon whether the user will provide information, such as a user-provided description of the problem that was encountered and the conditions in which the problem was encountered. If no such user input is to be collected, flow continues down to block 408 described below. If user input will be provided, however, flow continues to block 406 at which the device collects information provided by the user while the user is at or proximate to the device. The information can be input by the user using any one of a number of interface devices. For instance, the information may be entered using the user interface of the device (e.g., interface 204,
Referring next to block 408, a problem report is generated. This report can be generated by the device, or by another device that received various data from the device, such as the user's computing device. Regardless, the report at least includes the various data that was collected by the device (block 402), and may comprise additional information provided by the user (block 406). In addition or exception, the information can include information that was input by the user at his or her computing device (as will be described in relation to
At this point, a problem report has been created and is ready for storage on a device or for transmission to another device. With reference to decision block 410, if the report is not to be sent to another device, flow continues to block 414 at which the report is stored on a device (e.g., device 102 or user computing device 104). Alternatively, however, if the report is to be sent, flow continues to block 412 at which the report is transmitted to another device (e.g., support computing device 106). Such transmission could comprise, for example, an email message, a facsimile transmission, wireless transmission, or substantially any network transmission. At this point, flow for the current problem reporting session is terminated.
With reference next to decision block 504, if the user does not wish to create a customized problem report, flow continues down to block 524 of
Returning to decision block 500, if no device error is detected by the problem reporting manager 216, flow continues to decision block 506 at which the manager determines whether a problem indication is received from the user, for instance by user input entered via the user interface 204 (e.g., one or more button and/or menu selections). If not, presumably no problems are being experienced and flow returns to decision block 500 described above. If, on the other hand, the problem reporting manager 216 receives an indication of a problem from the user, flow continues to block 508 at which the problem reporting manager 216 prompts the user to identify the type of problem that is being experienced. For instance, the problem reporting manager 216 can present one or more multiple choice questions to the user with the display 206. In such a case, the problem reporting manager 216 can prompt the user to indicate whether the problem pertains to, for example, print quality or achieving a result that the user does not know how to attain (e.g., collating, creating bound documents, etc.).
After prompting the user, the problem reporting manager 216 can receive the problem type identification, as indicated in block 510. At this point, the problem reporting manager 216 can collect device data that is relevant to diagnosing and/or fixing the problem. Notably, this data may be collected after the problem reporting manager 216 detected a device error and received an indication from the user to create a customized report (blocks 500-504). Given that the particular problem is known (either through detection or from user input), the problem reporting manager 216 can collect the data that is most relevant to that particular problem. As identified above in relation to
Referring next to block 514 of
At this point, various device and user-provided information has been collected. Accordingly, as indicated in block 518, the problem reporting manager 216 can generate a customized problem report. Flow from this point then depends upon what is going to be done with the generated problem report. With reference to decision block 520, the problem reporting manager 216 determines whether to send a report to another device. This determination can be made with reference to a device setting or user selection. By way of example, the report can be transmitted via the network 110 to the support computing device 106. Such a communication may comprise, for instance, an email message, facsimile message, or other network communication. Alternatively, the report can be transmitted via a wireless communication to a portable device 108 (e.g., PDA 112 or paging device 114) that is possessed and used by a local system administrator. Furthermore, the report can be sent to the user's own computing device (e.g., user computer device 104).
If the problem report is not to be sent, flow continues to block 524 at which data about the problem is stored on the device 102 (e.g., to a hard disk of the device). The nature of this data depends upon the flow described above. For instance, if the user opted at decision block 504 (
Returning to decision block 520, if the problem report is to be sent to another device, flow continues to block 522 at which the report is transmitted to the other device. As noted above, the transmission can be directed at a system administrator or support representative. Accordingly, that person can obtain detailed information about the problem being experienced and, presumably, can take appropriate action to remedy the problem. Alternatively, the report can be transmitted to the user computing device 104 for the purpose of storing the report on that device, forwarding the report to another device from the computing device, and/or adding further user-provided information (e.g., with a keyboard of the computing device). Such operation is described below in relation to
Irrespective of whether the problem report was transmitted or simply stored on the device 102, flow then returns to decision block 500 of
With reference next to decision block 604, flow continues depending upon whether the report is to be sent to another device. By way of example, the report can be transmitted via the network 110 to the support computing device 106. Such a communication may comprise, for instance, an email message to which the generated report (block 602) is appended as a file attachment, or another network communication. In the former case, the problem reporting manager 314 may generate an email message in which the user can add comments, such as text entered via a keyboard of the user computing device 104 or save file attachments. In addition, that email message can automatically be directed to the appropriate support person (e.g., network administrator or support representative) via, for example, automatic entry of that person's email address in the “To:” block of the email message. Alternatively, the problem report manager 314 can generate a problem report template in which the user can add comments.
If the problem report is not to be sent, flow continues to block 608 at which the problem report is stored on the user computing device 104 (e.g., on a hard disk of the computing device). If, on the other hand the problem report is to be sent to another device (e.g., support computing device 106), flow continues to block 606 at which the report is transmitted to the other device. At that point, flow for the problem reporting session is terminated.