Patent Publication Number: US-7711814-B1

Title: Method and system for remote monitoring of a power supply device with user registration capability

Description:
RELATED APPLICATIONS 
     This application claims priority to U.S. Provisional Application Ser. No. 60/635,797, filed Dec. 13, 2004 and entitled, “Remote Monitoring System,” which is herein incorporated by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     Today, companies and persons rely on having consistent supply of power to electronic devices more than ever. Without power, companies may be unable to manufacture goods, or to operate at all, such as if the company is in the business of supplying information over the Internet. Without power, businesses and individuals may be completely incapacitated regarding critical activities, such as making goods, providing services, and transacting personal finances (e.g., filing tax returns, and paying bills). 
     Frequently, individuals and companies monitor the supply of power to electronic devices or facilities to ensure that their affairs and/or businesses are not significantly affected by a power outage, a change in status or some other power alteration. Uninterruptible power supplies (UPSs) are often used to provide backup power in case of a power outage. UPSs are commonly used on computing equipment to guard against data being lost due to a power outage before the data are saved. UPSs used with computing equipment also help to guard against a loss in service by providers of information over the Internet, such as by servers, e.g., hosting web pages. 
     Device status is often monitored and reported to the individual or company owning a device using email notification or the Plain Old Telephone System (POTS), which requires the installation of a remote monitoring unit at the customer site and is physically dialed into to get updates and specifics. Frequently, companies are obligated to provide manpower at substantial cost so that electronic devices can be monitored and reported on a regular basis. 
     SUMMARY OF THE INVENTION 
     In general, in an aspect, the invention provides a method for monitoring and reporting information regarding status of a power supply/management device operated by a user. The method includes detecting the status of the device using a monitoring device having an application interface configured to communicate over a communication network, generating a status update indication using a self-describing computer language and sending the status update indication over the communication network to a remote computer, and associating the user with the status update information for the remote device using the remote computer. 
     Implementations of the invention may include one or more of the following features. The method can include sending the user registration information to the remote computer comprises sending the user registration information via email. Sending the user registration information to the remote computer can comprise sending the user registration information via HTTP post. Sending the status update indication to the remote computer can comprise sending the status update indication via HTTP post. The method can include generating a user registration using a self-describing computer language and sending the user registration to the remote computer. The method may also include associating the user with the status update information for the remote device using mapping of the user and the device. Sending the user registration information to the remote computer can comprise sending the user registration information via a web service, the web service communicating the user registration to the remote computer. The self describing computer language can include eXtensible Markup Language (XML). 
     In general, in another aspect, the invention provides a system for communicating via a communication network with remote devices connected to at least one management device to monitor and supply a status associated with the remote devices. The system includes a first communication interface connected to the at least one management device configured to transfer status data associated with the remote devices over the communication network, a second communication interface configured to transfer data related to a user registration for a user having at least one remote device in communication with the communication network, a processor configured to receive the status data and the user registration data over the communication network and associate the user registration data with the status data associated with the remote devices, and a manager coupled to the processor and configured to receive and report the status data to the user. 
     Implementations of the invention may include one or more of the following features. The second communication interface can include a remote monitoring service web site on which the user enters user registration data. The manager can produce an event ticket when the status data associated with the remote device indicates a change in status. The processor can be further configured to inspect and manage user contracts associated with the user, and associate the status data and the user registration data based on information in the user contract. The manager can create an executive report and communicates the executive report to the user over a third communication network. Device data retrieved can be utilized for data mining, predictive failure analysis, sales support, quality improvement and technical service support. 
     Characteristics of the invention may include one or more of the following capabilities. A monitoring center can provide a human interface for analyzing and reporting data related to devices at remote locations. Customers can be directly contacted via phone, email or other means upon severe event occurrence. Service start-up of devices is monitored by the remote monitoring center. Device registration can be performed automatically in response to device purchase. Outsourcing for management of tickets, contracts or bulletin board notices may be alleviated. Data may be analyzed to determine maintenance needs. Implementation of additional remote monitoring devices at the site of electronic devices is avoided. Troubleshooting can be accomplished via a service center and can occur at the time of event occurrence. Devices can be controlled via the remote monitoring service to alter operations when events occur. Manpower for monitoring internal systems at the customer site and cost related thereto can be reduced. 
     These and other capabilities of the invention, along with the invention itself, will be more fully understood after a review of the following figures, detailed description, and claims. 
    
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         FIG. 1  is a diagram of a system for monitoring power status information for a remote location. 
         FIGS. 2A and 2B  are exemplary screen displays for user registration associated with monitored locations. 
         FIGS. 3A-3C  are exemplary screen displays of event management information associated with monitored locations. 
         FIG. 4  is an exemplary report of status information associated with a monitored location. 
         FIG. 4A  is a computer monitor showing an exemplary report of status information as described in  FIG. 4 . 
         FIG. 5  is a block flow diagram of a process of monitoring power status information for a remote location. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     Embodiments of the invention provide techniques for monitoring devices from a remote location, reporting the status of devices and controlling devices from the remote location. Devices can be monitored at distributed locations, reported to a centralized monitoring system and controlled by the centralized system. Remote management can be accomplished using a web portal, an application interface and a remote monitoring event manager. The application interface is associated with electronic devices. Data collected from the application interface can be transported to the event manager as an email. Data collected from the application interface and the web portal can be displayed as Hyper-Text Transfer Protocol (HTTP) post data at the remote monitoring center. Customer information can be sent from the monitored device at startup, and can be XML formatted. Device data can also be XML formatted. The system includes a built in trouble ticketing system and a notification system. A customer having a device can utilize a remote monitoring system web site to enter contact information, create and view reports and define event escalation rules that are related to the monitored devices. The application interface acts as a proxy between the device and the event manager at the remote monitoring center. The event manager monitors incoming device alarms at a location remote from the devices. Devices monitored can include uninterruptible power supplies (UPS&#39;s), cooling devices, environmental probes, and power distribution devices. Devices can include power management software or a management device to monitor performance. Devices containing the power management software can be distributed throughout the country, and even globally. Reports on the status of devices can be generated and information provided to users in various ways such as over the Internet. Other embodiments are within the scope of the invention. 
     Referring to  FIG. 1 , a system  10  includes a customer site  12 , a communications network  14  and a remote monitoring center  16 . The customer site  12  includes monitored devices  18 , a management device (MD)  22 , a remote monitoring system application layer interface (API)  24  and a web portal  26 . Each device  18  can have its own MD  22 . The remote monitoring center  16  includes a database  30 , a server  32  and an event manager/viewer  34 . The server  32  and the remote devices  18  are configured with communication interfaces and coupled for uni-directional communication with the network  14 . For example, the API  24  is embedded in the MD  22  to allow communication between the devices  18  and the network  14 . The API  24  can be embedded within a management device, an ISX Manager®, and/or PowerChute® Business Edition (PCBE), or other hardware and software applications, for example. In at least some embodiments, the MD  22  is coupled directly to the communications network  14 . The server  32  can be, e.g., a single computer server or a bank of servers, and information flowing into and out of the bank of servers may be load balanced. The communication network  14  can be any of a variety of communication networks currently known (e.g., the Internet, a local area network (LAN), a wide area network (WAN), an integrated services digital network (ISDN), a wireless network, etc.) or developed in the future. Although only one server  32  and three remote devices  18  are shown, other numbers of servers  32  and/or remote devices  18  may be used. For example, the monitoring center  16  may include a web server and a mail server separately. The monitored devices  18  can be any of several types of devices, e.g., uninterruptible power supplies, battery management systems or other electronic devices or groups of electronic devices, etc. The monitored devices  18  may be disposed remotely from each other such as in different zip codes, cities, counties, states, or countries. 
     The devices  18  communicate with the MD  22 , which accepts data related to the status of the devices  18 . Remote monitoring units other than the MD  22  can directly interact and communicate with the server  32  over the network  14 . The MD  22  includes a processor for performing instructions in software in the API  24 . The software in the MD  22  is also configured for general interaction with the devices  18 . The MD  22  is configured to detect power status, temperature, humidity, load and other status information at the devices  18 . The API  24  is embedded in the MD  22  and is configured as a software program to provide an interface between the devices and the server  32  at the remote monitoring center  16 . The API  24  processes the information collected and sends the information via the communication network  14  to the server  32 . The API  24  is configured to receive information regarding status from the server  32  via the network  14 . Other configurations of the API  24  are possible such as pure hardware configurations, or combinations of hardware and software, etc. 
     The MD  22  can detect that a device  18  switches and/or has switched to battery operation, detect increases/decreases in temperature, and detect other activity indicating an event, such as an outage or a reduction or increase in power exceeding a threshold. In response to an event, the MD  22  produces and sends an indication of the event (e.g., power failing to meet requirements) that gets transmitted through the network  14  to the server  32 . The event indication provides the server  32  with a variety of information regarding the event. For example, the information can include a time of the event. The MD  22  is configured to determine and report resolution of an event. The MD  22  is further configured to detect status information other than power considerations, such as load considerations, temperature, and humidity. 
     Information provided to the server  32  through the API  24  in the MD  22  is preferably provided using a low-level protocol and is done in a manner to reduce the likelihood of simultaneous high-reporting traffic. For example, the information is provided using an HTTP POST command, via email, via web services or via other techniques. The information is reported asynchronously from the API  24 . Techniques can be used to help prevent reporting congestion including aggregating multiple power events into a single report and reporting them in one transaction. 
     The API  24  is configured to provide heartbeat signals to the server  32 . The heartbeat signals provide periodic (or possibly aperiodic) indicia that the devices  18  are operational and that the equipment between the API  24  and the server  32  is operational and connected. The server  32  is configured to expect the heartbeat signals from the reporting units and to respond if one or more of the heartbeat signals are not received, e.g., within an expected time frame. For example, if no heartbeats are received in a threshold amount of time, the server  32  may determine that a failure has occurred in the reporting units, the devices  18 , the network  14 , and/or one or more connections of these devices/systems to the server  32 . The server  32  may respond by indicating a failure. If multiple heartbeats from multiple reporting units are not received within the same time frame, the server  32  may surmise that the network  14  has failed or that another, relatively global (as opposed to isolated to a particular reporting unit) failure has occurred, such as a large-scale power outage. 
     The web portal  26  is configured to communicate over the network  14 . Information entered at the web portal  26  is communicated to the event manager  34  via the network  14 . The web portal  26  allows a customer to enter and modify profile data (e.g., customer registration info), view contracts, define event escalation rules related to the operation of a device  18 , view an alarm/event log and view device specifics (product and model type) and data points. The customer registration information describing and/or identifying the customer and entered at the web portal  26  is sent to the database  30  for storage at the monitoring center  16 . The server  32  processes the customer data with incoming data from the API  24 . Customer data is associated with the device data at the monitoring center  16 . Customer data is preferably sent once and mapped to the device  18  serial numbers, e.g., by cross referencing purchases made by the customer. The customer information is sent in XML format. The API  24  also sends device data in XML format, in configurable time periods, e.g., heartbeat data every 10 minutes and status data every 8-24 hours, although other formats are possible. For example, the customer registration information can be transmitted via a web service operated by the remote monitoring center  16 . The customer can log on and enter registration information on an RMS web page, e.g., hosted by a server associated with the RMS  16 , and transmit the entered data via a web service to the server  32 . The server  32  is configured to host the web page for information entry. 
     Through the web portal  26 , on-line help is available. Access permissions at the web portal  26  include Network Operations Center (NOC) super administrators, NOC administrators, NOC user, company administrators (e.g., for editing customer data and creating company users), and company user, which can be designated as read-only. Other access permissions can be enabled. The web portal  26  defines alarm/event escalation based on activity from the devices  18 . Real time data graphs are generated based on the activity monitored and recorded at the monitoring center  16 . 
     The customer registration information entered at the web portal  26  is transmitted via a website operated by the remote monitoring center  16 . Alternatively, the website  27  can be operated by a party other than the remote monitoring service  16  provider. The customer logs on and enters registration information on a Remote Monitoring Service web page, and transmits the data via the communication network  14  to the server  32 . 
     The server  32  is configured to receive and process (e.g., in a server processor) incoming power anomaly/event indicia from the API  24  and to provide server output signals that include power status information such as accumulated/aggregated and collated power anomaly information. The server  32  collects data from multiple individuals/companies/devices/organizations/locations. Information processed by the server  32  is stored in the database  30 . The server  32  is configured to determine start times and end times of power anomalies and associated locations of the power anomalies. For example, the server determines start and end times by processing received indicia of beginnings and ends of power events, with associated information as to locations of the reporting units and/or the corresponding devices  18 . The server  32  is configured to determine timing of events, as events are time stamped (or by cross-referencing a clock, etc.). 
     The server  32  accumulates the event information and other device information received to determine status reports on a per customer basis and provides reports to the event manager  34  and/or the customer. The reports indicate events occurring at one or a number of locations, and identify the device  18  affiliated with an event. The server  32  processes the information, whether the information is in email format, HTTP format or other known data formats. The data is parsed and stored on the database  30 . 
     The event manager  34  is configured to receive and process output signals from the server  32  to provide desired information to users of the remote devices  18 . For example, the server  32  receives data and associated customer information and the data are displayed by the event manager  34 . The event manager  34  also evaluates the server output signals to determine whether action at the customer site  12  is warranted/desirable. The event manager  34  monitors incoming device alarms that are sent from the API  24 . The API  24  acts as a proxy between the device  18  and the event manager  34 , and substantially all data are sent through the API  24 . The server  32  receives customer data via HTTP and device alarms via HTTP, both in XML format. The event manager  34  provides a hypertext link to the remote monitoring system web site  27 . 
     The event manager  34  provides a built-in trouble ticketing system associated with the incoming alarms. Trouble ticket viewing is restricted to designated individuals at the customer site  12 . Trouble ticket viewing can be provided, for example, at two permission levels: NOC personnel and Remote Monitoring System customers. The web portal  26  includes a built-in bulletin board for internal NOC notification. From the event manager  34 , the monitoring operation center has a hyperlink to the remote monitoring website  27 . Device information is retrieved from the remote service website  27 . 
     With continued reference to  FIG. 1 , and referring to  FIGS. 2A-2B , a user having at least one device  18  registers for the monitoring system by completing profile data at the web portal  26 . An RMS Settings screen  40  includes a company information page  42  and a contact information page  44 . The company information page  42  prompts for entry of a company name  45 , a location  46 , a phone number  47 , an address  48 , a country  49 , a city  50 , a state  51 , a province  52 , a zip code  53  and a time zone  54 . Other fields can be included on the company information page  42  (e.g., fields suited for other countries). The contact information page  44 , shown in  FIG. 2B , prompts for entry of an email address  55 , a password setting  56 , a name  57 , a title  58 , a phone number  59  and a phone type  60 . Data entered are saved in the remote monitoring system database  30  and are accessible over the web portal  26  at the customer side and by the event manager  34  on the monitoring side. The RMS website  27  is accessed by the customer to update contact information. Customer information is sent to the monitoring center  16  from the monitored device  18  upon start-up of the device  18 . 
     The customer information is XML formatted and is sent in an HTTP post and/or in an email message. Device registration is completed automatically by associating the device  18  with a customer using knowledge of which device  18  (including unique identifiers, e.g., serial numbers) the customer is using or has purchased. XML is a self describing computer language. XML allows the creation and format of custom document tags, as opposed to HTML which has fixed tags, e.g. &lt;HEAD&gt; and &lt;BODY&gt;. The exemplary customer XML template used to generate the customer registration information sent to the event manager is as follows: 
     &lt;?xml version=“1.0” encoding=“UTF-8”?&gt; 
     &lt;!--DTD generated by XML Spy v4.4 U (http://www.xmlspy.com)--&gt; 
     &lt;!ELEMENT APCRMCustLink (Company+)&gt; 
     &lt;!ATTLIST APCRMCustLink 
     xmlns:xsi CDATA #REQUIRED 
     xsi:noNamespaceSchemaLocation CDATA #REQUIRED 
     &gt; 
     &lt;!ELEMENT Address1 EMPTY&gt; 
     &lt;!ELEMENT Address2 EMPTY&gt; 
     &lt;!ELEMENT Company (CompanyName, CompanyPhone, LocationList, DeviceContactList)&gt; 
     &lt;!ELEMENT CompanyName EMPTY&gt; 
     &lt;!ELEMENT CompanyPhone EMPTY&gt; 
     &lt;!ELEMENT Contact (FirstName, LastName, EmailAddress, Password?, Title, PhoneList)&gt; 
     &lt;!ATTLIST Contact 
     Status (Active|Inactive) #REQUIRED 
     Role (Admin|User) #REQUIRED 
     Owner (False|True) #REQUIRED 
     &gt; 
     &lt;!ELEMENT ContactList (Contact+)&gt; 
     &lt;!ELEMENT CountryCode (#PCDATA)&gt; 
     &lt;!ELEMENT Device (DeviceDescription)&gt; 
     &lt;!ATTLIST Device 
     Model CDATA #REQUIRED 
     Identifier CDATA #REQUIRED 
     ParentIdentifier CDATA #IMPLIED 
     &gt; 
     &lt;!ELEMENT DeviceContact EMPTY&gt; 
     &lt;!ATTLIST DeviceContact 
     EmailAddress CDATA #REQUIRED 
     Identifier CDATA #REQUIRED 
     Priority (1|2|3|4|5) #REQUIRED 
     &gt; 
     &lt;!ELEMENT DeviceContactList (DeviceContact+)&gt; 
     &lt;!ELEMENT DeviceDescription EMPTY&gt; 
     &lt;!ELEMENT DeviceList (Device*)&gt; 
     &lt;!ELEMENT EmailAddress EMPTY&gt; 
     &lt;!ELEMENT FirstName EMPTY&gt; 
     &lt;!ELEMENT LastName EMPTY&gt; 
     &lt;!ELEMENT Location (LocationName, Address1, Address2?, Municipality, Region, PostalCode, CountryCode, Timezone, ContactList, DeviceList)&gt; 
     &lt;!ELEMENT LocationList (Location+)&gt; 
     &lt;!ELEMENT LocationName EMPTY&gt; 
     &lt;!ELEMENT Municipality EMPTY&gt; 
     &lt;!ELEMENT Password EMPTY&gt; 
     &lt;!ELEMENT Phone EMPTY&gt; 
     &lt;!ATTLIST Phone 
     Type (cell|fax|home|office|phone) #REQUIRED 
     &lt;!ELEMENT PhoneList (Phone+)&gt; 
     &lt;!ELEMENT PostalCode EMPTY&gt; 
     &lt;!ELEMENT Region EMPTY&gt; 
     &lt;!ELEMENT Timezone EMPTY&gt; 
     &lt;!ELEMENT Title EMPTY&gt; 
     Referring to  FIGS. 3A-3C , the event manager  34  is used by the remote monitoring center  16  to assess device status. The event viewer screen  70  provides a synopsis of data related to a device  18  for review at the event manager  34 . Preferably, the event viewer screen  70  provides data on a number of customers per screen. The RMS event viewer screen  70  is accessible at the event manager  34 . The event viewer screen  70  includes an events page  72  ( FIG. 3A ), a tickets page  74  ( FIG. 3B ), and an activities page  76  ( FIG. 3C ). The event viewer screen  70  can include an emails page  78 , an audit trail page  80  and a callbacks page  82 , as well as other pages. In  FIG. 3A , a snapshot of the events page  72  includes fields for a company name  90 , an identifier  92 , an event description field  94 , ticketID  96 , a ticket state field  98 , a count  100  and a date field  102 . Information on the screen  72  can be filtered by any of the fields  90 ,  92 ,  94 ,  96 ,  98 ,  100  and  102 . For example, in  FIG. 3A , data are filtered by company name  90 . In  FIG. 3A , events  71  are color coded for visual inspection, i.e., such that the most severe events can be visually identified quickly. For example, severe events  73  can appear in red, while less severe events  75  can appear in blue, with different colors representing gradations of severity in between. Severe events automatically create trouble tickets which outline the escalation process specific to an event  94 . An operator at the monitoring center  16  selects an event  71 , follows the escalation steps, adds notes, creates bulletin boards and closes out open tickets in the ticket state field  98 . 
     In  FIG. 3B , information is sorted by open tickets  104 . A selected open ticket  104  presents profile information for the customer  90 , as well as notes  106  related to the status of the device  18 . Each open ticket  104  is assigned to a service individual  108  residing at the monitoring center  16 . Data related to the event, such as the frequency of the occurrence, the urgency and the device data are presented on the event viewer  70 . Service is provided from the assigned individual  108  based on the event viewer  70  data. In  FIG. 3C , activity related to a particular ticket identification can be viewed. A company contact  110  and mode of contact  112  are available to the service individual. The contact  110  can be contacted directly, or via passive means where indicated. The contact information is that collected from the website  27 , where the customer has registered. 
     Referring to  FIG. 4 , a report is generated based on the data collected at the event manager  34 . The report  120  includes an executive summary and details of the activity for a customer&#39;s devices  18  over a week, a month, a quarter, or a year. The report  120  can be generated over another specified duration, such as more frequently than a quarter, or less frequently than a quarter. The report  120  includes a contact portion  122  and an executive summary  124 . An executive summary  124  includes a system availability analysis  126 . The actions required section  128  provides a brief synopsis for the customer for any actions pending. The event summary includes an event summary table  130  and visual graph  132  showing the occurrence of severe, warning, informational and total events over the given time period. The report  120  also includes a severe events synopsis  134 . A recommendations section  136  can, for example, include event manager recommendations to improve the efficiency of the devices  18  or to alter the system at a customer site. The report  120  also includes a details section  138 . The details section  138  provides a snapshot of an identified device and its parameters over the time period. For example, the details section  138  can include a breakdown of device activity for UPSs  140 , PDUs  142  and Environments  144  present at a customer site, or other numbers of such tables. Information, such as load percentage, runtime, balanced systems, power, and temperature and humidity are summarized in the device activity tables  140 ,  142  and  144 . The report  120  can include as many or as few device activity tables as there are devices/systems at the customer site. System evaluation is possible via the periodic reports  120 . The customer or user accesses the report  120  via the RMS website  27 . 
     Referring to  FIG. 4A , a computer monitor  150  includes the report  120  as a screen view. The report  120  may be arranged in a number of formats for presentation to the user. For example, the Contact data  122 , executive summary  124 , availability  126 , actions required  128 , event summary  130 , graph  132 , severe events summary  134 , recommendations  136 , and details  138  sections can be arranged in any order within the report  120 . Different presentation formats, e.g., line graphs, pie charts, stacked bar charts, etc., may be used to provide the information. Further, additional information can be added or removed based on the event activity for the specified time period. 
     The remote monitoring system  10  and reporting system can be used for a variety of applications. An exemplary use of the system  10  is to provide an integrated monitoring system for use at a customer site. The customer site  12  can include one or more devices in the monitoring scheme. The system  10  can be integrated into an environment where a user has a separate monitoring center staff, rather than utilizing a centralized monitoring staff. These examples are not limiting, as other applications are within the scope of the invention. 
     In operation, referring to  FIG. 5 , with further reference to  FIGS. 1-4 , a process  200  for monitoring and reporting device status using the system  10  includes the stages shown. The process  200 , however, is exemplary only and not limiting. The process  200  can be altered, e.g., by having stages added, removed, or rearranged. 
     At stage  202 , a user registers by entering contact information at a web portal  26  or device user interface. The user can make a one-time entry of customer profile information. The user chooses to be a part of the remote monitoring service that monitors and reports status information of the devices  18  at the user site  12  by registering at the Remote Monitoring Service website  27 . The website  27  can be operated by the remote monitoring center  16  or by a third party. The user enters information, such as name, location, address, time zone, and direct contact data. The customer data may also, or alternatively, be sent by XML or HTTP post. Device registration is accomplished automatically via the API  24 . 
     At stage  204 , a monitored device  18  is started up. At start-up, device information is sent automatically from the monitored device  18  to the event manager  34 . User data and device data are associated at the monitoring center  16 , e.g., using a lookup table with device information (e.g., serial number) and corresponding customer data. Devices at the user&#39;s location are associated with the user via the registration data entered at the web portal  26 . The device data can be XML formatted and can be sent to the server  32  via HTTP post. 
     At stage  206 , the API  24  sends heartbeats and/or separate or included indicia of power events for the device  18 . For example, a power problem/event/anomaly or a return of power occurs at the device  18  and the API  24  reports the anomaly. The API  24  reports information regarding the time of the anomaly and the location of the device  18 . The monitoring center  16  associates the incoming HTTP post with the customer data and stores the associated data in the database  30 . The information is parsed, e.g., by reading tags, and data are retrieved for storage. 
     At stage  208 , detailed device information is retrieved. The data are stored in the database  30 . A staff member at the remote monitoring center  16  can review and monitor the device data using the event manager  34 . For example, a staff member can inspect power activity, power outages, event occurrence and other status information related to one or many of the devices at one or more customer sites  12 . The staff has a hyperlink to the remote monitoring website, and device information is retrieved for use at the event manager  34 . Device specifics may not be duplicated at the event manager  34  due to the hyperlink. 
     At stage  210 , the staff member at the event manager  34  contacts the customer based on the device data retrieved. For example, if an event  71  has occurred, the event manager  34  displays the severity of the event  71  via a color-coded list of events  71 . The event manager  34  can contact a customer where an event has taken place. 
     At stage  212 , the report  120  is generated, e.g., periodically. The report  120  provides a snapshot of the device activity over a specified duration. The report  120  can cover a set duration, such as a one-month period of activity. Users access the report via the RMS website  27 , at the web portal  26  or received the report via email or via postal service. Evaluation and analysis of the event activity is provided through the report  120 . 
     The process  200  depicts a preferable sequence of events. Other stages can be added, or the order of stages can be altered in the process  200 . For example, device data can be received prior to receiving customer registration data. In this instance, the device data are held in a limbo state at the server  32  until the accompanying customer data is received. 
     Other embodiments are within the scope and spirit of the appended claims. For example, due to the nature of software, functions described above can be implemented using software, hardware (e.g., an embedded web card), firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Additionally, power status information can be provided only when an event occurs, rather than at regular intervals. 
     Other embodiments of the MD  22  are possible. For example, the MD  22  may be located in or attached to (e.g., inserted into a receptacle of) the devices  18 . Such devices would be configured to communicate with the network  14  and provide management information.