Abstract:
A device management system and method is provided. The device management system and method includes a transmission server to transmit a communication from at least one device. A reception server receives the communication from the at least one device. And a device manager coupled to the reception server manages the at least one device by automatically parsing the communication received by the reception server. The device manager authorizes the communication for further processing where the device manager includes a device list including identification data associated with the at least one device. The device manager includes an alert processing component that generates an alert message responsive to the device list.

Description:
BACKGROUND 
     1. Field 
     The invention relates to a device management system and method. 
     2. Related Art 
     Office equipment manufacturers often lease office equipment to business owners either directly or through dealers (collectively dealers). Office equipment might comprise fax, copy, scan, printing, or multi-function devices or machines. The lease fee may be based on “clicks:” the number of faxes, copies, scans, and/or printouts run through the leased device. The lease fee may additionally be based on consumable usage. That is, on the amount of paper, toner, ink, and the like used by the business owner during a predetermined period. 
     The dealers must proactively replenish necessary supplies to the leased devices. And the dealers are responsible for maintaining the leased devices in proper working order, as well as keeping track of the clicks and consumable usage. To this end, the dealers have developed manual and semi-automated means of collecting the click counts and consumable usage on the leased devices. The leased devices are notably often located geographically distant from the dealer. 
     Manually collecting click counts involves a dealer representative visiting the business owner on a regular basis to inspect the leased device. The dealer representative obtains the click counts by, e.g., pressing a predetermined sequence of buttons on the device&#39;s front panel. During the visit, the dealer representative may also stock the business owner with needed consumables based on the clicks obtained from the device. For billing purposes, the representative may manually input the click count and consumable usage into a dealer management system designed to generate lease bills. Alternatively, the business owner obtains and then faxes the click counts and usage to the dealer. The dealer then manually inputs the click counts and usage into the dealer management system. 
     Semi-automatically collecting click counts involves coupling the leased device to a computer network and providing the leased device with the ability to automatically generate a status report. The status report may include the click counts and certain other status information. 
       FIG. 1  is a diagram of a conventional semi-automatic system  100 . Referring to  FIG. 1 , a system  100  includes a plurality of devices, e.g.,  110 A,  110 B, and  110 C, networked to a site server  120  through network capable devices, e.g., network interface cards (NICs) (not shown) installed in the devices  110 A,  110 B, and  110 C. The plurality of devices  110 A,  110 B, and  110 C are leased to a customer  130 . The site server  120  may be coupled to a dealer server  150  through a global communication network  140 , e.g., the Internet®. A plurality of customers like customer  130  may be coupled to the dealer server  150  through the network  140 . The dealer server  150  may receive the status report directly and automatically from the leased device, e.g., device  110 A. A person  160  downloads the status report from the server  150 . A person  170  gets the status report from the person  160  and then manually inputs the information to a dealer management system  180 . The dealer management system  180 , in turn, automatically generates a bill to the customer  130 . Persons  160  and  170  may be the same person or they may be distinct persons. 
     A disadvantage to manual and semi-automatic data collection is cost. As manual labor costs increase, so do costs associated with visits to collect and input click counts. Manual data collection and input is fraught with errors. And manual and semi-automatic click count and other data collection takes valuable time away from the dealer&#39;s staff, time needed to respond to consumable calls for restocking paper, toner, and drums, conducting preventative maintenance, and/or servicing leased device breakdowns 
     Accordingly, a need remains for an improved device management system and method. 
    
    
     
       BRIEF DRAWING DESCRIPTION 
         FIG. 1  is a diagram of a conventional system. 
         FIG. 2  is a diagram of an exemplary system including a device management system according to the present invention. 
         FIG. 3  is a block diagram of an exemplary device management system. 
         FIG. 4  is a block diagram of an exemplary processing component. 
         FIG. 5  is a block diagram of an exemplary retrieval component. 
         FIG. 6  is a block diagram of an exemplary extraction component. 
         FIG. 7  is a block diagram of an exemplary parsing component. 
         FIG. 8  is a block diagram of an exemplary authorizing component. 
         FIG. 9  is a block diagram of an exemplary filtering component. 
         FIG. 10  is a block diagram of an exemplary data preparation component. 
         FIG. 11  is a block diagram of an exemplary external interface component. 
     
    
    
     DETAILED DESCRIPTION 
     The following description illustrates embodiments of the present invention. Numerous other embodiments are contemplated and the description is intended only to illustrate, and not limit, the present invention. Like reference numerals throughout the drawings denote like structures. 
       FIG. 2  is a diagram of an exemplary system including a device management system  202  according to the present invention. Referring to  FIG. 2 , the system  200  includes a plurality of devices, e.g.,  110 A,  110 B, and  110 C, networked to a site server  120  through network capable devices, e.g., network interface cards (NICs) (not shown) installed in the devices  110 A,  110 B, and  110 C. The plurality of devices  110 A,  110 B, and  110 C are leased to a customer  130 , e.g., a business owner. The site server  120  may be coupled to a dealer server  150  through a global communication network  140 , e.g., the Internet®. A plurality of customers like customer  130  may be coupled to the dealer server  150  through the network  140 . A person of reasonable skill in the art knows well the design of devices  110 A,  110 B, and  110 C, servers  120  and  150 , and circuitry necessary to network the devices to the servers, e.g., NICs. We will not discuss these devices, servers, and circuitry in any further detail. 
     The devices  110 A,  110 B, and  110 C automatically generate a status report. The status report may be any communication, e.g., email, automatically generated by the device  110 A,  110 B, or  110 C and capable of being transmitted to the servers  120  and  150 . The status report may include all manner of status information, including device identification information (e.g., serial number), device operating status (e.g., on or off line, paper jam, malfunction indication), consumable status (e.g., paper, toner, and/or ink levels), etc. 
     The status report may include a title, a body, and any number of attachments. The body of the status report may be a short summary of the information contained in the attachments. The body may include the click counts and identify the reporting device (e.g., by providing a serial number). The body may be readily human readable while the attachments may not. The attachments may include machine readable binary data. The attachments may include the click counts as well as other more detailed status information, including toner level, serial number, connection status, server identification, network gateway identification, and the like. The status report may further be designated as an alert or status message. 
     For simplicity, we will refer to the status report as an email. But a person of reasonable skill in the art should recognize that the present invention is not limited to emails. Rather, the present invention contemplates that any type of communication capable of being transmitted from a server  120  to a server  150  and generated by any electronic device to indicate its status comes within the scope the present invention. The incoming email accounts may be specified by a user, e.g., a dealer or business owner, during application configuration. The email addresses configured during application configuration may include incoming, archive, exception, alert, and self identity email addresses. 
     Table 1 is an example status report generated by a device, e.g., device  110 A. 
     
       
         
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 Field 
                 Example 
               
               
                   
                   
               
             
             
               
                   
                 Date/Time 
                 2000/02/27 
               
               
                   
                 DEVICE 
                 Cougar34 
               
               
                   
                 DEVICE 
                 SHARP AR- 
               
               
                   
                 LOCATION 
                 2 nd  Floor 
               
               
                   
                 SERIAL 
                 9620160901 
               
               
                   
                 MACHINE 
                 AR-507 
               
               
                   
                 COPY 
                 40084 
               
               
                   
                 PRINT 
                 215984 
               
               
                   
                 TOTAL 
                 256238 
               
               
                   
                   
               
             
          
         
       
     
     Table 2 is another example status report generated by a device, e.g., device  110 A. In this case, the device is alerting the device manager  202  of a low toner. 
     
       
         
               
               
               
             
           
               
                   
                 TABLE 2 
               
               
                   
                   
               
               
                   
                 Field 
                 Example 
               
               
                   
                   
               
             
             
               
                   
                 Date/Time 
                 2000/02/27 
               
               
                   
                 Device 
                 Cougar34 
               
               
                   
                 Model Name 
                 SHARP AR- 
               
               
                   
                 Installed 
                 2 nd  Floor 
               
               
                   
                 Serial 
                 9620160901 
               
               
                   
                 Machine 
                 AR-507 
               
               
                   
                 Message 
                 TONER 
               
               
                   
                   
               
             
          
         
       
     
     The devices  110 A,  110 B, and  110 C transmit the status report to the server  120 . The server  120  may be in the same or a different geographic area than the devices  110 A,  110 B, and  110 C. 
     The server  120 , in turn, transmits the status report to the dealer server  150  through a global communication network, e.g., the Internet®. The site server  120  and the dealer server  150  may be a same server or distinct servers. The site server  120  and the dealer server  150  may operate in a same location or in geographically distant locations. For example, the site server  120  may be located in Portland, Oreg., while the dealer server  150  may be located in Vancouver, Wash. Or both may be located at different parts of a same office building. 
     A device manager  202  retrieves the status report from the dealer server  150 . The device manager  202  interprets data included in the status report and provides properly formatted data automatically to the dealer management system  180 . The dealer management system  180 , in turn, automatically generates a bill to the business owner. A person of reasonable skill in the art knows well the design of the dealer management system  180 . We will not discuss the design of the dealer management system  180  in any further detail. 
       FIG. 3  is a block diagram of the device manager  202 . Referring to  FIG. 3 , the device manager  202  includes an email retrieval component  210 , a data extraction component  220 , a filter  230 , a data preparation component  240 , and an interface component  250 . And the device manager  202  includes an exception component  260  and an archive component  270 . We explain the device manager  202  and its various components in more detail below. 
     The device manager  202  operates as shown in  FIG. 4 . Referring to  FIGS. 3 and 4 , the device manager  202  retrieves an email from the server  150  using the email retrieval component  210 . The data extraction component  220  includes three subcomponents: a data extraction subcomponent  220 A, a data parsing subcomponent  220 B, and an authorizing subcomponent  220 C. The data extraction subcomponent  220 A extracts data from the email into a collection of raw textual data. The parsing subcomponent  220 B parses the extracted data. That is, the parsing subcomponent  220 B parses data from the collection of raw textual data. The email authorizing subcomponent  220 C determines if the parsed data is authorized for further processing. For example, the email authorizing subcomponent  220 C may compare the device identified in the email to a preexisting device list of licensed devices. If the device is not included in the device list because it is not a properly licensed device or because the customer  130  has exceeded its number of properly licensed devices, the device manager  202  and, more particularly, the exception component  260 , generates an alert message that it sends to a predetermined email address, e.g., an alert email address. The alert email address is configured at set up. 
     The filtering component  230  filters the data received from the data extraction component  220 . If the data requires no further filtering, the data flows to the data preparation component  240 . If additional filtering is required, the email is archived or removed from the server  150  by the archive component  270 . The data preparation component  240  transforms (or translated) the extracted data into an intermediate data in a predetermined format, e.g., XML, ready for the interface component  250 . The interface component  250  translates the intermediate format data into a format that is appropriate for exporting to the target dealer management system  180 . The interface component  250  interacts with the dealer management system  180  to send an alert notification if the data transfer is not successful. The corresponding email message will remain in the incoming email server for subsequent email retrieval. 
       FIG. 5  is a block diagram of an exemplary email retrieval component  210 . Referring to  FIG. 5 , the retrieval component  210  retrieves the status report generated by the device, e.g., device  110 A, from the server  150 . In an embodiment, the retrieval component  210  retrieves an email sent by the device, e.g., device  110 A, to a specified incoming email account at the server  150 . 
     The retrieval component  210  activates at a specified frequency configured during setup (box  502 ). If the device manager  202  is running (box  504 ), the retrieval component  210  retrieves an email at box  506  from the server  150 . If the device manager  202  is not running, the device manager  202  stops at  508 . The retrieved email may include raw data  510  in a title, a body, and any number of attachments. 
     It is possible that a previously retrieved email failed at the point of removal from the server  150 . For this reason, the retrieval component  210  may check each email retrieved against the list of previously failed email removals. If it is in the list of failed email removal, then it will not be relayed to the next component. 
       FIG. 6  is a block diagram of an exemplary extraction subcomponent  220 A. Referring to  FIG. 6 , the extraction subcomponent  220 A receives the raw email data  510  from the retrieval component  210 . The subcomponent  220 A determines whether the email includes any attachments at box  602 . If attachments exist, the extraction subcomponent  220 A extracts all attachments at  604  and then extracts the raw binary data from all attachments at  608  (if such exists). The attachments may also have textual data that is extracted at  608 . If no attachments exist, the extraction subcomponent  220 A extracts the raw textual data from e.g., the title and body of the email at  606 . The extraction subcomponent  220 A compiles the extracted textual and binary data  610  and provides it to the parsing subcomponent  220 B. The extracted textual and binary data  610  may include a collection item related to the body that is in textual format while all other collection items may be in binary format. 
       FIG. 7  is a block diagram of an exemplary parsing subcomponent  220 B. Referring to  FIG. 7 , the parsing subcomponent  220 B parses the extracted textual and binary data  610  at box  702 . The parsing subcomponent  220 B may create an internal data structure with the parsed data  702 . At box  706 , the parsing subcomponent  220 B determines whether the parsing was successful. If it was not (perhaps because of a syntactical error), it forwards an exception message to an exception email address at the server  150  (box  708 ). The exception message may be the original email forwarded to an exception email address for further human processing. The server  150  may serve both as incoming and outgoing servers, or two different servers may be used depending on the application. If the exception message was successfully forwarded to the server  150  at  708 , the parsing subcomponent  220 B removes the original email from the (incoming) server  150  at box  704 . Exception messages are forwarded to the specified (during configuration) exception email address in their original form and may be manually processed by an operator. In an embodiment, the operator may make the necessary corrections, and re-send the email to be reprocessed by device manager  202 . 
       FIG. 8  is a block diagram of an exemplary authorizing subcomponent  220 C. Referring to  FIG. 8 , the authorizing component  220 C determines whether the extracted data  710  meets one of a predetermined number of authorization conditions. One authorization condition may be detection of a device serial number at box  802 . Another authorization condition may be determined by the device list as we explain below. If the authorizing subcomponent  220 C does not find a serial number, it forwards an exception message to server  150  at box  808 . The server  150  may serve both as incoming and outgoing servers, or two different servers may be used depending on the application as we explained above. If the exception message was successfully forwarded to the server  150  at  808 , the authorizing subcomponent  220 C removes the original email from (incoming) the server  150  at box  806 . 
     The authorizing subcomponent  220 C compares the serial number with a device list. The device list may list devices that are properly licensed to the customer  130  ( FIG. 2 ). The device list may have a preset number of allowable entries, consistent with the level of license. The preset number of allowable entries is controlled by the dealer. For example, the customer  130  may have a 50 device license but currently have only 35 devices operating. The device list, therefore, will list the 35 operating devices and allow for 15 more future entries before generating an exception message indicating a full device list. 
     The authorization subcomponent  220 C may add the device to the list if the device list is not full. The device list may be modified to remove older or non-operating devices and allow additional entries before generating an alert message indicating a full device list. The device list may also inform the dealer (at, e.g., a self identity email address) that the customer  130  is at the limit of his license (if, e.g., the license is for 50 devices and the customer wishes to add an additional 10) and may require a license upgrade (e.g., to a 100 device license from a 50 device license). 
     Table 3 is a pictorial view of a device list in the device manager  202 . 
     
       
         
               
             
           
               
                 TABLE 3 
               
               
                   
               
             
             
               
                 
                   
                             
                     
                         
                         
                     
                   
                 
               
               
                   
               
             
          
         
       
     
       FIG. 9  is a block diagram of an exemplary filtering component  230 . Referring to  FIG. 9 , the filtering component  230  gets an alert type  904  from the extracted data  810  output from the authorizing subcomponent  220 C at box  902 . The filtering component  230  determines if the data  810  needs to be filtered at boxes  906  and  908 . This determination may be made on any of a plurality of basis, including an alert type. The alert type may be embedded in the email, as shown above in Table 2 (e.g., low toner). The types of alerts necessitating filtering may be configured at set up. 
     If the data requires additional filtering, the archive component  270  forwards an archive email message to the server  150  at box  912 . The archive email message may be the original email forwarded to an archive email address for archiving purposes. If the archive message was successfully forwarded to the server  150  at  912 , the filtering component  230  instructs the user to remove the initial email from the server  150  at box  910 . 
       FIG. 10  is a block diagram of an exemplary data preparation component  240 . Referring to  FIG. 10 , the data preparation component  240  receives the data  810  from the filtering component  230 . At box  1002 , the data preparation component  240  transforms the data  810  into data  1004  having a predetermined intermediate format, e.g., XML. The data preparation component  240  provides the data  1004  to the interface component  250 . 
       FIG. 11  is a block diagram of an exemplary interface component  250 . Referring to  FIG. 11 , the interface component  250  exports the data  1002  to the dealer management system  180  (box  1102 ). The exported data module may be in the form of a Windows® dynamic link library (DLL) file. If the interface  250  successfully exports the data (box  1104 ), it forwards an archive email message to the server  150  (box  1114 ). If the interface  250  successfully sends an archive email to the server  150  responsive to the successful exportation, it removes the email from the (incoming) server  150  (box  1112 ). 
     If, on the other hand, the interface  250  fails to export the data (box  1104 ) and detects data errors (box  1108 ), e.g., an unrecognizable device name and/or serial number, it forwards an exception email to the (outgoing) server  150  at box  1110 . If the interface does not detect data errors, it instead sends an alert notification to the user or operator. 
     The dealer management system  180  populates its database  182  with the data  1002  exported by the interface  250 . 
     While we have illustrated and described this invention with reference to some embodiments, those skilled in the art will understand that they may make various changes in form and detail without departing from the spirit and scope of the invention as defined by the following claims.