The number of network-connected devices has grown dramatically over the last decade. Such growth is expected to continue far into the future, causing enormous problems of integration for consumers, companies, and governments. One significant problem is the inclusion of many legacy devices that were never intended to be connected to a network. For instance, gaining information regarding bulb life on a projector can reduce down time by allowing a manger to replace the bulb before it burns out. But light bulbs and electrical systems that operate light bulbs are generally not designed to be networked.
Another problem is the ever-growing number of network enabled devices that have inadequate monitoring and control capabilities. These problems are pervasive, involving all manner of equipment from FAX machines, printers, copiers and other office equipment, to specialized devices found in manufacturing plants, to home appliances, and even hand-held electronics such as cameras and audio/video players. This problem is particularly acute for IT administrators, who often find themselves spending a great deal of money and time bridging heterogeneous management systems. Most of these devices do not contain state information and are even more difficult to manage. A more homogeneous management environment can save time and money, but numerous vendors have many valid business and technical reasons for avoiding homogeneous management systems.
Device management functionality comes in many different forms depending on the administrator's needs and the capabilities of the target device. Common management functions include monitoring the device's critical information, taking an inventory of the devices sub-systems, logging interesting events that take place, sending alerts to an administrator, recovering the device if the power fails, ensuring the data is secure, asset tracking, or reporting information to an administrator. Administrators also employ more advanced management functions including scripting or programming, aggregating device data from multiple devices, diagnostics, taking action based on the device data content, trending device data, reporting information in a final format including a spreadsheet or graph, or translating from one management format to another. A major area of management functionality includes securing the device through providing confidentiality of data, data integrity, administrator authentication, device authentication, risk mitigation, countermeasures, or protection against hostile environments and threats.
Management functionality described above can be represented concisely by the acronym MILARRS. MILARRS has the following meaning:
Monitoring the state of the device for an administrator
Inventory the devices sub-systems, components, or assets
Logging data or events generated by the device
Alerting an administrator of device state or taking action based on defined rules
Recovering the device if it fails or shuts down
Reporting device information or diagnostics to an administrator
Securing the device and its assets from threats and risks
IT departments are well aware of the management issues involved with network devices. They regularly manage large numbers of servers, printers, or file systems. Many IT shops employ Simple Network Management Protocol (SNMP) to manage devices through the use of application software including HP's OpenView. Over the last several years, Intel and other organizations (DELL and HP) have promoted new a standard called Intelligent Platform Management Interface (IPMI) for managing devices including servers, chassis, or racks. Other companies suggest using a common Data Center Markup Language (DCML) being developed under the OASIS Consortium or Web services for Management eXtensions (WMX) proposed by Microsoft for hardware management. These and other standards embody various management concepts or functions. Unfortunately, all these methods have limitations. In addition, these “standards” have created a chaotic environment where all the “standards” conflict, require different applications, or generally don't communicate with each other efficiently. Another consequence of all these standards is that device developers have difficulty knowing which method will be employed by their end customer but would like to offer their customers flexibility in selecting their preferred management environment.
Protocols including SNMP offer methods of transporting device information, but do not offer a method of actually performing management actions. In addition, data transport mechanisms including WMX or DCML define how a remote administrator makes requests of a device, but again don't offer real autonomous management ability. Data transport mechanisms all require that the target device understand the methodologies a priori in order for them to work. These data transport mechanisms can be used as part of an overall management strategy but do not offer a complete management solution by themselves. For instance, IPMI uses SNMP for sending alerts, but SNMP does not provide actual management capabilities.
Unfortunately, manageable devices that use IPMI or other management methods must have the method built into the devices a priori, or at least the devices must have an upgrade path to provide management capabilities. This requires the device developer to spend time and money to incorporate the necessary management capabilities or plan for them ahead of time. An upgrade path for the device may take the form of a PCI slot for a server management card or the form of a software management application which requires an extensible operating system. Adding management solutions including IPMI at design time to a device is an expensive undertaking because of the learning curve involved, the added expense to the BOM to support an IPMI subsystem, royalties on firmware, and the time to integrate, and then test. In addition, most devices have static operating systems that can not be upgraded in a modular fashion. Clearly, IPMI does not provide a quick method for incorporating management functionality into a general purpose device.
IPMI offers a solid management solution for specific kinds of devices including server, chassis, or blades, but has limited capabilities. IPMI offers the ability to monitor, inventory, log, alert, and recover a device, but requires that the device be IPMI-aware at some level. IPMI sub-systems are often integrated into the physical design of a server's mother board making it difficult to add advanced management functionality to the device. In addition, an IPMI upgrade card can not be adapted to a general purpose device. When IPMI cards are available, they generally use a parallel interface including a PCI bus. Unfortunately, most existing low-end products do not have such an expensive interface. IPMI does offer the administrator the ability to set minimal criteria for monitoring, inventory, logging, recovery, alerting, and some security, but does not allow the administrator to adjust the management module to understand a generic device's natural communication method, to generate device state based on the device information context, or to make autonomous decisions based on the administrator's desired rules.
Other approaches have been taken in the past to provide minimal generic management solutions for legacy devices including console servers or device servers. These types of products are designed to connect to legacy systems through serial interfaces then tunnel data directly from the device to a remote administrator. An administrator must connect to the device through a console server or a device server using an application on a workstation in order see the device information streaming from the device's serial port. In both these cases, while they have provided remote connectivity to devices, they do not provide a method for actually managing the devices or a method for determining device state.
Finally, network devices coupled with evolving standards, and the high cost of adding management capabilities, have created several problems that need to be addressed as the number of networked devices increases:                Administrators need a method to access device state in order to reduce cost of maintenance;        Administrators need a module to attach to devices to bring them into a homogenous management environment to reduce costs associated with many different management environments;        Administrators need a method that allows them to set rules for managing a device for more efficient operation; and        Developers need an apparatus to quickly and cost effectively add management functionality to a product design to improve time to market.Having a method and apparatus for converting device data into management data for a homogenous management environment can reduce the costs to IT professionals because they will no longer be required to learn additional IT management methods or purchase expensive software packages to bridge management systems. In addition, developers will be able to incorporate management functionality into their designs quickly thereby improving time to market.        
Heterogeneous network devices, coupled with evolving standards and the high cost to add management capabilities, have created several problems that need to be addressed as the number of networked devices increases. There is a consequent need for apparatus and methods by which legacy devices can be brought into a homogeneous management system based on desired standards, and there is also a need for a low cost solution by which management capabilities can be added to existing designs and/or to new product designs.
USPTO Backgrounds
USPTO Backgrounds