Abstract:
A communication system and apparatus for a xerographic imaging system for enhanced collaborative communication between the machine user and the remote troubleshooting advisor. The machine includes an imager for showing a selected virtual representation of the machine including an image of the machine illustrating an area of the machine having the troubleshooting need. A communication link exists between the user and the advisor and comprises a bi-directional visualization of a selected virtual representation synchronously displayed to the user and the advisor via respective imagers. An image adjuster is operated by the expert for selective adjustment of the virtual representation to suggest a section of the area of the machine wherein action by the machine user may resolve the troubleshooting need. The selective adjustment is communicated to the machine user through the communication link whereby upon viewing this suggested adjustment, corrective action is suggested to the user. The corrective action is identified to the user by identifying a difference between the actual machine state and the shared virtual representation. The visual indicators may direct the user to a particular location and percussion centers on the machine identify a particular tapping location by the user to verify position identification to the troubleshooting expert.

Description:
CROSS REFERENCE TO RELATED PATENTS AND APPLICATIONS 
   This application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/657,584 filed on Mar. 1, 2005 and entitled “BI-DIRECTIONAL REMOTE VISUALIZATION FOR SUPPORTING COLLABORATIVE MACHINE TROUBLESHOOTING,” the entirety of which is incorporated herein by reference. 

   FIELD OF THE INVENTION 
   The present invention relates to diagnostic and customer-service systems for users of office equipment, such as copiers, printers, facsimile, or multifunction machines. 
   BACKGROUND OF THE INVENTION 
   Office equipment, such as printers or copiers, typically uses a software-based operating system to perform essential machine functions and implement the various jobs of which the machine is capable. However, software, particularly that used in high-speed multi-function machines, is subject to various problems and faults. Additional problems also arise with the machine hardware which, in machines of this type, is extremely complex and sophisticated. Hardware and software problems that occur typically happen at a low, non-periodic rate and thus are very difficult to replicate when servicing the machine and therefore difficult to resolve. Further, many of these problems are identified by the customer, who is typically not technically trained to diagnose and service machines of this type. For this reason, it is important for a servicing organization to be able to access key machine operating information, and particularly information reflecting on the performance of the machine control system and physical states of machine componentry. 
   A common feature of the business arrangement between the user of the equipment and the supplier is that the user is responsible, at least in part, for some maintenance and basic trouble-shooting of the equipment. Often the equipment has componentry that can be tested, manipulated and perhaps replaced by the user, but in view of the investment in the equipment, users are reluctant to engage in system repair without the strong support of the supplier and its service departments. Accordingly, enhancing the accuracy and efficiency of equipment service is based on particularly articulating or determining equipment status and the occurring problem to a remote trouble-shooting service department. Frustrating experiences with the telephone communication-to-tech support departments is universally known and the problems with unsophisticated customers trying to actually communicate a problem to the department are extremely common. 
   Typically, when a user encounters a problem with a machine and cannot resolve it (or does not want to solve it himself, he (or a user representative) calls a support organization for assistance, such organizations typically have troubleshooters available to help. After salient details such as the machine serial number have been taken, the troubleshooter tries to ascertain the character and extent of the problem. When the nature of the problem and its possible causes have been uncovered, the troubleshooter will either propose some ways to attempt to resolve the problem or decide at this point that the call is best passed to higher level support. Where the troubleshooter attempts to get the user to resolve the problem, aside from his own knowledge and experience he may make use of a range of resources, such as an online knowledge base, physical machines, or the advice of colleagues. 
   The interactions between a user experiencing a problem with a machine and a troubleshooter on the phone recurrently involve a number of phenomena. The user and the troubleshooter between them build up a description of the problem that enables consideration of what an appropriate solution might be. This can include:
         the provision by the user of an initial problem description, often containing a range of contextual information about the situation the problem has arisen in;   the reformulation of this description by the troubleshooter, into terms more specifically relevant to locating a solution;   affirmation/refinement of this description by the user;   potential further joint refinement of the problem/collation of other relevant features (either verbally or by getting the user to ‘go look’); and,   working together through instruction, implementation, and feedback to try out possible solutions.       

   In doing this work both the user and the troubleshooter routinely describe physical elements of the machine and give spatial directions or descriptions. It is often necessary to describe machine parts because users do not necessarily have the technical vocabulary to identify machine parts by name. The situation in which this particular problem with this particular machine arose has to be made available, where either party may only have partial information. The full extent of the problem also needs to be inquired into and made available. This may involve asking the user to undertake additional testing activities and report back. Potential solutions must be located and instructions given, followed, and their outcomes provided. 
   These interactions also typically take place under circumstances where the interactants only have access to an audio channel (telephone) which is not necessarily (physically) located by the machine, thereby requiring the user to negotiate a means of accessing the machine while retaining contact with the troubleshooter. The audio channel alone means that all descriptions, instructions and feedback are only verbal and the user will be the sole source of the initial problem description, circumstantial information, the results of the attempted instructions, etc. This can result in the troubleshooter requesting that the user repeat actions, either because they do not know the user has already done these, or because they cannot be sure the user has done these correctly. For the troubleshooter, where possible solutions come from textual resources, they will have to be digested from text and then articulated through purely verbal means. As a consequence of these circumstances a number of issues arise where the resolution is, at best, sub-optimal:
         The user may lack access to the machine while on the phone and need to devote effort to coordinating access with others or constantly moving between the phone and the machine.   Troubleshooters will lack potentially significant and relevant information about the current machine status, the previous actions undertaken by the user, and the machine&#39;s previous behavior.   There is a lack of mutual access to the machine resulting in effort being devoted to:
           describing the current state and answering questions in order to arrive at a mutually agreed expression of the problem;   producing instructions and directions and reporting back without being able to see how instructions and directions might be appropriately framed to the current circumstance (necessitating potentially redundant feedback and varying degrees of clarification); and   working out ways together to ensure that they are referring to the same physical components of the machine.   
               

   Out of these observations it is possible to recognize two inter-related and potentially critical barriers to fully effective troubleshooting via conventional means:
         1. The site of the problem is removed form the site of resolution for user-machine interactions. Excessive physical movement and coordination may be demanded, there is an absence of potentially important information to relevant parties, and both the problem and the resolution must always be mediated by verbal means.   2. The user-troubleshooter interaction is not best facilitated solely over the phone. Restriction to verbal mediation only diminishes the capacity to recognize the current state of the machine, the user situation, the object of reference, and the import of instructions.       

   The foregoing problems have suggested various needs for improved collaborative, distributed troubleshooting of network devices such as printers or MFDs (“multi-function devices”). There is a need for the improved communication of important information to be accomplished by the use of networking and user interface (“UI”) capabilities with the equipment to handle the collaboration between the user and troubleshooter, and to use sensors and actuators (LEDs in the equipment). More particularly, there is a need for the user-troubleshooter interaction to comprise making the equipment the infrastructural mediator between the troubleshooter and the user and to create a bi-directional Shared Visualization of the Problems (“SVP”) which the user and troubleshooter can manipulate to thereby make coordinated informed actions in order to troubleshoot the problem. 
   That is, the user should be able to access technical support through the machine and then carry out the interactions with the troubleshooter via an audio-visual communication channel. This enables both parties to have a real time understanding of the actions which are being or should be performed on the machine, providing a resource for overcoming the descriptive and spatial problems which currently affect troubleshooting. The visualization allows technical support to better utilize the abilities of the remote user to carry out actions on the machine. 
   A number of systems using video have been suggested or designed to support remote collaboration around locally situated objects. However, video can introduce interactional difficulties or may involve considerable overhead, requiring multiple cameras or sophisticated equipment. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  is a general architecture of a bi-directional remote visualization system for supporting collaborative machine troubleshooting; 
       FIG. 2  is a flowchart showing the essential steps performed by a machine user and a troubleshooting expert in accordance with the subject system; and 
       FIGS. 3-5  are block diagrams particularly illustrating selected components of an imaging system incorporating the present development. 
   

   DETAILED DESCRIPTION 
   The subject system comprises apparatus and methods for negotiating common barriers arising in the user-troubleshooter interaction when trying to solve a machine problem. The machine becomes the infrastructural mediator between the troubleshooting expert and the user to create a bi-directional Shared Visualization of the Problem (“SVP”) which the user-troubleshooter can manipulate for making coordinated performed actions in order to troubleshoot the problem. The user accesses technical support through the machine and carries out independent or suggested interactions with the troubleshooter via an audio-visual communication channel. Most parties thus have an enablement to real-time understanding of the actions which are being actually performed on the machine, and thereby providing a resource for overcoming the descriptive and spatial problems which commonly and currently affect the troubleshooting scenarios. The SVP allows technical support to better utilize the abilities of the remote user to carry out actions on the machine. 
   The machine thus enhances the troubleshooter&#39;s understanding of the problem and it further aids the discovery of a solution. The subject system mediates between the troubleshooter and the user for enabling them to mutually arrive at a solution despite not having mutual access to the problem source, i.e., the machine. Major benefits are achieved over audio-only interaction since most of the user-troubleshooter interaction involves work of a spatial nature; describing parts, delivering instructions, etc. 
   More particularly, with reference to  FIG. 1 , an imaging device  10  (printer/copier, MFD) is connected to a service department/troubleshooter  12  via communication link  14  comprising a conventional firewall/intranet/internet link. The troubleshooter  12  includes a call management system  16  and knowledge base  18  comprising a database including customer information and call support information, and more particularly includes in knowledge base  18  stored data identification of the machine  10  and a model of its expected visual representation as would be viewed by a user if servicing the machine. A user has access to enhanced user-troubleshooter interaction through audio input/output and a visual imaging device  20  for display of the SVP as hereinafter will be more fully detailed. 
   With reference to  FIG. 2 , the subject troubleshooting scenario is initiated when the user discovers  30  a problem with the machine that they cannot troubleshoot or fix, or do not want to fix themselves. Such a problem may be software or hardware in nature, but for the following exemplary description will be as discussed as only hardware. A call is placed  32  to a remote support center and troubleshooter  12  by selecting a “call support” button on the user interface (“UI”) of the machine  10  display. Alternatively, when the machine  10  detects a problem it is so indicated to the user who is advised via the UI that they should call support. The audio-visual link comprises a secure audio end-to-end connection to the customer support center server via a secured data connection through which relevant data is transmitted. The relevant data may include any or all of the following:
         machine serial number;   user ID, if the user is logged in, e.g. name and any other relevant information;   machine diagnostic data, such as sensor information on the current state of the machine;   historical information on the machine events, e.g. toner changed; and   interaction data, e.g. user interaction with troubleshooting tools such as a knowledge base.       

   The troubleshooting remote server uses the relevant data in combination with its own stored data for identifying  34  the machine and records of other troubleshooting sessions to build an initial SVP. The user is then asked to put on a headset for establishing  36  the audio link after the placing of a service call. Alternatively, when the secure audio connection is made and an operator comes on line, this may instigate the audio and visual signal, e.g. a phone style ring and a “put on your headset” message. The initial SVP is generated  38  and synchronously display  40  to both the user and the troubleshooting expert. The user oriented version of the SVP includes a visual representation of the current status of the machine, e.g. showing which doors are opened, etc. The initial SVP for the troubleshooter may contain the following information which may vary according to what was accessible and what is relevant to the current problem: 
   a) History of the machine showing, if available, entries for:
         field engineers intervention session, including, e.g. replacement of pieces;   previous collaborative troubleshooting sessions;   previous user troubleshooting sessions;   maintenance sessions, including, e.g. replacement of consumables;   alerts, e.g. paper jam;   normal interactions, e.g. opened tray  1 .       

   The history could be represented: (1) simply as an unstructured or structured list (e.g. a tree) or (2) as a state diagram, where nodes represent status of the machine, or (3) by an animation showing the physical changes in the status of the machine. The troubleshooter can navigate the entries in the history for seeing more details, discovering actions performed by the user on the machine before calling the service or similar problems already occurred. 
   b) Current status of the machine including:
         1. a visual description of the machine (by a virtual model or images) as the user currently sees it. In addition, this representation could be enhanced with a view from different spatial perspectives (front-side, left-side, right-side, back-side) to facilitate at-a-glance recognition of problems;   2. other potential options such as:
           i. a sample of an image quality problem;   ii. a sample of noises the machine is producing;   iii. a sample of abnormal vibrations.   
               

   c) Position of the user with respect to the machine, displayed with the visual representation of the machine and the spatial perspectives. 
   d) Means with which to interact through the SVP. 
   After the SVP interface is established, the user can perform actions on the machine and is provided with an imaging interface on a display showing the current status of the interaction. Thus, the SVP comprises a bi-directional visualization of a selected virtual representation between the machine and the advising troubleshooter. 
   During the troubleshooting process, the troubleshooter  12  can give the user  20  instructions on what to do to perform specific troubleshooting operations, e.g. removing parts of the machine, etc. The troubleshooter is provided with a UI showing:
         a main interactive window showing the current status of the machine as resulting from the interaction, including current sensed actions (e.g. an opened tray); the history of the machine; if known, and the position of the user.   control buttons in the window showing actions of the user are also provided.       

   In order to communicate  42  the machine problem to the troubleshooting expert, the user usually needs to indicate a part of the machine. Such indication is effected by using the display of the SVP to transmit and identify a signal, e.g. a cursor can indicate the part both on a main window of the display and on the window showing the actions of the user. Also, the user can indicate a part of the machine by percussing it, e.g. tapping on that part, and/or coming into relatively close proximity to it, e.g., entering a field associated with a contactless sensor. Additionally, the user can perform an action on the printer. The information on the action performed by the user is transmitted to the troubleshooter and the troubleshooter will see the results of the user action both on the main window and on the window showing the actions of the user. Such actions, along with the audio conversation effectively communicate  42  the machine problem to the expert. 
   In response to the user actions, the expert on the troubleshooting side can also indicate a part of the machine represented on the main window by adjusting the SVP for the ultimate purpose of suggesting the corrective action to solve the problem. An identified part is remotely shown to the user on the machine display and, alternatively, visual indicators, e.g. LEDs, if available, facilitate part identification. The LEDs on the machine part are activated as a special assist to a particular position to the user. After such indication, the expert will then select an action that the user should perform on the machine or that part which can be represented on the main window showing the SVP. The troubleshooter selects a part and then chooses the appropriate action, e.g. pushing, pulling, rotating or combination, from a menu of available options and the amount of force to be used. Such action is shown to the user on the display and the visual indicators for the selected part are activated. When indicating the amount of force to be used on the part, different brightness intensity will indicate to the user the appropriate strength required for performing correctly the action. Also, the sense of the movement can be indicated in a sequence of activations of the visual indicators. A possibility for specifying an action for the troubleshooter could be select actions from a mnemonic resource and drag-and-drop them on to the presentation of the machine in the main window. 
   Alternatively, the expert can put the user on hold so that the troubleshooter will be temporarily disconnected from the user and its SVP for the purpose, for example, of making some tests without sharing them with the user. In this situation, on the user side, the window will show a message notifying the user of the holding status. By “hold” is meant a muting activity where the term “hold” serves to preserve the existing telephone metaphor used by call center troubleshooters. 
   An important aspect of the subject system is that the user can compare the actual state of the machine with the SVP provided by the expert to identify  48  any difference between what the expert indicates as the correct machine state in the SVP, and the actual state seen by the user. For example, if the SVP shows a particular latch as correctly being in position, and the user by the comparison can see that the latch is not in SVP position, the mispositioning of the latch may be the source of the problem and its movement to the correct position may be the desired corrective action sought by the user. In communicating the particular positioning of the subject componentry, the user may again initiate  50  percussion and/or contactless actions for identifying selective machine positions and/or the componentry. The system sensors within the machine can recognize  52  and communicate through the communication link the selected position and/or componentry for clearly identifying the difference between the actual machine state and the SVP state being considered by the expert. The problem and differences are then identified  54  to the expert who can then clearly indicate to the user the corrective action so that the user can then execute it  56 . 
   It is to be appreciated that the foregoing example is provided for explanatory purposes and is not limiting. For instance, it is to be understood that there can be one or more communications for expressing problem and/or one or more communications for suggesting an action to resolve the problem. For example, after executing a corrective action  56 , one or more other SVPs can be generated  38  and synchronously displayed  40  to both the user and the troubleshooting expert. 
   With reference to  FIGS. 3 ,  4  and  5 , exemplary devices comprising the subject system are shown.  FIG. 3  illustrates a device  80  having a contactless sensor  82 , e.g., a contactless capacitive sensor, which is capable of contactless detection of human proximity for identifying a component of the device  80 . As described in detail above, in order to communicate the problem to the troubleshooting expert, the user usually identifies a part of the device to the expert. The user can indicate the part of the device  80  by disturbing the field generated by the contactless sensor  82 , e.g. by penetrating the field with a hand or finger, as depicted. The information is conveyed to the troubleshooter via a position controller  84 , and the troubleshooter can visualize the results on the SVP  86 , as described in detail above. The results and any audio conversation effectively communicate the problem to the expert. 
     FIG. 4  illustrates the device  80  having a percussion sensor  88  for identifying a user selected component of the device  80 . The user can indicate a part of the device  80  by percussing, or tapping on it. Likewise, the information is conveyed to the troubleshooter via a position controller  84 , who visualize the results on the SVP  86 , and the results and any audio conversation effectively communicate the problem to the expert. 
     FIG. 5  illustrates visual indicator positioning to better identify device or componentry positioning. In response to the user actions detected by the contactless and percussion sensors described in  FIGS. 3 and 4 , the expert on the troubleshooting side can indicate a part of the device  80  via the SVP  86  for suggesting a corrective action to solve the problem. An identified part is remotely shown to the user on a display  90  through various visual indicators  92  such as one or more illumination elements. As depicted, a LED controller  94  can be used to illuminate one or more of the visual indicators  92 . The expert can then select an action that the user should perform on the device  80  or the identified part component of the device  80 . This action is provided to the user, and the visual indicators  90  for the selected component are activated. 
   The protocols described above for the subject collaborative troubleshooting are merely exemplary and can be reordered in a sequence that the user and expert may determine to further enhance the efficiency of the communication process. 
   It will be appreciated that various of the above-disclosed and other features and functions, or alternatives thereof, may be desirably combined into many other different systems or applications. Also that various presently unforeseen or unanticipated alternatives, modifications, variations or improvements therein may be subsequently made by those skilled in the art which are also intended to be encompassed by the following claims.