Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1999-06-30
2002-04-30
Iqbal, Nadeem (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C710S017000
Reexamination Certificate
active
06381712
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to error messaging systems and in particular, to an error messaging standard for electronic devices and components.
Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office file or records, but otherwise reserves all copyright rights whatsoever. Sun, Sun Microsystems, the Sun logo, Solaris, Java, JavaOS, JavaStation, HotJava Views, JINI and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
BACKGROUND OF THE INVENTION
When a device fails, (breaks, stops working, works incorrectly) it is often difficult to figure out the reason for failure. Often this is because the device is not able to give any status information because it has failed. Another reason is that the device is not configured to be able to provide useful status information even when it is working correctly. Finally, even when a device does give status information, it may be in a proprietary format that requires specialized knowledge, documentation, or tools to understand.
Regardless of whether a device is an embedded device or not, it usually has a scheme for communicating its failures and status to the outside world. A failure identification can be as simple as a device not turning on, or a blinking or color coded LED indicating a problem. It can also be as sophisticated as sending an e-mail message of a device failure to a remote computer. Larger and more complex electronic components have more sophisticated mechanisms for identifying and communicating failures. This is important where there are many possible failure modes in a complex system, and the source of a problem can be more quickly identified by useful failure communication information.
When designing a device with electronic components, striving for reliability and serviceability are important competitive factors. But design cost is proportional to the level of reliability and serviceability achieved on the device. Obtaining reliability depends on the quality of electronic components selected, and the manufacturing process of the device. But even when high reliability is achieved, the possibility of device failure still exists. Therefore designing in advance for serviceability becomes equally as important as reliability. Obtaining high level of serviceability first depends on the accuracy, granularity, and ease of use in identifying what failed in a device.
A universal and reusable method for designing serviceability features capable of identifying and delivering device failures does not exist today. Therefore designing for serviceability today is device dependent, and can become costly depending on device's architecture. SNMP, (Simple network management protocol), and MIB, (Management information base), are two standards that provide some consistency in a method of managing errors, but both schemes are predominantly used for network specific devices, e.g. network interface cards, Ethernet hubs, and routers. The portability of these schemes to other environments is limited.
One problem with providing a universal error messaging system is the number of different “platforms” on which the system is required to operate. A platform is the combination of the hardware (e.g. processor) and software (e.g. operating system) that comprises a particular device. For example, a computer system with a processor manufactured by Intel and running the operating system known as Windows is considered to be a platform. An Intel computer running the DOS operating system is considered to be another platform. Other platforms include Sparc processor based computers from Sun Microsystems, Motorola processor based computers, and computers using the Unix operating system. In the prior art, software is often written specifically for a particular platform and will not run on other platforms. Such software is platform dependent.
SUMMARY OF THE INVENTION
A standard platform independent messaging environment for use with devices is provided. The environment provides programming and operational building blocks that can be used to interface with existing data providing capabilities to identify, respond to, and report errors and failover conditions. Customizable decision logic is used to provide more sophisticated response and reporting capabilities, even though the basic device hardware and operation is not redesigned.
REFERENCES:
patent: 4356546 (1982-10-01), Whiteside et al.
patent: 4866712 (1989-09-01), Chao
patent: 4914657 (1990-04-01), Walter et al.
patent: 4945471 (1990-07-01), Neches
patent: 5291585 (1994-03-01), Sato et al.
patent: 5335320 (1994-08-01), Iwata et al.
patent: 5345550 (1994-09-01), Bloomfield
patent: 5347627 (1994-09-01), Hoffmann et al.
patent: 5384911 (1995-01-01), Bloomfield
patent: 5412772 (1995-05-01), Monson
patent: 5414806 (1995-05-01), Richards
patent: 5423034 (1995-06-01), Cohen-Levy et al.
patent: 5430836 (1995-07-01), Wolf et al.
patent: 5436637 (1995-07-01), Gayraud et al.
patent: 5448695 (1995-09-01), Douglas et al.
patent: 5461399 (1995-10-01), Cragun
patent: 5461710 (1995-10-01), Bloomfiled et al.
patent: 5473745 (1995-12-01), Berry et al.
patent: 5487147 (1996-01-01), Brisson et al.
patent: 5491784 (1996-02-01), Douglas et al.
patent: 5493638 (1996-02-01), Hooper et al.
patent: 5499364 (1996-03-01), Klein et al.
patent: 5509116 (1996-04-01), Hiraga et al.
patent: 5526517 (1996-06-01), Jones et al.
patent: 5544288 (1996-08-01), Morgan et al.
patent: 5546519 (1996-08-01), Berry
patent: 5548702 (1996-08-01), Li et al.
patent: 5550968 (1996-08-01), Miller et al.
patent: 5559942 (1996-09-01), Gough et al.
patent: 5564003 (1996-10-01), Bell et al.
patent: 5566330 (1996-10-01), Sheffield
patent: 5570462 (1996-10-01), McFarland
patent: 5572643 (1996-11-01), Judson
patent: 5694603 (1997-12-01), Reiffin
patent: 5694604 (1997-12-01), Reiffin
patent: 5712856 (1998-01-01), Finney et al.
patent: 6138253 (2000-10-01), Buzsaki
Ronald L. Johnston, “The Dynamic Incremental Compiler of APL/3000” Proceedings of the API '79 Conference, published as APL Quote Quad, 9(4), pp. 82-87.
Leo J. Guibas et al., “Compilation and Delayed Evaluation in APL,” Fifth Annual Synposium on Principles in Programming Languages, pp. 1-8, 1978.
Gleen Krasner “The Smalltalk-80 Virtual Machine” BYTE Publications Inc., Aug. 1991, pp. 300-320.
Coudert Brothers LLP
Harriman II, Esq. J. D.
Iqbal Nadeem
Sun Microsystems Inc.
LandOfFree
Method and apparatus for providing an error messaging system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for providing an error messaging system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for providing an error messaging system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2916503