GB2449518A

GB2449518A - Remote monitoring device

Info

Publication number: GB2449518A
Application number: GB0804278A
Authority: GB
Inventors: Arnaud Denis; Maureen Politte; Randy Calabio; Hoai Nguyen
Original assignee: American Power Conversion Corp
Current assignee: Schneider Electric IT Corp
Priority date: 2007-03-08
Filing date: 2008-03-07
Publication date: 2008-11-26
Anticipated expiration: 2028-03-07
Also published as: GB2449518B; GB0804278D0

Abstract

A method for monitoring and reporting information regarding status of a power supply/management device operated by a user comprises 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.

Description

REMOTE MONITORING SYSTEM

RELATED APPLICATIONS

This application claims priority under 35 U.S.C. ≈I 19(e) to U.S. Provisional Application Serial No. 60/893.772. entitled "REMOTE MONITORiNG SYSTEM." filed on March 8, 2007 and is a continuation in part of U.S. Application Serial No. 11/302,578, entitled "REMOTE MONITORING SYSTEM," filed on December 13, 2005, which claims priority under 35 U.S.C. ≈I 19(e) to U.S. Provisional Application Serial No. 60/635,797, entitled "REMOTE MONITORING SYSTEM," filed on December 13. 2004. Each of these applications is herein incorporated by reference in its en ti rety.

BACKGROUND OF INVENTION

Today, companies and persons rely on having consistent supply of power to electronic devices more than ever. Without power, companies may he unable to manufacture goods, or to operate at all, such as if the company is in the business of supplying inftrmation 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., tiling tax returns, and paying hills).

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 he monitored and reported on a regular basis.

SUMMARY OF INVENTION

S In general, in an aspect, the invention provides a method for monitoring and reporting information regarding status 0! a power supply/management device operated by a user. The method includes detecting the status of the device using a nionitoring device having an application intethice 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 which may comprise sending the user registration intormation 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 HTT'P 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 Imlanageinent 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 i-elated to a user registration for a user having at least one remote device in communication with the communication network, a processor contigured 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/agreements 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 comiTiunicates the executive report to the user over a third communication network. Device dai.a 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/agreements or bulletin board notices may be alleviated. Data may be analyzed to determ i ne in ai ntenance 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 he reduced.

These and other capabilities of the invention, along with the invention itself, will be more fully understood after a review of the following ligures, detailed description, and claims.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are not intended to be drawn to scale. in the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, floE every component s may he labeled in every drawing. In the drawings: FIG. I 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 inftwniation 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 1.5 information as described in FIG. 4.

FIG. 5 is a block flow diagram of a OCCSS of monitoring power status information for a remote location.

FIG. 6 is an example user interface according to one embodiment of the present invention that may he presented as a company home page to a user by a remote device monitoring system.

FIG. 6a is another example user interface according to one embodiment of the present invention that may be presented as part of a company home page to a user by a remote device monitoring system.

FiG. h is another example user interface according to one embodiment of the present invention that may be presented as part of a company home page to a user by a remote device monitoring system.

FIG. 7 is another example user interface according to one embodiment of the present invention that may he presented to a user by a remote device monitoring system to explain system functionality.

FIG. 8 is another example user interface according to one embodiment of the present invention that may he presented to a user by a remote device monitoring system to enter company information. -5--

FIG. 9 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to enter facility information.

HG. 10 is another example user interface according to OflC embodiment of the S present invention that may he presented to a user by a remote device monitoring system to enter contact ink)rtllation.

FIG. I I is another example user interface according to one embodiment of the j)Iesent invention that may be presented to a user by a reniote device monitoring system to enter user information.

FIG. 12 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to associate contacts with devices.

FIG. 13 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to enter reporting preferences information.

FIG. 14 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to validate company profile information.

FIG. 1 5 is another example user interface according to oiie embodiment of the present invention that may be presented to a user by a remote device monitoring system to configure a business rule.

FIG. 16 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to execute a business rule.

FIG. I 7 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to develop a business rule.

FIG. I 8 is another example user interface according to one embodiment of the present invention that may he presented to a user by a remote device monitoring system 3(.) to display monitored device status information.

FIG. 19 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to display KPI overview information.

FIG. 20 is another example user interface according to one embodiment of the S present invention that may he presented to a user by a remote device monitoring system to display KPI statistics information.

FiG. 21 is another example user interface according to one embodiment of the present invention that may he presented to a user by a remote device monitoring system to display service level information.

FIG. 22 is another example user interface according to OflC embodiment of the present invention that may be presented to a user by a remote device monitoring system to display delayed acknowledgement in formation.

FIG. 23 is another example user interface according to one embodiment of the present invention that may be presented to a user by a remote device monitoring system to display a geographical representation of monitored devices.

FIG. 24 shows a general-purpose computer system upon which various embodiments of the invention may be practiced.

FiG. 25 illustrates a storage device of a general-purpose computer system.

FIG. 26 depicts a network of general-purpose computer systems.

FIG. 27 is a flow chart of a method of completing a company profile according to one embodiment of the invention.

DETAILED DESCRIPTION

This invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, the phraseology and terminology used herein is for the purpose of description and should not he regarded as limiting. The use of "including," "comprising," or "having," "containing", "involving", and variations thereof herein, is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

Various embodiments of the present invention provide techniques for monitoring devices from a remote location. Also, various aspects of the present invention relate to reporting the status of devices and controlling devices from the remote location.

According to one embodiment, devices can he monitored at distributed locations, reported to a centralized monitoring system and controlled by the centralized system.

Remote management can he accomplished using a web portal, an application interface and a remote monitoring event manager. The application interface is associated with electronic devices. As discussed below in OflC embodiment, the application interface enables the electronic devices to communicate with other computing devices through a computer network. 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 (H1TP) post data at the remote monitoring center. Customer information can he sent from the monitored device at startup, and can be XML formatted. Device data can also be XML krrnatted. The system includes a built in trouble ticketing system and a notification system. The notification system may include rules that define which contact personnel should he notified when a particular electronic device encounters an anomaly. These rules, termed escalation rules, may also include the order in which personnel should be contacted as well as the preferred mode of communication for each contact. A customer having a device can utilize a i-emote 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 eveiit manager monitors incoming device alarms at a location remote from the devices. Devices monitored can include, for example, unintelTuptible power supplies (UPS's), cooling devices, environmental probes, and pOWer distribution devices. Devices can include power management software or a management device to monitor performance of the devices. Devices containing the OWCF management software can he distributed throughout the country, and even globally. Reports on the status of devices can he generated and infirmation provided to users in various ways such as over the Internet. Other embodiments are within the scope of the invention.

Referring to FIG. I, 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 monitonng system application layer interface (API) 24 and a web portal 26. Each device 18 can have its own MD 22. The S remote monitoring center 16 includes a database 30, a server 32 and an event manager/viewer 34. The server 32 and the remote devices 1 8 are configured with communication interfaces and coupled for tini-directional colilmunication with the network 14. For example, the API 24 is embedded iii the MD 22 to allow communication between the devices 18 and the network 14. In an alternate embodiment, remote devices 18 may communicate bi-directionally with network 14 independently of MD 22. The API 24 can he 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. In one embodiment, MD 22 may include a support call hutton that when actuated may establish an interactive communication session, such as a phone call or chat session, with staff located at remote monitoring center 16. Customer identification information, e.g. telephone number, may he included when establishing the session and the medium of communication may be network 14. In other embodiments, the support call button may he located on devices 1 8 or elsewhere, and the interactive communication session may use a medium other than network 14, such a standard telephone line. The server 32 can he, 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 (ESDN), a wireless network, a POTS based 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 1 8 may he used. For example, the monitoring center 16 may include a web server and a mail server separately. The monitored devices 1 8 can he any of several types of devices including any device that may be capable of communicating with a computing device such as general purpose computing system 400 discussed with regard to FIG. 24 below, e.g., uninterruptible power supplies, battery management systems or other electronic devices or groups of electronic devices, etc. The monitored devices 1 8 may he disposed remotely from each other such as in different zip codes, cities, counties, states, or countries.

The devices I 8 conlrnunicate 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. In one embodiment, MD 22 may receive commands for one or more devices 18 from RMS website 27 through network 14 as discussed below.

MD 22 may then communicate these commands to devices 18 for further processing. In an alternate embodiment, devices I 8 may receive commands directly from RMS website 27 through network 14. Devices 1 8 may expose to the customer an interface to configure which commands may or may not be executed from RMS website 27 through network Is 14. The API 24 is embedded in the MD 22 aiid 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 infi)rmation 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 1 8 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 one embodiment, devices 1 8 may communicate status information, or events, which include an escalation instruction. These events may result in special highlighting of the status information in event manager as discussed with regard to FIG. 18 below. 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 infwmation can include a time of the event. The MD 22 is configured to determine and report resolution of an event. The MD 22 is -10-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 s likelihood of simultaneous high-reporting traffic. For example, the information is provided using an 1-ITTP POST command, via email, via web services or via other techniques. The information is reported asynchronously from the API 24. Techniques can he 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 I 8 are operational and that the equipment between the API 24 and the server 32 is operational aiid 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, is 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 I 8, the network 14, andlor 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 swmise 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/agreements, define event escalation rules related to the operation of a device 1 8, 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 fbr storage at the monitoring center 1 6. 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 lormat. 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 arc possible. For s example, the customer registration information can he transmitted via a web service operated by the remote monitoring center 16. The customer can log on and enter registration information on a Remote Monitoring System (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. In one embodiment, access permissions/user roles, which are classifications of users that may enable access to specific sets of system functionality, at the web portal 26 include Network Operations Center (NOC) super administrators, NOC administrators, NOC user, company administrators (e.g., for editing customer data aiid creating company users), and company user, which can he designated as read-only. In another embodiment, access penrussions/user roles may include NOC super administrator, NOC Administrator, Administrator, and Read Only. Other access permissions can he 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 wcbsite operated by the remote monitoring center 16. Alternatively, the website 27 can he operated by a party other than the remote monitoring service 16 provider. The customer logs on and enters registration inlormation 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 rower 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 -12-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 I 8. The server 32 is configured to determine timing of events, as events arc time stamped (or by cross-s 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 OflC or a number of locations, and identify the device 1 8 affiliated with an event. The server 32 Jo POCCSSCS the in k)rrnalion, 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 1 8 and the event manager 34, and substantially all data are sent through the API 24. The server 32 receives customer data via I-ITTP 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 he provided, for example, at two permission levels: NOC personnel and Remote Monitoring System customers. The web portal 26 includes a built-inbulletin 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. In one embodiment, remote service website 27 may he implemented using a general-purpose computer as discussed below with reference to FIG. 24.

In another embodiment, RMS website 27 may expose system interface 42 to share device and other information with external system 44. The monitored device -13-information that may he shared in this manner includes device model, serial number, firmware version and geographic location. Other shared information may include escalated support events that require firmware upgrades or hardware replacement. In one embodiment, the external system which receives this information may he, for example, Siehel Customer Relationship Management (CRM) applications available from Oracle Corporation of Redwood Shores. CA. When SO coupled, inkrmation regarding newly installed devices, changes in previously installed device, and escalated support events may automatically flow from the devices in the field into the Siehel CRM application, thus ensuring the CRM application has current data. Although VIOUS embodiments of the present invention may be implemented in the Siebel CRM application, it shoukl be appreciated that various aspects of the present invention may he implemented with other CRM or other types of external systems, and the invention is not limited to any specific external system.

In another embodiment, the external system which receives the device intormation may he the well-known Google Earth application commercially available from Google, Inc. of Mountain View, CA. When SO coupled, information regarding the geographic location of newly installed devices and escalated support events involving those devices may automatically flow from the devices into the Google Earth application. Monitoring center staff may then use the Google Earth application to obtain a geographic representation of their monitored device installed base, including the operating condition of' the devices. This geographic representation may enable rnonitonng center staff to diagnose issues, such as power outages, that affect multiple devices and facilities. FIG. 23 illustrates one embodiment in which a geographic representation of a monitored device may be colored according to the operational condition of the device. For example, device 2300 may he colored green when the device is operating normally. Device 2302 may be colored yellow when it is operating in a warning state. Device 2304 may he colored red when it is operating in a critical state.

In yet another embodiment, RMS website 27 may include promotions module 40 which compares customer device information to device roadmaps and sales promotions to determine attractive upgrade plans for the customer. These upgrade plans may then be communicated to the customer when the customer accesses web portal 26. -14-

In a further embodiment, RMS website 27 may expose an interface that enables monitoring center staff or other authenticated users, to take corrective aCtion by issuing device commands to devices I 8. These commands may include, for example.

modification of thresholds, turning devices on and off and modification of firmware versions, among other command types that perform other corrective actions.

With continued reference to FIG. I, and referring to FIGS. 2A-2B, a user having at least one device I 8 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. In one embodiment, company information page 42 may prompt a user 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 ZOflC 54. Other fields can he included Ofl the company information page 42 (e.g., lields suited for other countries).

The contact information page 44, shown in FIG. 2B. may be displayed to a user, Is and may prompt 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 may be saved in the remote monitoring system database 30 or any other location. In one embodiment, data saved in the remote monitoring system database 30 may be 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 startup of the device 1 8.

In one implementation, customer information is XML formatted and is sent in an FITTP post and/or in an email message. Device registration may he completed automatically by associating the device 1 8 with a customer using knowledge of which device 18 (including unique idcntiiicrs, e.g., serial numbers) the customer is using or has purchased. As is known, XML is a self-describing computer language. XML allows the creation and format of custom document tags, as opposed to HTML which has uixed tags, e.g. <HEAD> and <BODY>. The exemplary customer XML template used to generate the customer registration information sent to the event manager may be structured similarly to the following example: <?xrnl version=' I 0 encodi iig'tJTF-8"'?> <--D]'D generated by XMLSpy v4. 4 IT (hILp://www.xnilspy.corn)--> -15- <!ELEMENT APCRMCnstLink (Cornpany+> <!ATTIAST APCRMCiistLink xmlns:xsi COATA #REQUIRED xsi:nuNanicspaceSchcmal oca1ion Cl)ATA #REQt]IREI) <!ELEMFNT Address I EMPTY> <!EIEMENT Address2 EMPTY> <IEIkMEN'l Company (CompanyName. ConipanyPhone. LocationList. DeviceContactList)> <!EI EMENT Compan yName EMPTY> 1 0 <!ELEMFNT CompanvPhone EMPTY> <tFIJ-MFN'l' Contact ( FirstNanie. LastName, EmailAddress, Password?, Title. Phonelst)> <!ATTIJST Contact Status (Active I Inactive) #REQEJIREI) Role (Admin I User) #REQUlRF) Owner (False I True) #REQUIRED <!El.EMENT ContactList (Contact+)> <!ElEMENT CountrvCode (#PCDATA)> <!ELEMENT Devtce (DeviceDescripliun)> <!ATTIJST Device Model CDA'I'A #REQUIRED Identifier CDATA #REQU!RED Parentldeiitifler CDATA IMP1JED <!EI.EMENT DeviceContact EMPTY> <!ATTIJST t)eiceCiitct hmailAddress CDA'IA #REQUIRFI) Identifier CDATA #RFQUIRED Priority (I I 2 I 3 I 4 I 5) #REQUIREII) <!El.EMENT J)eviceContactList (I)cviceConlact-i-)> <!ELEMEN'F Devicel) escnption EMPTY> <IELEMENT Devicel,jst (Device)> <!ELEMENT EmailAddi'ess EMPTY> <!ELEMENT FirsiNainc EMPTY> <!ELEMENT LastNaine EMPTY> <!ELEMEN1' Location (LocationName, Addressl, Address2'!, Municipality. Region, PostalCode, CoLintryCode. l'irnezone, ContactList. DeviceList)> <!ELEMENT LocationList (Location-i-)> <!ELEMENl' LocationName EMPlY> <!ELEMENT Municipality EMPTY> <!ELEMENT Password EMPTY> <!ELEMENT Phone EMPTY> <!Al'l'LISl' Phone lype (cell I I home I office I phone. #RLQUIRED <!ELEMENT PhoneList (Phone+)> <!ELEMEN'l' PostalCode EMPTY> <!LLLMLNl' Region EMPTY> <!ELEMENT Titnezonc EMPTY> <!ELEMENT Title EMPTY> Various embodiments of a computer-based interface enabling entry and maintenance of company profile data are illustrated in FIGS.7-14. In one embodiment, a Pro!'ile Wizard may he exposed thi'ough web portal 26 as shown in FIG. I and may he displayed in a window of a general-purpose computer as discussed below with reference -16-to FiG. 24. As discussed herein, the "Profile Wizard" is a utility within a software application that pcnnits the user to manage company contact and inonitorcd device i nforrnation.

The Profile Wizard may he developed using well-known liiternet technologies such as Java, Java Script, AJAX, HTML and XML. Although various aspects of the invention may he developed using browser-based computing tools, it should he appreciated that any programming language, framework, or environment may he used, and the invention is not limited to any particular implementation.

The Profile Wizard may guide the user through the process of creating a company profile and may include screens 700-714 which prompt the user to enter company profile information. Some user interface elements with similar functionality may he depicted with a similar appearance on multiple Profile Wizard screens. These common elements may include navigation elements 728, 820 and 700-722 and screen information section 726. Navigation elements 700-714 may allow the user to navigate, respectively, to welcome screen 700, company screen 800, facilities screen 900, contacts screen 1000, users screen 1100, devices screen 1200, preferences screen 1300 and validation screen 1400. Navigation elements 7 16-722 may lead, respectively, to system administration functionality, company home page 600, and help documentation. When actuated, user interface element 722 may log the user off of the system. Screen information section 726 may present the user with helpful information regarding the Profile Wizard screen currently displayed. Navigation element 728 may allow the user to move to the next Profile Wizard screen. As is common in the art, the user interface may highlight any information that is required by the system and the system may restrict the choices presented to the user ftr entry of certain types of information.

Specifically with regard to FIG. 7, welcome section 724 may greet the user with information regarding the system and the purpose of the Profile Wizard.

FIG. 8 illustrates a Profile Wizard screen that may he directed toward gathering information regarding a company that owns the monitored device and an individual at the company who is responsible thr maintain the device profile, i.e. a company contact.

Company screen 800 may include company section 802 and additional common navigation element 820. Navigation element 820 may allow the user to move to a previous Profile Wizard screen. Company section 802 may include several user interface -17-elements, including phone number list 804, phone number priority assignors 806 and 808, contact subsection 810, phone number entry subsection 81 2 and phone number entry user interface elements 814, 816 and 818.

Contact subsection 8 10 may display or, when used in conjunction with phone number entry subsection 8 12 below, enable additions or changes to company contact identification information. This information may mci tide the company contact's name, title and company.

Phone number entry subsection 8 I 2 may enable the user 10 record and associate new phone nuiithers with a company contact. After entering a phone number and the type of phone line identified by the phone number, e.g. cell, home, pager, etc., the user may record the phone number, and the associated company contact, by actuating user interface element 814. Similarly, after selecting a recorded and associated phone number in phone number list 804, the user may erase the selected phone number by actuating user interface element 816. Finally, the user may abort recordation or erasure by actuating user interface element 818.

As discussed above, phone number list 804 may present recorded phone numbers associated with a company contact. Phone number list 804 may show each recorded phone number, the order in which each phone number should be called (priority ranking), and the phone line type. By selecting a particular phone number from the list and actuating user interface element 806, the user may increase the priority ranking of the selected phone number relative to the other recorded and associated phone numbers.

Similarly, by actuating user interface clement 808, the user may decrease the priority ranking of the selected phone nuniher.

FIG. 9 depicts a Profile Wizard screen for gathering information regarding facilities that a company operates. Facilities screen 90() may include facility section 902.

Facility section 902 may include facility entry subsection 904, facility list 912 and user interface elements 906-910.

Facility entry subsection 904 may permit the user to add or modify facilities associated with a company profile. This information may include facility name, address, country, city, state or province, postal code and lime zone. Once any required information has been entered, the user may record the facility information and associate it with the company profile by actuating user interface element 906. Similarly, after -18-selecting a recorded and associated facility in facility list 912, the user may erase the selected facility information by actuating user interface element 908. Lastly. the user may abort recordation or erasure by actuating user interface element 910.

Facility list 1)12 may display a list of recorded facilities that are associated with s the company profile.

FIG. 10 shows a Profile Wizard screen for gathering information regarding contact personnel associated with the company profile. Contacts screen 1000 may include contact section 1002. Contact section 1002 may include contact entry subsection 1004, phone number entry subsection 101 2, phone number list 1020. contact list 1026 to and user interface elements 1006-1008, 1014-1018 and 1022-1024.

Contact entry subsection 1004 may permit the user to add or modify contacts associated with the company profile. This information may include contact name, title, email address, facility, any comment or notes, whether the contact is active and whether contact is responsible for maintaining company profile regarding a monitored device.

Once any required information has been entered, the user may record the contact information and associate it with the company profile by actuating user interface element 1006. Similarly, after selecting a recorded and associated contact in contact list 1026, the user may erase the selected contact information by actuating user interface element 1008. Lastly, the user may abort recordation or erasure by actuating user interface element 1010.

Phone number entry subsection 1012 may enable the user to record and associate new phone numbers with a contact. After entering a phone number and the phone line type, the user may record the phone number and associate it with the contact currently selected in contact list 1026 by actuating user interface element 1014. Similarly, after selecting a recorded and associated phone number in phone number list 1020, the user may erase the selected phone number by actuating user interface element 1016. Finally, the user may abort recordation or erasure by actuating user intethice element 1018.

As discussed above, phone number list 1020 may present recorded phone numbers associated with a contact. Phone number list 1020 may show each recorded phone number, the priority ranking, and the phone line type. By selecting a particular phone number from the list amid actuating user interface element 1022, the user may increase the priority ranking of the selected phone number relative to the other recorded and associated phone numbers. Similarly, by actuating user interface element 1024. the user may decrease the priority ranking of the selected phone number.

Contact list 1026 may display a list of recorded contacts that are associated with the company profile.

FIG. I I illustrates a Profile Wizard screen for gathering information regarding individuals in the company that will be system users. Users screen 1100 may include user section 1102. User section 1102 may include user entry subsection 1104, user list 1112 and user interface elements 1106-1110.

User entry subsection 1 I 04 may allow the user to add or modify users associated will-i a company profile. This information may include contact name, user login, user password, a hint for remembering the password, the user's temperature measurement preference for reporting purposes, user role and whether the user is active. Once any required information has been entered, the user may record the user information and associate it with the company profile by actuating user interface element 1106.

is Similarly, after selecting a recorded and associated user in user list 1112, the user may erase the selected user information by actuating user interface element 1108. Lastly, the user may abort recordation or erasure by actuating user interface element 1110.

User list 111 2 may display a list of recorded users that are associated with the company profile.

FIG. 12 depicts a Profile Wizard screen for associating contacts with monitored devices. Devices screen 1200 may include device section I 202. Device section 1202 may include device contact entry subsection 1204, device list 1218, contact list 1220, device contact list 1222 and user interface elements 1206-1216.

Device list 1218 may list all monitored device associated with the company profile, and contact list 1220 may list all contacts associated with the company profile.

Device contract entry subsection 1204 may enable the user to associate a contact with a device, in one embodiment, this association may he a many-to-many relationship, meaning that a single device may he associated with multiple contacts and a single contact may he associated with multiple devices. To associate one or more contacts with one or more devices, the user may first add contacts from contact list 1220 to device coiitact list 1222. The user may add multiple contacts to device contact list 1 222 by repeatedly selecting contacts from contact list 1 220 and actuating user interface element -20 - 1206 until device contact list 1222 lists the desired contacts. The user may remove a contact from contact list 1 222 by selecting the contact in device contact list 1222 and actuating user interface element 1208.

Once device contact list includes the desired contacts, the user may increase the priority ranking of the selected contact relative to the other recorded and associated contacts by selecting the contact from device contact list 1 222 and actuating user interface element 1210. Similarly, by actuating user interface element 1212, the user may decrease the priority ranking of the selected contact.

Once the device contact list includes the desired contacts in the proper priority ranking, the user may assign the contact list to one or more devices selected in device list 1218 by actuating user interface element 1214. The user may assign the current contact list to all 1218 devices by actuating user interface element 1216.

FIG. 13 shows a Profile Wizard screen for adding users to a list of those that receive automatic system generated reports and configuring reporting preferences.

Preferences screen 1300 may include preference section 1302. Preference section 1302 may include prelrence entry subsection 1304, report recipient list 1310, contact list 1312 and user interface elements 1306-1308.

Preferences section 1302 may allow the user add a contact selected in contact list 13 12 to report recipient list I 3 10 by actuating user interface element 1306. Similarly, the user may remove a contact from report recipient list 13 10 by selecting the contact in report recipient list 1 3 10 and actuating user interface element I 308. Lastly, degree list 1314 and frequency list 1316 may allow the user to specify these reporting preferences for the contact currently selected in report recipient list 1310.

Contact list 13 12 may list all of the contacts associated with the company profile and report recipient list 1310 may list all of the contacts that have been designated to receive automatically generated system reports. Degree list 1314 may list all of the temperature measurement standards supported by the system and frequency list 13 16 may list all of the report frequencies support by the system. In OflC embodiment, the system can support degrees Fahrenheit and Celsius and reporting frequencies include 30 days and 90 days.

FIG. 14 illustrates a Profile Wizard screen for displaying the validity of the company profile. Validation screen 1400 may include validation section 1402.

Validation section 1402 may include device validation warning list 1406, contact validation warning list 1408 and user interlace elements 1404.

Validation section 1402 may allow the user to evaluate the validity of the company profile as currently configured by actuating user interlace element 1404.

Device validation warning list 1406 may include devices for which are associated with fewer than 3 contacts. Contact validation warning list 1408 may include contacts which are associated with fewer than 2 phone numbers.

RefelTing 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 0 synopsis 0! 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 ernails page 78, an audit trail page 80 and a cailbacks page (not shown), 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, ticketlD 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 7 1 are color coded and can he sorted by level of importance for visual inspection, i.e., such that the most severe events can he 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 7 I, 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 1 8. Each open ticket 104 is assigned to a service individual 108 residing at the monitoring center 1 6. Data related to the eveiit, such as the frequency of the occurrence, the urgency and the device data are presented on the event viewer 70.

-22 -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 I 10 and mode of contact I 12 are available to the service individual. The contact I JO can he contacted directly, or via passive means where indicated. The contact information is that collected from the website 27, where the customer has registered.

FIG. 1 8 shows another embodiment in which event manager may include special highlighting for events that require replacement parts, service dispatch, firmware upgrades or other issues that require temporary escalation. In the depicted embodiment, this special highlighting may include escalation column 1802 and the coloring of rows representing escalation events. In one embodiment, event manager may be displayed in a window of a general-purpose computer as discussed below with reference to FIG. 24.

According to one embodiment of the present invention, an external systeiri (e.g. a Siebel CRM system), may initiate an action in response to an event (e.g. an escalation event) provided by the event manager and/or device. According to one aspect of the invention, a monitoring service may provide information to a CRM application.

Conventionally, CRM systems are stand-alone applications or, at most, provide information to other applications. According to one embodiment, a monitoring system provides data to a CRM application, permitting the creation of a dynamic picture of customer's network from within the CRM application.

According to another embodiment of the present invention, events or alarms may be "tagged" that require replacement/repair of a monitored device. According to one embodiment, the system may determine automatically whether there should be some type of escalated action performed for a monitored device. Such an action may he taken, for example, by an inspection of escalation information associated with a particular device and/or event, triggering an upgrade of software or firmware, displaying an alert to an event viewer application, or other action. In one example, the device may be modified to report which event might require an escalation. Conventionally, an operator must make a judgment decision as to whether a particular device is repaired or replaced.

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's devices 18 over a week, a month, a quarter, or a year. The report 120 can be -23 -generated over another specified duration, such as more frequently than a quarter, or less frequently than a quarter.

The report I 20 includes a contact portion I 22 and all executive summary 1 24. 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.

Tile report 120 also includes a severe events synopsis 134. A recommendations section 136 can, for example, include event manager recommendations to improve the efficiency to 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 u.s parameters over tile 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 aiid humidity are summarized in the device activity tables 140, 142 and 144.

The report 1 20 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 I 5() includes the report 120 as a screen view. The report I 20 may he alTanged in a number of formats for presentation to the user. For example, the Contact data 122, executive summary 124, availability 126, actions required 128, eveiit 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 he added or removed based on the event activity for the specified time period.

The remote monitoring system 10 and reporting system can he used for a variety of applications. An exemplary use of the system 10 is to provide an integrated monitoring system ftr use at a customer site. The customer site 12 can include one or more devices in the monitoring scheme. The system 10 can he integrated into an environment where a user has a separate monitoring center staff, rather than utilizing a -24 centralized monitoring staff. These examples are not limiting, as otherapplications are within the SCOC of the invention.

FIG. 6 depicts example company home page user interface 600, which may allow the user to evaluate the recent history and current condition of monitored devices and access various system functions. In one embodiment, this interface may be displayed in a window of a general-purpose computer as discussed below with reference to FIG. 24.

Company home page 600 may he developed using well-known Internet technologies such as Java, Java Script, HTML and XML. in one embodiment, company home page 600 may he created using the well-known ZK AJAX technologies available to from the Potix Corporation. Although various aspects of the invention may be developed using browser-based computing tools, it should he appreciated that any programming language, framework, or environment may he used, and the invention is not limited to any particular implementation.

Company home page 600 may include navigation elements to other system pages 602-6 10, which present the user with various system functions as discussed below, and exit element 612 that allows the user to log off the system. Company home page 600 may also include device summary status section 6 14, company relationship status section 618, event and ticket history section 620 and white paper list 626, each of which is discussed in further detail below. Typically, the system will automatically display company home page 600 to the user after user log on, and the information displayed may he automatically updated at regular intervals. Various users may review company home page 600 including company users such as monitoring center staff and management.

Device status summary section 614 may present the user with the current condition of monitored devices aggregated into device groups. In the embodiment shown in FIG. 6, monitored devices may he grouped by device functional type, e.g. power distribution units (PDU's), environmental units, network cooling systems, urminterruptihle power supplies (UPS's) or other devices. It should be appreciated that if a particular company has no monitored devices that fall within one of these categories then that category may he omitted from device status summary section 614. When one or more devices within a group encounter an anomaly, that group may highlighted. In the FIG. 6 embodiment, this highlighting may take on the form of a red attention status icon. As illustrated in FIG. 6a, the user may then hover the mouse pointer over the status icon to gain additional information regai-ding the problem, such as the serial number, device name and device location of the device reporting the anomaly. Further drill-down functionality may allow the user to click on the serial number of the device to access the event log fi)r that device, as depicted in FIG. 6h.

Company relationship status section 61 8 may present the user with the current condition of the company profile and agreernentlconiracl status. As with device status summary section 614 above, hovering the mouse point over the status icon may enable the user to view more specific information regarding the source of any validation or agreement problems. In one embodiment, actuating the status icon for profile validation may cause the system to display validation screen 1400 depicted in FIG. 14 as discussed below. Actuating an anomalous status icon associated with agreement status may cause the system to display the user contracliagreemcnl at issue.

Event and ticket history section 620 may contain a graphical representation of monitored device anomalous events and any resulting tickets within the previous time specified in date horizon usei-interface element 624. In the embodiment shown in FIG. 6, the graphical representation may be a line graph that presents the daily volume of tickets and events as a function of time. Date horizon user interface element 624 specifies that 7 days of historical data should be represented. In one embodiment, date horizon user interface element 624 may default to 14, 30, 90 or a customer configurable number of days. As shown by legend 628, events and tickets may be displayed as separate data ranges. In one embodiment, events and tickets may be combined into a single data range in a bar graph representation.

Event and ticket history section 2004 may contain a graphical representation of monitored device anomalous events and any resulting tickets within the previous year.

In the embodiment shown in FIG. 20, the graphical representation may he a bar graph that presents the quarterly volume of tickets and events as a function of time. As shown by legend 2008, events and tickets may be displayed as separate data ranges. In one embodiment, events and tickets may he combined into a single data range in a line graph representation.

In another embodiment, white paper list 626 may provide navigation elements to white papers focused on APC equipment.

-26 -Navigation element 602 may invoke the Profile Wizard interface discussed above. Navigation clement 604 may allow the user to view all of the monitored devices associated with the company. Navigation element 606 may expose a link to system reports. Navigation elements 608 and 610 may cause the system to display a conlacts s user interface and user help, respectively.

FIGS. 19-22 illustrate an example interface that may enable users to view Key Perftrmance Indictor ( KPI) and related information. KPI's may include metrics such as ihe number of tickets that were not responded to within a target timeirame and the actual response time for those instances when the response time exceeded the target. More particularly, FIG 19 depicts KPI overview screen 1900 which may include KPI history section 1902, event and ticket history section 1904 and previous day section 1906.

KPI history section 1902 may display a graphical representation of system KPI's lr the previous 30 day period. In the embodiment shown in FIG. 19, the graphical representation may be a line graph that presents the number of times KPI's were not met 1.5 per day as a function of time. in one embodiment, the graphical representation may he a bar graph.

Event and ticket history section 1904 may contain a graphical representation of monitored device anomalous events and any resulting tickets within the previous 30 days. In the embodiment shown in FIG. 19, the graphical representation may he a line graph that presents the daily volume of tickets and events as a function of time. As shown by legend 1908, events and tickets may he displayed as separate data ranges. In one embodiment, events and tickets may be combined into a single data range in a bar graph representation.

Previous day section 1906 may display a snapshot of metrics based on the previous 24 hour period, information displayed in this section may include events and tickets as well as summaries of the devices that generated the most events and tickets in the previous 24 hours. Previous day section 1906 may also include user interface elements that enable the user to export the information presented Ofl KPI overview screen 1900 to a third party application, such as Microsoft Excel.

FIG 20 may show KPI statistics screen 2000 which is similar to KPI Overview screen I 900, hut generally utilizes more and older device data. KPI statistics screen -27 - 2000 may include KPI previous year section 2002, event and ticket history section 2004 and user and monitoring method SeCtion 2006.

KPI previous year section 2002 may display a graphical representation of system KPI's for the previous year. In thc embodiment shown in FIG. 20, the graphical representation may he a line graph that presents the number of times K P1's were not met per quarter as a function of time. In one embodiment, the graphical representation may he a bar graph.

In the embodiment showii in FIG. 20, the graphical representation may he a bar graph that presents the quarterly volume of tickets and events as a function of time. As shown by legend 2008, events and tickets may be displayed as separate data ranges. In OflC embodiment, events and tickets may be combined into a single data range in a line graph representation.

User and monitoring method section 2006 may display a snapshot of metrics based on the previous 30 days. Information displayed in this section may include metrics such as customer count, agreement/contract count, device count and agreement/contract renewal rate as well as the type and number of monitoring methods that are in use. User and monitoring method section 2006 may also include user interface elements that enable the user to export the information presented on KPI statistics screen 2000 to a third party application, such as Microsoft Excel.

FIGS. 21 and 22 show an exemplary KPI report generation interface which may allow the user to execute and view KPI reports. FIG 21 depicts a report generation screen 2 100 which may include report execution section 2104 and report results section 2 102. The user may execute a report by submitting the information required in report execution section 2104. This infrmation may include the type of report desired, the start and end date and time of the data to include in the report and which facilities to include in the report. Once any required information is submitted the system may display the resulting report in report results section 2102.

As illustrated in FIG. 21, the information displayed by the service level report may include operator identifier 2106, number of tickets 2 108, percentage of tickets opened within target response time 2110, average response time 2112, minimum response time 2114, and maximum response tune 2116. As shown in FiG. 22, the information displayed by the delayed acknowledgement report may include ticket identifier 2202, issue description 2204, operator identifier 2206 and the response time 2208.

FIGS. 15-17 show an example user interface enabling development, configuration and execution of business rules. According to one embodiment, business rules enable various vocational groups, e.g. support, sales and product development, in a device manufacturing and monitoring company, such as the APC Corporation, to perlorm management functions related to devices installed in the field. For instance, io such functions may include obtaining information about the installed device base, such as how the devices are perthrming in the field, determining which devices do not have the latest version of firmware and upgrading software on installed devices, among other data and/or functions. This information may he used to provide proactive support, understand device behavior in the field and identify potential upgrade opportunities.

is FIG. 17 illustrates business rule development screen 1700 which may include business rule definition section 1702, available business rule list 1708 and user interface elements 1704-1706.

Business rule definition section 1702 may give development personal the ability to create new business rules that can be later configured by end users, such as monitoring center staff. The information captured by business rule definition section 1702 may include rule name, description, parameter names, number of parameters, filter, SQL Query and parameter values. The user may create a new business rule by entering the required information in business rule definition section 1 702 and actuating user interface element 1704. Similarly, the user may abort the creation of a new business rule by actuating user interface element 1 706.

Available business rule list 1708 may list the business rules that have already been created. The user may modify a rule selected in list 1708 by changing the definition of the rule in section 1702 and actuating user ititerface element 1704.

FIG. 15 depicts business rule conhguration screen l50() which may include business rule parameters section 1502, configurable business rule list 15 10 and user interface elements 1504-1508.

-29 -Business rule configuration section 1502 may allow users having certain user roles to configui-c business rules to be used by other system users. In one embodiment, any user with a user i-ole of (NOC) super administrator may configure business rules.

The infoi-mation captured by business rule configuration Section 1502 may include the rule name, description, parameter values and whether or not the business rule is active and thus available to other system users. The user may execute a newly configured business rule by selecting the desired business rule from configurable business rule list 10, entering any infrmation required by the business rule in section 1502 and actuating user interface element I 504. The user may save a configured business rule for io later use by entering any information required by the business rule in section 1502 and actuating user interface element 1506. The user may exit business rule configuration screen 1500 without saving the currently configured business rule by actuating user interface element 1508.

Configurable business rule list 1510 may include all of the business rules made LS available for configuration by the system development staff.

FIG. 16 shows business rule results screen 1600 which may include business rule results section 1602, executable business rule list 1604 and user interface element 1606.

Executable business rule list 1604 may list all of active configured business rules and may allow the user to execute any of the listed business rules by selecting it. The results may then be displayed in business rule results section 1602. The user may export the results to a third party application, such as Microsoft Excel, by actuating user interface element 1 606.

In operation, referring to FIG. 5, with further reference to FIGS. 1-4, a process 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 usei-can make a one-time entry of customer profile information. The user chooses to he 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 he operated by the remote monitonng center 16 or by a third party. The user enters information, such as name, -30 -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 starle(1 up. At start-up, device information is sent automatically Ironi the monitored device I 8 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's location are associated with the user via the registration data entered at the web portal 26. The device data can be XML firrnatted and can he sent to the server 32 via HTTP post.

At stage 206, the API 24 sends heartbeats andlor separate or included indicia of power events, environmental events, or failure events for the device 18. For example, a power problemleventlanomaly or a return of power occurs at the device I 8 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 HITP 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 I 2. 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 he duplicated at the event manager 34 due to the hyperlink.

At stage 2 10, the staff member at the event manager 34 contacts the customer based on the device data retrieved. For example, if an event 7 1 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 2 12, 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 VIII postal service. Evaluation and analysis of the event activity is provided through the report 120.

The OCCSS 200 depicts a preferable sequence of events. Other stages can he s added, or the order of stages can he 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.

At least one aspect of the present invention relates to the user completing a company profile through the Profile Wizard. The high level procedural 110W of this method is shown in FIG. 27, with further reference to FIGS. 1 and 7-14, and may consist primarily of the Profile Wizard prompting the user to enter company information 2704, enter facilities information 2706, enter contacts information 2708, enter users information 2710, associate contacts with devices 271 2, enter preferences information 2714 and check the validity of the company profile 2716. Components of this process may he implemented using a general-purpose computer system as discussed with regard to FIG 24 below and accessed through web portal 26.

At stage 2702, OCCSS 2700 begins. At stage 2704. the Profile Wizard may prompt the user to enter the information required by company screen 800. In one embodiment, this information may include company name, company phone, company contact first name, company contact last name and company contact phone number.

After entering all of the required information, user may actuate common user interface element 728 to move the next Profile Wizard screen.

At stage 2706. the Profile Wizard may prompt the user to enter the information required by facilities screen 900. In one embodiment, this information may include facility name, address, country, city/municipality and time zone. After entering all of the required information, user may actuate common user interface element 728 to move the next Profile Wizard screen.

At stage 2708, the Profile Wizard may prompt the user to enter the information required by contacts screen 1000. In one embodiment, this information may include first name, last name, eiiiail address, t.iciIity and phone number. After entering all of the required information, user may actuate user common interface element 728 to move the next Profile Wizard screen.

At stage 27 10, the Profile Wizard may prompt the user to enter the information required by users screen 1100. In one embodiment, this information may include name, login, password, confirm password and user role. After entering all of the required information, user may actuate common user interface element 728 tO ITR)VC the next Profile Wizard screen.

At stage 27 12, the Profile Wizard may prompt the user to associate contacts with devices using devices screen 1200. In one embodiment, the user may associate contacts with devices in any manner described above with regard to devices screen 1200. After associating all devices with contacts, user may actuate common user interface element 728 to move the next Profile Wizard screen.

At stage 2714, the Profile Wizard may prompt the user to enter the information required for a contact to receive report 120 using preferences screen 1300. After entering all of the desired information, user may actuate common user interface element 728 to move the next Profile Wizard screen.

At stage 2716, the Profile Wizard may prompt the user to check the validity of the company profile using validation screen 1400. In one embodiment, the user may check the validity of the company profile by actuating user interface element 1404. The user may use any errors or warning reported by validation screen 1400 to make corrections to the company profile. Once no validation errors or warnings exist, stage 2718 is reached, and process 2700 ends.

The process 2700 depicts a preferable sequence of events. Other stages can he added, or the order of stages can he altered in the process 2700 without departing from the spirit of the present invention.

Other embodiments are within the scope and spirit of the appended claims. For example, due to the nature of software, functions described above can he implemented using software, hardware (e.g., an embedded web card), firmware, hardwiring, or combinations of any of these. Features implementing functions may also he physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations. Additionally, power status information can he provided only when an event occurs, rather than at regular intervals.

-33 -Other embodiments of the MD 22 are possible. For example, the MD 22 may he located in or attached to (e.g., inserted into a receptacle of) the devices 18. Such devices would he configured to communicate with the network 14 and provide management in formation.

The above defined processes 200 and 2700, according to one embodiment of the invention, may be implemented on one or more general-purpose coiiiputcr systems. For example, various aspects of the invention may he implemented as specialized software executing in a general-purpose computer system 400 such as that shown in FIG. 24.

Computer systeul 400 may include one or more output devices 401, one or more input devices 402, a processor 403 connected to one or more memory devices 404 through an interconnection mechanism 405 and one or more storage devices 406 connected to interconnection mechanism 405. Output devices 401 typically render information for external presentation and examples include a monitor and a printer, input devices 402 typically accept information from external sources and examples include a keyboard and a mouse. Processor 403 typically performs a series of instructions resulting in data manipulation. Processor 403 is typically a commercially available processor such as an Intel Pentium, Motorola PowerPC, SGI MIPS, Sun UltraS PARC, or Hewlett-Packard PA-RISC processor, but may be any type of processor. Memory devices 404, such as a disk drive, memory, or other device for storing data is typically used for storing programs and data during operation of the computer system 400. Devices in computer system 400 may he coupled by at least one interconnection mechanism 405, which may include, for example, one or more communication elements (e.g., busses) that communicate data within system 400.

The storage device 406, shown in greater detail in FIG. 25, typically includes a computer readable and writeable nonvolatile recording medium 9 I I in which signals are stored that define a program to be executed by the processor or information stored on or in the medium 911 to be processed by the program. The medium may, for example, he a disk or flash memory. Typically, in operation, the processor causes data to he read from the nonvolatile recording medium 911 into another memory 912 that allows for faster access to the information by the processor than does the medium 911. This memory 91 2 is typically a volatile, random access memory such as a dynamic random access memory (DRAM), static memory (SRAM) or flash memory. It may be located in storage device -34- 406, as shown, or in memory device 404. The processor 403 generally manipulates the data within the memory 404, 912 and then copies the data to the medium 911 after processing is completed. A variety of mechanisms are known for managing data movement between the medium 911 and the memory 404, 912. and the invention is not s limited thereto. The invention is not limited to a particular memory device 404 or storage device 406.

Computer system 400 may be implemented using specially programmed, special PUrPOSC hardware, or may he a general-purpose computer system that is programmable using a high-level coulputer programming language. For example, computer system 400 may include cellular phones and personal digital assistants. Computer system 400 usually executes an operating system which may he, for example, the Windows 95, Windows 98, Windows NT, Windows 2000, Windows ME, Windows XP, Windows Vista or other operating systems available from the Microsoft Corporation, MAC OS System X available from Apple Computer, the Solaris Operating System available from Sun Microsystems, or UNIX operating systems available from various sources (e.g., Linux). Many other operating systems may he used, and the invention is not Iiiriited to any particular implementation. For example, an embodiment of the present invention may instruct network devices to change power consumption a general-purpose computer system with a Sun UItraSPARC processor running the Solaris operating system.

Although computer system 400 is shown by way of example as one type of computer system upon which various aspects of the invention may he practiced, it should be appreciated that the invention is not limited to being implemented on the computer system as shown in FIG. 24. Various aspects of the invention may he practiced on one or more computers having a different architecture or components than that shown in FIG. 24. To illustrate, one embodiment of the present invention may retrieve detailed device information using several general-purpose computer systems running MAC OS System X with Motorola PowerPC processors and several specialized computer systems running proprietary hardware and operating systems.

As depicted in FIG. 26, one or more portions of the system may be distributed to one or more computers (e.g., systems 109-Ill) coupled to communications network 108.

These computer systems 109-111 may also he general-purpose computer systems. For example, various aspects of the invention may he distributed among one or more -35 -computer systems conhgured to provide a service (e.g.. servers) to one or more client computers, or to perform an overall task as part of a distributed system. More particularly, vanous aspects of the invention may he performed on a client-server system that includes Components distributed among one or more server systems that pert orm various functions according to various embodiments of the invention. These components may be executable, intermediate (e.g., IL) or interpreted (e.g., Java) code which communicate over a communication network (e.g., the Internet) using a communication protocol (e.g., TCP/IP). To illustrate, OflC embodiment may display validation screen 1400 though a browser interpreting I-ITML forms and may retrieve JO detailed device inft)rmation using a data translation service running on a separate server.

Various embodiments of the present invention may he programmed using an object-oriented programming language, such as SmailTalk, Java, C++, Ada, or C# (C-Sharp). Other object-oriented programming languages may also he used. Alternatively, functional, scripting, and/or logical programming languages may be used. Various Is aspects of the invention may heimplemented in a non-programmed environment (e.g., documents created in HTML, XML or other format that, when viewed in a window of a browser program, render aspects of a graphical-user interface (GUI) or perform other functions). Various aspects of the invention may be implemented as programmed or non-programmed elements, or any combination thereof. For example, preferences screeii 1300 may be implemented using a Microsoft Word document while the application designed to send device data heartbeats may he written in C++.

It should be appreciated that a general-purpose computer system in accord with the present invention may perform functions outside the scope of the invention. For instance, aspects of the system may he implemented using an existing commercial product, such as, fir example, Database Management Systems such as SQL Server available from Microsoll of Seattle WA., Oracle Database from Oracle of Redwood Shores. CA, and MySQL from MySQL AB of UPPSALA, Sweden and WehSphere middleware from IBM of Armonk, NY. If SQL Server is installed Ofl a general-purpose computer system to implement an embodiment of the present invention, the same general-purpose computer system may be able to support databases for sundry applications.

554456.1 -36 -Based on the foregoing disclosure, it should he apparent to one of ordinary skill in the art that the invention is not limited to a particular computer system platform, pI)cessor, operating system, network, or communication protocol. Also, it should he apparent that the present invention is not limited to a specific architecture or programming language.

Having thus described several aspects of at least one embodiment ol this invention, it is to he appreciated various alterations, modilications, and improvements will readily OCCUF to those skilled in the art. Such alterations, modifications, and improvements are intended to he part of this disclosure, and are intended to he within the spirit and SCOC of the invention. Accordingly, the foregoing description and drawings are by way of example only.

What is claimed is:

Claims

-37 -CLAiMS I. A computer-implemented method for providing a remote

monitoring service to a Customer, the method Comprising: providing an interface to a remote monitoring system, the interface being available over a network, the remote monitoring system including a computer i-eadahle medium and being located at a first geographic location; receiving, from (he customer via the interface, registration iii formation including a company profile and an identifier of at least one monitored device, the at least one monitored device being located at a second geographic location remote from the first geographic location; storing, on the computer readable medium, an association of the at least OflC monitored device with the company profile; validating the registration infonnation; and providing, via the interface, a result of validating the registration information to the customer.
2. The method according to claim I, further comprising: receiving, at the remote monitoring system, status information associated with the at least one monitored device, the status information describing an operational condition of the at least one monitored device; storing the status information on the computer readable medium; and providing, by the remote monitoring system, the status information to a first user at a third geographic location remote from the first geographic location and the second geographic location.
3. The method according to claim 2, further comprising: determining, by the at least one monitored device, that an event associated with the at least one monitored device should be escalated; generating, by the at least one monitored device, escalation information; -38 -including, by the at least one monitored device, the escalation information in the status in formation; and providing, by the at least one monitored device, the status information.
4. The method according to claim 3, further comprising escalating the status inlormation.
5. The method according to claim 4, wherein escalating the status inlormation comprises escalating the status information according to an escalation rule. l0
6. The method according to claim 2, wherein providing, by the remote monitoring system, (lie status information to the first user comprises: aggregating the status information by at least one device group, the at least one device group including a plurality of devices having a common functional device 1.5 type. the aggregated status information including information associated with a device in an anomalous state; and presenting, to the first user in a display of a computer system, the aggregated status information.
7. The method according to claim 6, wherein providing, by the remote monitoring system, the status information to the first user further comprises presenting, to the first user in the display, an identifier of the device in an anomalous state.

2
8. The method according to claim 2, wherein providing, by the remote monitoring system, the status information to a lirst user comprises: presenting, to the first user in a display of a computer system, historical monitored device status in formation; presenting, to the first user in the display of the computer system, current monitored device status information for a plurality of monitored devices, the monitored device status information aggregated into device group representations, at -39 -least one device group representation including infi)rmation about a device operating in an anomalous stale; detecting a mouse pointer hovering over the representation including inlormation about a device Operating in an anomalous state; and presenting, to the user in the display, an identifier of the device operating in an anomalous state.
9. The method according to claim 2 further comprising: receiving, from a second user, a query that when executed groups the at least JO one monitored device according to a value of at least OflC common characteristic, the query having at least one parameter defining the value; receiving, from a third user, an input identifying the query and the at least OflC parameter: and executing the query using the parameter.
10. The method according to claim 2, further comprising providing, by the remote monitoring system, the status information to a customer relationship management (CRM) system.
1 I. The method according to claim 2, wherein receiving, at the remote monitoring system, status information comprises receiving status information indicating the need to replace the at least one monitored device.
12. The method according to claim I 1, further comprising providing, to a system supporting hardware replacement orders, the status information indicating the need to replace the at least one monitored device.
13. The method according to claim 2, wherein receiving, at the remote monitoring system, status information comprises receiving status information indicating a geographical location of a monitored device, and the method further comprises presenting the status to a second user in the context of a geographical representation, the status being located in the representation at the geographical location of the monitored device.
14. The method according to claim 3, wherein providing, by the at least one monitored device, the status information comprises providing, by the at least one monitored device, status information indicating a geographical location of the monitored device.
15. The method according to claim 2, further comprising: determining, based on the status information, at least one replacement device for the at least one monitored device; and presenting an indicator of the at least one replacement device to a second user.
16. The method according to claim 15, wherein determining, based on the status information, the at least one replacement device comprises determining at least one replacement device based on a product roadinap.
17. The method according to claim 15, wherein determining, based on the status information, the at least one replacement device comprises determining at least one replacement device based on a sales promotion.
18. The method according to claim 2, further comprising: receiving configuration information defining a plurality of device commands available for remote execution by the remote monitoring system, each of the plurality of device commands being capable of changing a characteristic of the at least one monitored device; and providing an interface to remotely execute each of the plurality of device commands according to the configuration information.
19. The method according to claim 1 8, further comprising transmitting the configuration information from a CRM system. -4]-
20. The method according to claim 1, wherein providing the interface to the remote monitoring system comprises: presenting, to the customer in a display, an input that allows the user to enter company information; presenting, to the customer in the display, an input that allows the user to enter facility inlormation; presenting, to the customer in the display, an input that allows the user to enter contact information; presenting, to the customer in the display, an input that allows the user to enter user information; presenting, to the customer in the display, an input that allows the user to associate a contact with a monitored device; and presenting, to the customer in the display, an input that allows the user to enter reporting preference information; wherein receiving, from the customer via the interface, registration information comprises: accepting, in the display, the company inRrmation provided by the customer; storing the company information; 2() accepting, in the display, the facility information provided by the customer; storing the facility information; accepting, in the display, the contact information provided by the customer; storing the contact information; accepting, in the display, the user information provided by the customer; storing the user information; accepting, in the display, the association provided by the customer; storing the association; accepting, in the display, the reporting prefircnce information provided by the customer; stoling the reporting preference information; and -42 -wherein validating the registration infirrnation comprises validating the company profile against a set of validation rules.
21. The method according to claim I. further comprising providing the Company profile to a CRM system.
22. A remote monitoring system Compnsing: a computer readable mcdi urn; an input configured to receive, from a customer, registration information io including a company profile and an identifier of at least one monitored device; a processor coupled to the computer readable medium and the interface and configured to store an association of the at least one monitored device with the company profile and to validate the company profile; and an output coupled to the processor and configured to provide a result of the validation of the company profile.
23. A computer readable medium having stored thereon sequences of instruction including instructions that will cause a processor to provide an interface to a remote monitoring system, the interface being available over a network, the remote monitoring system including a computer readable medium and being located at a first geographic location; receive, from the customer via the interface, registration information including a company profile and an identifier of at least one ITH) IlitOred device, the at least one monitored device being located at a second geographic location remote from the first geographic location; store, on the computer readable medium, an association of the at least one monitored device with the company profile; validate the registration information; and provide, via the interface, a result of validating the registration information to the customer. -43 -
24. A support session apparatus for use with computer equipment comprising: an element operable by a user to establish an interactive communication session between a support entity and the user; and an interface configured to transmit to the support entity operational information associated with the computer equipment.
25. The apparatus according to claim 24, wherein the support session apparatus is included with a monitored device.
26. The apparatus according to claim 24, wherein the support session apparatus is included with an enclosure housing at least one monitored device.
27. The apparatus according to claim 24, wherein the support session apparatus is included with a management device.