(12) United States Patent
`Mann et al.
`
`USOO6922722B1
`(10) Patent No.:
`US 6,922,722 B1
`(45) Date of Patent:
`Jul. 26, 2005
`
`(54) METHOD AND APPARATUS FOR DYNAMIC
`NETWORK CONFIGURATION OF AN
`ALERT-BASED CLIENT
`
`(75) Inventors: Eric K. Mann, Hillsboro, OR (US);
`Anil Vasudevan, Hillsboro, OR (US)
`(73) Assignee: Intel Corporation, Santa Clara, CA
`(US)
`-
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(*) Notice:
`
`6,161,133 A 12/2000 Kikinis ....................... 709/220
`6,182,180 B1
`1/2001 Liu et al.
`6,198.722 B1
`3/2001 Bunch
`6.219,708 B1
`4/2001 Martenson
`6.243,746 B1
`6/2001 Sondour et al.
`6,249,885 B1
`6/2001 Johnson et al.
`6.253,243 B1
`6/2001 Spencer
`6,275,864 B1
`8/2001 Mancusi et al.
`6,282,568 B1
`8/2001 Sondur et al.
`6,286,038 B1 * 9/2001 Reichmeyer et al. ....... 709/220
`6,308.206 B1 10/2001 Singh
`6,349,333 B1
`2/2002 Panikatt et al.
`6,353,854 B1 * 3/2002 Cromer et al. .............. 709/220
`6,363,421 B2
`3/2002 Barker et al.
`6,363,422 B1
`3/2002 Hunter et al. ............... 709/218
`6.490.620 B1
`12/2002 Dit
`t al.
`2 : - - 2
`f
`he ea
`* cited by examiner
`
`(21) Appl. No.: 09/409,627
`(22) Filed:
`Sep. 30, 1999
`(51) Int. Cl." .............................................. G06F 15/177
`Primary Examiner Ario Etienne
`ASSistant Examiner Kevin Parton
`(52) U.S. Cl. ....................... 709/220; 709/221; 709/222;
`(74) Attorney, Agent, or Firm-Blakely, Sokoloff, Taylor &
`709/223; 709/224; 709/225; 709/217; 709/218;
`Zafman LLP
`709/219; 717/172; 717/177
`(58) Field of Search ................................. 709/221-225,
`ABSTRACT
`(57)
`709/217-219, 220; 717/171-173, 176-178;
`701/220, 223, 224 A method and apparatus for performing network-based
`control functions on an alert-enabled managed client. An
`alert proxy translates generic, management-based command
`data received from a management application/agent into
`Specific client-based hardware control data. The alert proxy
`transmits a data packet containing the hardware control data
`over a network to an alert-enabled managed client. Alert
`hardware within the alert-enabled managed client parses the
`hardware control data into control bits and utilizes the
`control bits to Set or clear registers within the alert-enabled
`managed client So as to effectuate the Specified control
`operations. The control operations may be performed on the
`alert-enabled managed client independent of the operational
`Status of the alert-enabled managed client's operating Sys
`tem.
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,168,566. A 12/1992 Kuki et al.
`5,175,855 A 12/1992 Putnam et al.
`5,181.201 A 1/1993 Schauss et al.
`5,309,563 A 5/1994 Farrand et al.
`5,600,782 A 2/1997 Thomson
`5,689,708 A 11/1997 Regnier et al.
`5,838,907 A 11/1998 Hansen ....................... 709/220
`5,860,010 A 1/1999 Attal
`5,968,116 A 10/1999 Day, II et al.
`5,968,176. A 10/1999 Nesset et al.
`5,978,912 A 11/1999 Rakavy et al.
`5.987,514 A 11/1999 Rangarajan
`5.987,554. A 11/1999 Liu et al.
`6,065,053 A 5/2000 Nouri et al.
`
`15 Claims, 14 Drawing Sheets
`
`
`
`
`
`
`
`ALERTPROXY
`125
`
`
`
`NEWORKSTACK
`122
`
`MGMTSERVER 120
`
`CENT 11
`
`NETWORK
`100
`
`Intel Corporation v. ACQIS LLC
`Intel Corp.'s Exhibit 1049
`Ex. 1049, Page 1
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 1 of 14
`
`US 6,922,722 B1
`
`
`
`
`
`
`
`?V? INBITO
`
`
`
`?Ž? HENNES | WOW
`
`Ex. 1049, Page 2
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 2 of 14
`
`US 6,922,722 B1
`
`
`
`HETTO?HINOO
`}}}JONA13N
`
`?I?
`
`Ex. 1049, Page 3
`
`

`

`US. Patent
`
`Jul. 26, 2005
`
`Sheet 3 0f 14
`
`US 6,922,722 B1
`
`meEmz
`
`amm._._OE.ZOo
`
`Ema25%
`
`$959,$59
`
`Hmm4<
`
`a$2392:
`
`v3.10
`
`mwo._x23
`
`mOmme2E
`
`
`
`mmafigmw>oo
`
`
`
`flownmam—2m
`
`mewzww
`
`mszmw
`
`9mm
`
`mOmzmw
`
`momzmm
`
`W3
`
`<m.OE
`
`meEmz
`
`Ex. 1049, Page 4
`
`Ex. 1049, Page 4
`
`
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 4 of 14
`
`US 6,922,722 B1
`
`
`
`*JOSNES}JOSNES(JOSNES}}OSNES
`???55????
`
`Ex. 1049, Page 5
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 5 of 14
`
`US 6,922,722 B1
`
`STAR
`
`
`
`
`
`
`
`
`
`
`
`RECEIVE EVENT MESSAGE
`DATA
`402
`
`PARSEEVENT MESSAGE
`DAA
`404
`
`ASSIGN VALUESTO EVEN
`VARABLES BASED UPON
`EVENT MESSAGE DAA
`406
`
`REFERENCE EVENT
`DESCRIPTION FLE
`
`FIG. 4A
`
`Ex. 1049, Page 6
`
`

`

`U.S. Patent
`
`m
`
`6m
`
`mn.7,202,,
`
`
`
`
`
`%ram225<$5.82as:m:m,95E25:2%QO$528.o.55%v:
`
`
`
`
`
`Sascha::022:833:352mat.m0<mmm2«av
`
`mv.0.”—
`
`
`
`:028&5:MatEmaas. 255.2888:a8m:$8.223me25:8.65szEma«2m255m353%?a8m:$382$38<25:88%mea?m2522m$55:
`
`
`
`
`
`
`
`c2552;22m.285225:85%Emav2
`
`Ex. 1049, Page 7
`
`Ex. 1049, Page 7
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 7 of 14
`
`US 6,922,722 B1
`
`F.G. 5A
`
`505->|LANGUAGE MAP
`eSm esp
`
`510->{SYSTEM D)
`511 - XXX = CompanyxYZ
`512->YYY = CompanyABC
`520-EVENT TYPE
`O = SMPLE
`521 - 1 = SIMPLE
`522->8 = SOFTWARE
`523 -> 90 = COMPOUND
`
`530->EVENT MAP
`531-> CompanyxYZ = 1,2; 2,2; 84,9; 90.7
`540->EVENT LIST
`O = 13000;14014
`541 -> 1 = 13001;14015
`2 = 13002;14O16
`3 = 13003;14017
`550 -> COMPANYXYZ 90)
`551 - 7 - 8
`552->9 = 10
`(RESOURCE MAP
`CompanyxYZ = XYZ
`CompanyABC = ABC
`
`565-ICOMPANYXYZ
`01.06.2712
`
`Ex. 1049, Page 8
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 8 of 14
`
`US 6,922,722 B1
`
`FIG. 5B
`
`570
`
`572
`
`574
`
`576
`
`
`
`GE EVENT EXTENSION:
`
`
`
`
`
`
`
`N PLATFORMAND EVENT
`TYPE # SECTION, REFERENCE
`EVENT EXTENSION i
`
`OBAN 2ND EVENT TYPE
`CORREATED TO EVENT
`EXTENSON #
`
`584
`
`586
`
`588
`
`GE SYSTEM O
`
`ASSOCATE SYSTEM D
`WHPAFORM NAME
`
`GET FRST EVENTYPE
`
`578
`
`
`
`S EVENT TYPE
`"COMPOUND"?
`
`N PLATFORM EVENT MAP
`REFERENCE ST EVENT TYPE
`
`IN PLATFORM EVENT MAP
`OBAN 2NO EVENT TYPE
`CORRELATED TO ST EVENT
`TYPE
`
`
`
`
`
`NEVENT LIST, REFERENCE2ND
`EVENTYPE is
`
`OBAN OCALIZED EVENT
`SRNG AND EVEN INFO STRING
`CORRELATED WITH 2ND
`EVENT TYPE
`
`592
`
`
`
`
`
`
`
`
`
`594
`
`GE "SOFTWARE, EVENT
`MESSAGE STRING
`
`
`
`N PLAFORMAND EVENT TYPE
`SECTION, OBTAINS/W INFO
`STRING CORRELATED TO
`SW MESSAGE STRING
`
`
`
`596
`
`598
`
`580
`
`
`
`
`
`582
`
`
`
`
`
`
`
`
`
`
`
`Ex. 1049, Page 9
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 9 of 14
`
`US 6,922,722 B1
`
`FIG. 6A
`
`610 - FUNCTION_LIST
`O = 20000:21015
`1 = 20001:21016
`610 -> 2 = 20002:21017
`620->(FUNCTION_MAP)
`622--> COMPANYXYZ = 1,1,2,2,3,3,445,596
`630-SUBFUNCTIONS_2)
`632 -
`0 = 16001; 16002
`634-> 1 = 16003;16004
`(COMPANYXYZ)
`DeviceType = 0
`StatusPolarity = 0xD9
`StatusPowerupMask = 0x1B
`StatusPOWerdown Mask FOX19
`CompanyxYZ
`652 - 101
`3.0040
`110 W:300402
`114 C:3004-03
`
`Company ABC
`662 - 101 300402;300800300801
`110 300405
`
`672 -> 300401
`300402
`300403
`30O800
`300801
`
`A failure occurred during testing of the system board
`A memory parity failure occurred
`Adapter ROM failure
`Memory may be defective
`Replace memory
`
`Ex. 1049, Page 10
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 10 of 14
`
`US 6,922,722 B1
`
`SART
`
`
`
`RECEIVE POST CODE EVENT
`DATA
`710
`
`PARSE EVENT DATA AND
`OBAN SYSTEM D
`T5
`
`CORRELATE SYSTEM D WITH
`OEM DESCRIPTION
`720
`
`LOCATE OEM SECON
`725
`
`EXRAC MAPPING OF POST
`CODES TO STRING D'S
`730
`
`NDEX INTO STRENGABLE
`
`FIG. 7
`
`Ex. 1049, Page 11
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 11 of 14
`
`US 6,922,722 B1
`
`886986#86Z86
`
`
`
`
`
`
`
`
`
`
`
`? 006
`
`?
`
`Ex. 1049, Page 12
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 12 of 14
`
`US 6,922,722 B1
`
`START
`
`POWER-UPISTART BOOT
`
`SETIENABLE WATCHDOG
`
`
`
`
`
`
`
`DECREMENT WATCH DOG
`
`1008
`
`CONTINUE
`BOOT
`
`
`
`WATCHOOG
`SUSPENDED?
`
`1002
`
`
`
`1004
`
`1005
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`WATCHDOG
`EXPRED?
`
`TRGGER
`WATCHDOG
`EVENT
`
`1016
`
`
`
`BOOTS
`SUCCESSFU
`
`BOO
`REACHED
`SPECIFEO
`PON?
`
`
`
`FIG. 10
`
`Ex. 1049, Page 13
`
`

`

`U.S. Patent
`
`
`
`Jul. 26, 2005
`
`Sheet 13 of 14
`
`US 6,922,722 B1
`
`|NEITO
`
`Ex. 1049, Page 14
`
`

`

`U.S. Patent
`
`Jul. 26, 2005
`
`Sheet 14 of 14
`
`US 6,922,722 B1
`
`START
`
`
`
`FIRST DATA PACKET
`LOADED FROM EEPROM
`1202
`
`ALERT HIW XMITS DATA
`PACKET TO CONFIG SERVER
`1204
`
`CONFIG SERVER RESPONDS
`WITH CONFIG PARAMEERS
`1206
`
`CONFIG PARAMETERS
`RECEIVED BY ALERT HIW
`1208
`
`ALERT HIW UPDATES 2ND
`DAA PACKET IN EEPROM
`1210
`
`2ND DATA PACKET LOADED
`AND TRANSMITTED TO ALERT
`PROXY
`1212
`
`STOP
`
`FIG. 12
`
`Ex. 1049, Page 15
`
`

`

`1
`METHOD AND APPARATUS FOR DYNAMIC
`NETWORK CONFIGURATION OF AN
`ALERT-BASED CLIENT
`
`This nonprovisional patent application is related to con
`temporaneously filed nonprovisional patent application Ser.
`No. 09/410,483 entitled “PLATFORM INDEPENDENT
`ALERT DETECTION AND MANAGEMENT, and con
`temporaneously filed nonprovisional patent application Ser.
`No. 09/411,407 entitled “METHOD AND APPARATUS
`FOR PERFORMING NETWORK-BASED CONTROL
`FUNCTIONS ON AN ALERT-ENABLED MANAGED
`CLIENT.
`
`BACKGROUND OF THE INVENTION
`
`15
`
`1. Field of the Invention
`The present invention relates generally to the field of
`networking. Specifically, the present invention relates to a
`method and apparatus for dynamic unattended network
`configuration of an alert-based client.
`2. Background of the Invention
`AS the size and complexity of computer networks con
`tinues to grow, So too does the time required to maintain
`Such networks. It is not uncommon for local area networks
`that once required only a Single network administrator to
`now require multiple administrators or even a dedicated
`network Support department.
`AS networks continue to grow in size, they likewise grow
`in complexity.
`Nowadays, it is rare for networks to contain devices that
`were all produced by the same manufacturer. More likely,
`whether because of price, availability, or otherwise, a given
`network will contain a mixture of computers and appliances,
`produced by various manufacturers. Furthermore, the wide
`Selection of central processing units, audio and Video
`components, Storage devices, and other Support hardware
`available for both computer Systems and peripherals has
`enabled custom configuration of Systems tailored to meet
`particular needs.
`Unfortunately, however, from a network administration or
`management perspective, the more diverse a network is, the
`more difficult it is to manage due to the varying hardware
`and Software configurations utilized by the varying devices
`or clients. Traditionally, when a networked device ceased to
`function on a network, the network administrator would
`personally visit the device to troubleshoot the cause of the
`malfunction. In a large network containing many clients,
`however, the process of locating a client, not to mention the
`process of troubleShooting, can be time consuming and
`therefore costly.
`Remote management tools have been developed as part of
`an effort to decrease the total cost of ownership of networked
`Systems by increasing their manageability. Typically, remote
`management tools provide System administrators with a
`means for detecting client malfunctions located remotely
`from the administrator. Unfortunately though, the notifica
`tion that the administrator receives may be limited merely to
`an indication of whether an event has occurred, rather than
`a preferred notification indicating what type of event has
`occurred. Likewise due to the varying degree of customi
`Zation within network devices, the event notification may
`not be tailored to the Specific device that generated the event.
`Thus, an improved approach to event notification is desired.
`Furthermore, although remote detection of a malfunction
`may be possible using a management tool, a personal visit
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,922,722 B1
`
`2
`by an administrator remains necessary in order to attempt to
`remedy the problem. Although notification of a malfunction
`or System alert is important, it is also desirable to have the
`capability to remotely act on the information to correct a
`failing condition. Since a large portion of malfunctions
`cause client operating Systems to "hang”, “freeze' or “lock
`up”, it is further desirable for a mechanism that provides the
`ability to perform remote operations on a client after boot,
`to also provide the ability to perform Such operations when
`the client is without a functioning operating System, or in
`pre-boot State.
`SUMMARY OF THE INVENTION
`A System is provided to dynamically obtain at least one
`alert detection and management parameter from a first
`server. The system is provided to further dynamically obtain
`configuration data from a remote alert proxy using the at
`least one obtained alert detection and management param
`eter. The System is provided to further configure the appa
`ratus using the dynamically obtained configuration data.
`BRIEF DESCRIPTION OF THE DRAWINGS
`The invention is illustrated by way of example, and not by
`way of limitation in the figures of the accompanying draw
`ings in which like reference numerals refer to Similar ele
`mentS.
`FIG. 1 is a block diagram illustrating one embodiment of
`a network alerting System.
`FIG. 2 is a block diagram illustrating one embodiment of
`an alert-enabled managed client.
`FIG. 3A is a block diagram illustrating one embodiment
`of an input pin connection Scheme on a first System.
`FIG. 3B is a block diagram illustrating one embodiment
`of an input pin connection Scheme on a Second System.
`FIG. 4A is a flow diagram illustrating the operation of one
`embodiment of an alert proxy.
`FIG. 4B is a table illustrating one embodiment of vari
`ables used by the alert proxy.
`FIG. 5A illustrates a sample event description file con
`taining event data for different platforms.
`FIG. 5B is a flow diagram illustrating the operation of one
`embodiment of an alert proxy with respect to an event
`description file.
`FIG. 6A illustrates a sample event description file con
`taining control operation information and BIOS configura
`tion data.
`FIG. 6B illustrates one embodiment of a sample BIOS
`String table.
`FIG. 7 is a flow diagram illustrating the operation of one
`embodiment of an alert proxy with respect to BIOS.
`FIG. 8 illustrates one embodiment of a RMCP manage
`ment transmit packet format.
`FIG. 9 illustrates one embodiment of a RMCP manage
`ment receive packet format.
`FIG. 10 is a flow diagram illustrating one embodiment of
`a managed client boot process with respect to a watchdog
`timer.
`FIG. 11 is a block diagram illustrating one embodiment of
`an automatically configurable network alerting System.
`FIG. 12 is a flow diagram illustrating one embodiment of
`an automatic configuration process of a networked client.
`DETAILED DESCRIPTION
`In the following description, for purposes of explanation,
`numerous Specific details are Set forth in order to provide a
`
`Ex. 1049, Page 16
`
`

`

`US 6,922,722 B1
`
`15
`
`25
`
`35
`
`40
`
`3
`thorough understanding of the present invention. It will be
`apparent, however to one skilled in the art that the present
`invention can be practiced without these specific details. In
`other instances, well-known Structures and devices are
`shown in block diagram form to avoid obscuring the present
`invention.
`Some portions of the detailed descriptions which follow
`are presented in terms of algorithms and Symbolic repre
`Sentations of operations on data bits within a computer
`memory. These algorithmic descriptions and representations
`are the means used by those skilled in the data processing
`arts to most effectively convey the substance of their work
`to otherS Skilled in the art. An algorithm is here, and
`generally, conceived to be a Self-consistent Sequence of steps
`leading to a desired result. The Steps are those requiring
`physical manipulations of physical quantities. Usually,
`though not necessarily, these quantities take the form of
`electrical or magnetic Signals capable of being Stored,
`transferred, combined, compared, and otherwise manipu
`lated. It has proven convenient at times, principally for the
`reasons of common usage, to refer to these signals as bits,
`values, elements, Symbols, characters, terms, numbers, or
`the like.
`It should be borne in mind, however, that all of these and
`Similar terms are to be associated with the appropriate
`physical quantities and are merely convenient labels applied
`to these quantities. Unless Specifically Stated otherwise as
`apparent from the following discussions, it is appreciated
`that throughout the present invention, discussions utilizing
`terms Such as “processing or “computing or "calculating
`or “determining” or “displaying or the like, refer to the
`action and processes of a computer System, or Similar
`electronic computing device, that manipulates and trans
`forms data represented as physical (electronic) quantities
`within the computer System's registers and memories into
`other data Similarly represented as physical quantities within
`the computer System registers or memories or other Such
`information Storage, transmission or display devices.
`The present invention also relates to an apparatus for
`performing the operations herein. This apparatus may be
`Specially constructed for the required purposes, or it may
`comprise a general purpose computer Selectively activated
`or reconfigured by a computer program Stored in the com
`puter. Such a computer program may be Stored in a computer
`readable Storage medium, Such as, but is not limited to, any
`type of disk including floppy disks, optical disks,
`CD-ROMS, magneto-optical disks, read-only memories
`(ROMs), random access memories (RAMs), EPROMs,
`EEPROMs, magnetic or optical cards, or any type of media
`Suitable for Storing electronic instructions, and each coupled
`to a computer System bus. The algorithms and displayS
`presented herein are not inherently related to any particular
`computer or other apparatus. Various general purpose
`machines may be used with programs in accordance with the
`teachings herein, or it may prove convenient to construct
`more Specialized apparatus to perform the required method
`Steps. The required Structure for a variety of these machines
`will appear from the description below. In addition, although
`the present invention may be described with reference to a
`particular programming language, it will be appreciated that
`a variety of programming languages may be used to imple
`ment the teachings of the invention as described herein.
`Although all or Some of the operations may be performed
`by Software executing on one or more processing devices
`(e.g., CPUs), on a computer System or specialized apparatus,
`Some or all of these operations may be performed by digital
`logic and/or circuitry, an integrated circuit (e.g., ASIC) or
`other Semiconductor Substrates.
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`Brief Overview
`Network alerting, as described herein, refers to a network
`devices ability to perform problem identification,
`notification, and resolution. In one embodiment of the
`present invention, a Software-based intermediary referred to
`herein as an alert proxy is to used to transform binary,
`device-specific event or alert data into user-friendly plain
`text explanations of the event. In one embodiment, a man
`agement device containing the alert proxy is able to return
`a contextually correct description of the event to an admin
`istrator or other interested party based upon the character
`istics of the Specific device initiating the event. In one
`embodiment, event data is generated by alert Software
`executing on an alert-enabled managed client, whereas in
`another embodiment, event data is generated by alert hard
`ware embodied within an alert-enabled managed client.
`In another embodiment of the present invention, the alert
`proxy translates generic, management-based command data
`received from a management application/agent into specific
`client-based hardware control data. The alert proxy trans
`mits a data packet containing the hardware control data over
`a network to an alert-enabled managed client. Alert hard
`ware within the alert-enabled managed client parses the
`hardware control data into control bits and utilizes the
`control bits to Set or clear registers within the alert-enabled
`managed client So as to effectuate the Specified control
`operations.
`In another embodiment of the present invention, a
`network-alert client transmits a data packet over a network
`requesting Specific alert detection and management param
`eters from a centralized configuration Server. The configu
`ration server responds Supplying the network-alert client
`with the requested data. Using the received alert detection
`and management parameters, the network-alert client for
`mulates a Second data packet to be transmitted to the alert
`proxy upon the occurrence of an event. In Such a manner
`automatic, unattended, Simultaneous configuration of mul
`tiple network-alert clients is made possible.
`FIG. 1 is a block diagram illustrating one embodiment of
`a network alerting System. Referring to FIG. 1, management
`server 120 and alert-enabled managed client 110 are shown
`connected to a network 100. Network 100 may represent a
`local area network (LAN), a wide area network (WAN), the
`Internet, or any other interconnected data path acroSS which
`multiple devices may communicate. In one embodiment,
`network 100 is an Ethernet based network utilizing the
`transmission control protocol/internet protocol (TCP/IP). In
`another embodiment, network 100 utilizes the user datagram
`protocol/internet protocol (UDP/IP). It will be apparent to
`one of ordinary skill in the art, however, that various
`network and communication protocols could equivalently be
`implemented without departing from the Spirit and Scope of
`the present invention. Similarly, although management
`server 120 and alert-enabled managed client 110 are shown
`physically connected to network 100, any Such connection
`means known in the art may be implemented including
`wireleSS technology Such as infrared, radio frequency and
`microwave transfer means.
`In the present disclosure, the term "packet' is generically
`used to represent data transmitted or received over a network
`and should not be interpreted as being Specific to any
`particular topology or communication protocol. Likewise, in
`the present disclosure, the terms “event” and “alert” are used
`interchangeably to represent a particular type of data packet
`or message. Additionally, the term “event' is also used to
`represent a particular occurrence or change of State in a
`device.
`
`Ex. 1049, Page 17
`
`

`

`US 6,922,722 B1
`
`15
`
`25
`
`35
`
`40
`
`S
`In one embodiment of the present invention, alert-enabled
`managed client 110 represents a device equipped and con
`figured to detect and transmit events to management Server
`120. In one embodiment, alert-enabled managed client 110
`is equipped and configured to detect and transmit events
`while in a pre-boot or operating System unavailable mode. In
`one embodiment, as depicted in FIG. 1, alert-enabled man
`aged client 110 represents a general purpose digital
`computer, whereas in another embodiment, alert-enabled
`managed client 110 may represent a peripheral device Such
`as a printer or mass Storage unit. In yet another embodiment,
`alert-enabled managed client 110 may represent an intelli
`gent networked appliance Such as a microwave oven,
`refrigerator, or a System Such as an environmental heating
`ventilation air conditioning (HVAC) System, a burglar alarm
`System, a Sprinkler System and the like.
`Alert-enabled managed client 110 is shown having net
`work controller 112 and alert hardware 114 of the present
`invention. Network controller 112 represents a device
`capable of establishing a communication link between alert
`enabled managed client 110 and network 100. In one
`embodiment, network controller 112 is an 82559 multifunc
`tion fast Ethernet LAN controller available from Intel Cor
`poration of Santa Clara, Calif.
`Alert hardware 114 represents logic equipped to detect
`alerts on alert-enabled managed client 110 and to formulate
`one or more network data packets representing those alerts.
`In one embodiment, as shown in FIG. 1, alert hardware
`114 and network controller 112 represent two distinct com
`ponents connected through System management bus
`(SMBus) 115, whereas in another embodiment, alert hard
`ware 114 and network controller 112 may be integrated into
`a single ASIC. Similarly, both alert hardware 114 and
`network controller 112 may each be located on a mother
`board or on one or more Separate add-in expansion cards
`such as a network interface card (NIC).
`Management server 120 is shown connected to network
`100 and comprises network stack 122, alert proxy 125 of the
`present invention, and management application 127. In one
`embodiment of the present invention, management Server
`120 is a general purpose digital computer configured to
`execute alert proxy 125 and management application 127.
`Management application 127 represents any one or more of
`the various System management applications known in the
`art to be able to manage multiple clients over a shared
`network. In one embodiment, management application 127
`represents any one or more applications from the
`LANDESKCR suite of management products, available from
`Intel Corporation.
`Alert proxy 125 represents an intermediary configured to
`perform numerous tasks including translating platform inde
`pendent alert packets generated by alert-enabled managed
`client 110 into platform Specific alert explanations.
`Additionally, alert proxy 125 translates control commands
`from management application 127 into hardware-specific
`data control packets to be transmitted to alert-enabled man
`aged client 110. Alert proxy 125 can also perform tasks
`including, but not limited to discovering clients, identifying
`different hardware configurations and message formats,
`Sending and receiving network packets for event configura
`tion and control purposes, and providing a consistent exter
`nal interface to management applications. In one
`embodiment, alert proxy 125 includes a plain-text “...ini”
`description data file (not pictured), whereas in other
`embodiments, alert proxy 125 includes description files
`based upon the management information format (MIF)
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`and/or management information block (MIB) format. A
`more detailed description of alert proxy 125 may be found
`below.
`Network stack 122 which is also shown as part of man
`agement server 120, represents an optional TCP/IP-based
`network Stack and Supporting hardware device drivers nec
`essary for management Server 120 to communicate over
`network 100. It will be apparent to one of ordinary skill in
`the art, however, that various network communication pro
`tocols and hardware device drivers could equivalently be
`implemented.
`FIG. 2 is a block diagram illustrating one embodiment of
`an alert-enabled managed client. Client 210 represents an
`alert enabled managed client and includes processor 255
`coupled to chipset 250. In one embodiment, processor 255
`is a processor from the Pentium(R) family of processors
`including the Pentium(R), Pentium(R) Pro, Pentium(R II, and
`Pentium(R III processors available from Intel Corporation.
`Alternatively, other processors known in the art may also be
`used. Additionally, processor 255 may include a first level
`(L1) cache (not shown), and/or second level (L2) cache
`memory 207. The L1 and L2 cache memories may be
`integrated into a single device Such as processor 255, or one
`or both may be omitted entirely. Chipset 250 connects BIOS
`255 and main memory 257 to processor 255. In one
`embodiment, chipset 250 is a 440PCIset series PCI chipset
`available from Intel Corporation, although various other
`chipsets known in the art may be employed. Main memory
`257 and cache memory 207 store sequences of instructions
`that are executed by processor 255. In one embodiment,
`main memory 257 includes dynamic random access memory
`(DRAM), however, main memory 257 may comprise other
`configurations. The Sequences of instructions executed by
`processor 255 may be retrieved from main memory 257,
`cache memory 207 or Some other Storage device Such as
`hard disk 264 via IDE bus 261. Additionally, multiple
`processors (not shown) may be connected to chipset 250 as
`well as one or more Video devices Such as a cathode ray tube
`(CRT) or liquid crystal display (LCD) (neither shown).
`Chipset 250 may also be connected to additional bus
`structures Such as SMBus 240 and PCI bus 211. In one
`embodiment, network controller 212 is connected to chipset
`250 through PCI bus 211. Network controller 212 is also
`connected to alert hardware 214 by way of SMBus 215, as
`well as network 200 which is identical to network 100
`shown in FIG. 1.
`SMBus 240 connects alert hardware 214 to sensors 245
`and input/output unit 263. In one embodiment, input/output
`unit 263 is a general purpose input/output (GPIO) device,
`whereas Sensors 245 are implemented using a Heceta 4
`environmental IC to detect fluctuations in System Voltages
`and temperatures, as well as CPU and cooling fan integrity.
`If an event Such as, for example, a cooling fan failure is
`detected by sensors 245, alert hardware 214 is able to detect
`the event through SMBus 240.
`EEPROM 217 is connected to alert hardware 214 and
`provides the alert hardware with various default configura
`tion data. In one embodiment, EEPROM 217 is a Microw
`ire" compatible electrically erasable programmable read
`only memory that holds data about the alert hardware's
`default packet format, default register values, and SMBus
`device polling information. In one embodiment, alert hard
`ware 214 polls SMBus 240 for events by comparing SMBus
`address and register data loaded from EEPROM 217 against
`a bit mask using a logical AND function.
`Software executing on client 210 can Similarly generate
`events on alert hardware 214 by writing to certain registers
`
`Ex. 1049, Page 18
`
`

`

`7
`(not pictured) included in alert hardware 214. BIOS 255 for
`example, may be connected to, and write POST codes to
`alert hardware 214, whereby the codes are thereafter encap
`Sulated in an event message packet and Sent to alert proxy
`125 for interpretation. Alert hardware 214 can also detect
`events generated on Signal lines connected directly to the
`alert hardware. One embodiment of Such signal lines is
`depicted in FIG. 2 as input pins 224 and output pins 234
`which are shown connected to alert hardware 214. Both
`input pins 224 and output pins 234 may be implemented
`using a GPIO device connected to alert hardware 214. In one
`embodiment, GPIO 263 may be connected directly to alert
`hardware 214 rather than SMBus 240. One or more of input
`pins 224 may be connected to one or more Sensors that
`monitor System conditions. Similarly, one or more of output
`pins 234 may provide Signals to effectuate control data
`received from management Server 120.
`In one embodiment of the present invention, alert hard
`ware 214 may be connected to power Source 262 through
`output pins 234, or in another embodiment, power Source
`262 may be connected to GPIO device 263 as shown in FIG.
`2. A signal line from alert hardware 214 or GPIO 263 may
`also be connected to a power Signal trace on the motherboard
`of client 210, such that management server 120 may cause
`alert hardware 214 to perform remote power functions on
`client 210 by way of a network control data packet.
`Similarly, a signal line from alert hardware 214 or GPIO 263
`may be connected to a reset pin of the processor of client
`210, such that management server 120 may effectuate a
`remote system reset on client 210 by way of a network
`control data packet. In one embodiment, the Stimulus for
`Such remote power/reset operations is an Remote Manage
`ment & Control Protocol (RMCP) data packet sent from
`alert proxy 125 to alert hardware 214 (discussed below). In
`an alternative embodiment of the present invention, power/
`reset operations are effectuated by alert hardware 214 using
`the Simple Network Management Protocol (SNMP-defined
`in Request for Comments (RFC) 1157).
`FIG. 3A is a block diagram illustrating one embodiment
`of an input pin connection Scheme on a first System, whereas
`FIG. 3B is a block diagram illustrating one embodiment of
`an input pin connection Scheme on a Second System. It is to
`be appreciated that additional pin connection Schemes other
`than those illustrated may equivalently be implemented
`without departing from the Spirit and Scope of the invention.
`Referring to FIG. 3A, alert hardware 314 is shown con
`nected to network controller 312 and SMBus 340 having
`sensors 345. Alert hardware 314 is also shown having four
`input pins (pin 1, pin 2, pin 3, and pin 4) connected to four
`corresponding Switches or Sensors. In FIG. 3A, a cover
`tamper Switch is connected to pin 1, a fan Sensor device is
`connected to pin 2, a CPU monitoring device is connected
`to pin 3, and a link loSS Se