Ulllted States Patent [19]
`Johnson et al.
`
`[54] EVENT NOTIFICATION IN A COMPUTER
`SYSTEM
`
`
`
`
`
`[75] Inventors: Monte L. Johnson, Orem; Lori Olson - _
`
`sGailtilsleg’ogoggrlgn?iiigzth of
`p .
`.
`’
`’
`SPhhgV1he> an of Utah
`
`_
`[73] Asslgneei Novel], 1116-, Provo, Utah
`
`[21] APPL NO; 08/741 925
`’
`Oct. 31, 1996
`
`[22] Filed:
`
`Related U_S_ Application Data
`
`[60]
`
`Provisional application No. 60/007,214, Nov. 3, 1995.
`
`[51] Int. Cl.6 ................................................. .. G06F 15/163
`[52] US. Cl. ......... ..
`709/300; 709/1
`[58] Field Of Search ................................... .. 395/670, 672,
`395/673, 704, 680, 682
`
`[56]
`
`References Cited
`
`U'S' PATENT DOCUMENTS
`5,185,885
`2/1993 Dysart et al. ......................... .. 395/600
`5,212,778
`5/1993 Dally et al.
`. 395/400
`5,237,684
`8/1993 Record et al.
`. 395/650
`5,247,676
`9/1993 OZur et al. ............................ .. 395/650
`5,265,206 11/1993 Shackelford et al. ................ .. 395/200
`5,276,899
`1/1994 Neches ............ ..
`. 395/800
`5,283,856
`2/1994 Gross et al.
`395/51
`5,291,593
`3/1994 Abraham et al. .
`. 395/600
`
`'
`4/1994 Feigenbaum'et'al. ................ .1 395/775
`573057461
`5/1994 Matheny et al. ...................... .. 395/164
`5:315:703
`6/1994 Daniel et a1_ __
`_ 395/650
`573217837
`6/1994 East et al. .... ..
`. 395/725
`5,321,841
`8/1994 Beitel et al
`5,339,423
`- 395/600
`5,355,406 10/1994 Checinski et a1~
`379/88
`-
`5160;? et ‘til-1""
`5,377,350 12/1994 Skinner ................................. .. 395/600
`5,388,189
`2/1995 Kung ............ ..
`395/50
`
`a eny e a. ...................... ..
`
`,
`
`,
`
`US005925108A
`[11] Patent Number:
`[45] Date of Patent:
`
`5,925,108
`Jul. 20, 1999
`
`5,404,529
`5,414,851
`5,414,854
`
`4/1995 Chernikoff et al. .................. .. 395/700
`5/1995 Brice, Jr. et al.
`395/650
`5/1995 Heninger et al.
`395/700
`
`,
`
`,
`
`5,421,016
`5,423,023
`5,423,043
`5,428,734
`5,428,792
`5,430,875
`5,430,876
`5,434,964
`5,437,007
`5,437,014
`5,437,025
`5,781,724
`
`
`
`gohgh ~~~~~~~~ ~~ uc er .................................. ..
`
`5/1995 Conner et al. ........................ .. 395/700
`6/1995 Batch et al.
`395/500
`6/1995 Fitzpatrick et al. .................. .. 395/700
`6/1995 Haynes et al. ........................ .. 395/159
`6/1995 Conner et al.
`395/700
`7/1995 Ma ................ ..
`395/650
`7/1995 Schreiber et al. ..
`395/650
`7/1995 Moss et al.
`395/157
`7/1995 Bailey et al.
`395/159
`7/1995 Busboom et al. .................... .. 395/275
`7/1995 Bale et al. ............................ .. 395/600
`7/1998 NevareZ et al. ...................... .. 395/186
`
`OTHER PUBLICATIONS
`
`“The Amadeus GR ”, V. Cahill et al., OOPSLA, 1993, pp.
`144—161
`“ASX: An Object—Oriented Framework for Developing Dis
`tributed Applications”, D. Schmidt, USENIX Association
`C++ Technical Conference, 1994, pp. 207—226.
`“Callback functions: The heart of every GUI’s API”, R. van
`Loon, C++ Report, Nov.—Dec. 1994, pp. 43—46.
`
`(List continued on next page.)
`
`_
`_
`__
`P ""Wy EXaml”@r—MaJ1d A~ Banankhah
`Attorney, Agent, or Flrm—C0II1P1lI@r LaW+
`
`[57]
`
`ABSTRACT
`
`A system and method separate the order in Which event
`handlers register from the Order in Which the event handlers
`are noti?ed of events- This allows any Convenient registra
`tion order to be used together With a noti?cation order that
`corresponds to a network architecture, a memory hierarchy,
`or another familiar scale. The noti?cation order is deter
`mined by the event producers, and therefore may be reversed
`Without re-registering the event handlers. Events may be
`Eroadcash ?ght’ Carry dattafbigween genihandlers’ and may
`6 consume 0 Preveh ‘1r er no 1 Ca 10“
`
`5,394,544
`5,396,630
`
`2/1995 Motoyama et al. .................. .. 395/575
`3/1995 Banda et a1. .......................... .. 395/700
`
`20 Claims, 5 Drawing Sheets
`
`Register Event X Name
`
`Register Event Consumer X OSI
`Layer as Ordering Value
`
`Register Event Consumer X
`Notification Callback Procedure
`
`Register Event Consumer X
`Consumtion, Broadcast Flas
`
`Register Event Consumer X Version
`
`Register Event Y Name
`
`Register Event Consumer Y OSI
`Layer as Ordering Value
`
`Register Event Consumer Y
`Notification Callback Procedure
`
`Register Event Consumer Y
`Consumption, Broadcast Flags
`
`Register Event Consumer Y Version
`
`54
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 1
`
`

`
`5,925,108
`Page 2
`
`OTHER PUBLICATIONS
`
`“A Communication Facility for Distributed Object—Oriented
`Applications”, S. Deshpande et al., USENIX Association
`C++ Technical Conference, 1992, pp. 263—276.
`“Communication Mechanism on Autonomous Objects”, Y.
`IshikaWa, OOPSLA, 1992, pp. 303—314.
`“Designing Object Systems—Object communication”, S.
`Cook et al., JOOR Sep. 1994, pp. 14—23.
`“An expanded vieW of messages”, D. Firesmith, JOOR
`Ju1.—Aug. 1993, pp. 51—52.
`“Event—Driven Threads C++”, D. Ford, Dr. Dobb’s Journal,
`Jun. 1995, pp. 48—50, 52, 53, 98, 100, 102.
`“The Kala Basket”, S. Simmel et al., OOPSLA, 1991, pp.
`230—246.
`“Object—oriented design of a ?nite state machine”, M.
`Ackroyd, JOOR Jun. 1995, pp. 50—59.
`
`“OptimiZing Multi—Method Dispatch Using Compressed
`Dispatch Tables”, E. Amiel et al., OOPSLA, 1994, pp.
`244—258.
`
`“OTSO—An Object Oriented Approach To Distributed
`Computation”, J. Koivisto et al., USENIX Association C++
`Conference, 1991, pp. 163—177.
`“A Static Type System for Message Passing”, G. Ghelli,
`OOPSLA, 1991, pp. 129—143.
`FIFO—based
`in
`“Supporting
`distributed
`objects
`message—passing systems”, W. Chang et al., JOOR Feb.
`1995, pp. 56—64.
`“The Xthreads Library: Design, Implementation, and Appli
`cations”, J. Sang et al., IEEE COMPSAC, 1993, pp.
`173—179.
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 2
`
`

`
`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 1 of5
`
`5,925,108
`
`1
`(BMW)
`
`~ NEE
`
`mmdm
`
`3K %\ 2
`
`QmQsEz saw: v D
`
`
`E15 ww/Eohw \ m
`4 a /___ \
`
`Y _
`
`_ _ NJ _
`
`E
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 3
`
`

`
`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 2 of5
`
`5,925,108
`
`Register Event Consumers
`
`i
`
`Register Ordering Values for Event Consumers
`
`44 \
`\
`\
`
`Register Evint Producer
`i
`i
`
`Produce Event
`
`Notify Event Consumer(s)
`
`FIG. 2
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 4
`
`

`
`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 3 of5
`
`5,925,108
`
`/8
`
`/////8//g//
`
`01 N
`
`01 .5;
`
`Register Event X Name
`
`l
`Register Event Consumer X OSI
`Layer as Ordering Value
`l
`
`Register Event Y Name
`
`Register Event Consumer X
`Notification Callback Procedure
`l
`Register Event Consumer X
`Consumption, Broadcast Flags
`l
`Register Event Consumer X Version
`l
`l
`Register Event Consumer Y OSI
`Layer as Ordering Value
`l
`Register Event Consumer Y
`Notification Callback Procedure
`l
`Register Event Consumer Y
`Consumption, Broadcast Flags
`l
`Register Event Consumer Y Version
`l
`FIG. 3
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 5
`
`

`
`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 4 of5
`
`5,925,108
`
`7°\ i
`Notify X
`72 \ i
`Notify Y
`\ l
`Notify Z
`
`74
`
`76w i
`Notify Z
`78 \ i
`Notify Y
`\ l
`Notify X
`
`a0
`
`1
`82W v
`Notify X
`84 N v
`Notify Y:
`Y Consumes
`Event
`
`FIG. 4
`
`86\ l
`Notify X, Y, Z
`
`88 / Register Primary Ordering Value
`i
`90 /
`
`Register Secondary Ordering Value
`
`FIG. 5
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 6
`
`

`
`U.S. Patent
`
`Jul. 20, 1999
`
`Sheet 5 of5
`
`5,925,108
`
`100 \
`
`110 \
`
`102 \ Event Consumer for Task X
`
`104 \ Resource Management for Task X
`
`106 \
`
`Registration for Task X
`
`112
`\ Event Consumer for Task Y
`
`114 1 Resource Management for Task Y
`
`116 \.
`
`Registration for Task Y
`
`FIG. 6
`
`120 \ Resource Management 122 \ Resource Management
`for Task X
`for Task Y
`124
`126
`\
`\
`
`13O\ Event Handler, Registration for Task X
`
`132\ Event Handler, Registration for Task Y
`
`FIG. 7
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 7
`
`

`
`1
`EVENT NOTIFICATION IN A COMPUTER
`SYSTEM
`
`RELATED APPLICATIONS
`
`This application is based on commonly owned copending
`US. patent application Ser. No. 60/007,214, ?led Nov. 3,
`1995, for a Method and Apparatus for Improved Event or
`Message Noti?cation in a Computer System (hereinafter
`“the ’214 application”).
`
`COPYRIGHT NOTICE
`
`A portion of the disclosure of this patent document
`contains material Which 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 Of?ce
`patent ?le or records, but otherWise reserves all copyright
`rights Whatsoever. The copyright oWner does not hereby
`Waive any of its rights to have this patent document main
`tained in secrecy, including Without limitation its rights
`pursuant to 37 C.F.R. § 1.14.
`
`FIELD OF THE INVENTION
`
`The present invention relates to the management of event
`or message noti?cations in a computer system, and more
`particularly to the relationship betWeen event handler
`registration, the manner in Which registered event handlers
`receive noti?cation of events, and the computer system
`architecture.
`
`TECHNICAL BACKGROUND OF THE
`INVENTION
`
`Event mechanisms are used in many different computer
`systems to enable parts of the system to communicate With
`one another. The terms “event” and “message” are used
`inconsistently Within the literature. As used herein, “event”
`refers to an incident Whose occurrence (and possibly asso
`ciated data) should be communicated by one part of a
`computer system to at least one other part of the system to
`enable the system to operate appropriately. “Event” is some
`times used as an abbreviation for “message describing an
`event,” because communication may be accomplished by
`transmitting messages betWeen different parts of the system
`using computer hardWare. The hardWare is often (but not
`necessarily) controlled by computer softWare. The messages
`transmitted in response to an occurrence of an event are
`sometimes termed “event noti?cations.”
`One familiar approach to the management of event noti
`?cation utiliZes a procedural implementation. The notifying
`function is made expressly aWare of the destination(s) of
`each event noti?cation. The notifying function makes a
`speci?c call to a function in each destination Which is
`responsible for handling the information resulting from the
`communication. This type of message communication is
`“tightly coupled” in the sense that the notifying function and
`the destination function must knoW of each other at compile
`time in order for the function calls to be correctly linked
`together.
`In such procedural implementations, the notifying func
`tion is forced to make multiple calls (either directly or
`indirectly) Whenever more than one destination needs to
`receive the message, because one call must be made for each
`destination. If the messages are intended to arrive at their
`respective destinations in a particular order, then the noti
`fying function imposes an ordering by calling the destination
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`5,925,108
`
`2
`functions in the desired sequence. This likeWise requires
`express knoWledge of the destination functions.
`Under another approach to the management of event
`noti?cation, the messages (or events) are passed through a
`message queue from the source to the destination. This
`creates a “loosely-coupled” system in that the sending and
`receiving functions need not knoW about each other at
`compile time, but are linked instead through the message
`queue. Such a message queue implementation is difficult to
`use When a message may have multiple destinations because
`the message queue is typically implemented as a ?rst-in
`?rst-out (“FIFO”) structure. After the ?rst destination has
`retrieved the pending message from the queue, the message
`is either removed, in Which case it is no longer available for
`any other destination, or the message is left in place, in
`Which case it hinders access to subsequent messages.
`Under a third approach, event sources and event destina
`tions are loosely coupled through a registration process. This
`alloWs several destinations for a single source, but the order
`in Which messages are distributed to multiple destinations is
`either tightly constrained or unpredictable. TWo types of
`distribution are used, namely “simultaneous” broadcast and
`distribution according to the order of destination registra
`tion.
`Under “simultaneous” broadcast, the order of receipt is
`not important, so it is assumed that all destinations receive
`the message at the same time. In practice, messages may
`arrive at different times but the order is not predictable and
`thus cannot be relied on.
`Distribution according to the order of destination regis
`tration may result in a First Registered First Noti?ed order
`or a Last Registered First Noti?ed order. In either case, the
`order in Which different destinations receive a given mes
`sage depends on the order in Which the destinations regis
`tered their interest in such messages With some central
`registry. In situations Where the desired order of message
`receipt does not match the most convenient or established
`order of registration, tying the event noti?cation order so
`closely to the registration order is not advantageous.
`Yet another approach to event noti?cation utiliZes hard
`Ware based priority encoders. These encoders, Which are
`tailored for use in prioritiZing multiple simultaneous inputs,
`take a number of inputs of varying degrees of priority. When
`several inputs are asserted, the encoder resolves to the input
`Which has the highest priority. When that input has been
`satis?ed and is no longer asserted, the priority encoder Will
`again resolve to the input Which has the highest priority. This
`mechanism alloWs the asserted input With the highest pri
`ority to alWays be identi?ed When multiple inputs are
`asserted at one time.
`HoWever, such special-purpose hardWare is expensive,
`dif?cult to con?gure, and difficult to upgrade. Moreover,
`each piece of hardWare is customiZed, so the hardWare
`introduces many potential failure points Which cannot be
`?xed Without hardWare changes. Finally, priority encoders
`are tailored for use in prioritiZing simultaneous inputs, not
`for ordering a sequence of event noti?cations.
`Thus, it Would be an advancement in the art to provide a
`system and method for loosely coupled event noti?cation to
`multiple destinations Which alloW the noti?cation order to
`differ from the registration order.
`It Would also be an advancement to provide such a system
`and method Which do not require special-purpose hardWare
`such as priority encoders.
`It Would be an additional advancement to provide such a
`system and method Which support broadcast noti?cation.
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 8
`
`

`
`3
`Such a method and system for event noti?cation are
`disclosed and claimed herein.
`
`5,925,108
`
`BRIEF SUMMARY OF THE INVENTION
`
`10
`
`15
`
`25
`
`35
`
`The present invention provides a novel method and sys
`tem Which allow an event noti?cation to be sent to multiple
`destinations according to a prede?ned order. In one
`embodiment, the noti?cation order is established When each
`destination registers for noti?cation of the event. HoWever,
`the noti?cation order need not be the same as, or even the
`reverse of, the registration order.
`Each registration of a destination for event noti?cation
`includes an indication of the desired noti?cation order of the
`event handler (also termed herein the event “consumer”,
`although consumption of an event to prevent further noti?
`cations is optional). This noti?cation order does not change
`after the registration. This distinguishes the invention from
`executive task handlers Which constantly reassign priority to
`each task to determine Which task Will execute next. The
`event engine, upon receipt of the event noti?cation, ?rst
`passes noti?cation to the registered destination With the
`highest noti?cation level, folloWed by the next and so on. An
`option exists for the engine to start With the event destination
`of the loWest noti?cation level and continue until the highest
`level event destination has been serviced. If a broadcast
`mode of noti?cation is desired, or if ordering is not
`important, then registering the event destination With any
`noti?cation level Will produce the desired results for broad
`cast events.
`The invention has several features Which promote
`modular, logically organiZed source code Without sacri?cing
`the ability to fully control the order of event noti?cation. The
`invention alloWs a loosely coupled system in Which event
`handlers do not need to be expressly knoWn by the function
`producing the event. The event handlers do not need to knoW
`that any other routine is also interested in handling the
`noti?cation of the event. Other events Will be noti?ed
`according to the order speci?ed at noti?cation registration
`time. This means that the registration can occur in any
`arbitrary order for a given set of interested destinations and
`the proper order of noti?cation Will still be enforced.
`In some embodiments, the desired ordering corresponds
`directly to a Well knoWn scale, such as a memory hierarchy
`or the ordered layers in a netWork architecture reference
`45
`model. One such embodiment is utiliZed in the Novell VLM
`Client code. Another embodiment is utiliZed in the Novell
`Client32 code, Which contains modules that approximate the
`seven levels of the Well-knoWn Open Systems Interconnec
`tion netWork architecture reference model (“OSI Model”)
`(CLIENT32 is a trademark of Novell, Inc.).
`This ordering, evident in the design of Client32 code, is
`also the order required for most of the events of interest
`Within the client. For example, if a user Wishes to remove a
`PCMCIA NetWork Interface Card (“NIC”) from a client the
`folloWing sequence of events needs to be accomplished:
`(a) all open ?les associated With the connection supported
`by the NIC need to be closed;
`(b) any ?le information cached at the client for those
`connections needs to be ?ushed to the server disks;
`(c) the connection needs to be closed or terminated;
`(d) the transport (IPX) needs to be noti?ed that the NIC
`in question is no longer available for service requests; and
`(e) the loW-level drivers associated With the card need to
`be noti?ed that the particular NIC is no longer available in
`the machine.
`
`55
`
`65
`
`4
`Without the present invention, these noti?cations could be
`accomplished in a tightly coupled system, but a noti?cation
`routine Would require intimate knoWledge of the above
`sequence of events and Would call routines associated With
`each of the above mentioned noti?cations. Such dependen
`cies interfere With modular, logically organiZed code and
`hence make the creation and modi?cation of large computer
`systems more difficult and expensive.
`HoWever, With the present invention this ordering can be
`readily achieved Without such dependencies. An event is
`associated With the “Remove PCMCIA Card” action, and
`corresponding event handlers are provided for the ?le
`system, the ?le cache, the connection manager, the transport
`module, and the loW-level NIC driver. Upon registration a
`noti?cation order is speci?ed for these event handlers. The
`noti?cation order, Which may differ from the registration
`order, is based upon the OSI Model. Upon receipt of the
`event occurrence, a system according to the invention noti
`?es each of the destinations in turn according to their
`noti?cation order.
`Other events in Client32 code require a different ordering.
`Some of the events of interest are handled in a bottom-up
`OSI Model ordering rather than the top-doWn ordering
`illustrated above. But bottom-up noti?cation order can also
`be readily speci?ed for a given class of events using the
`present invention.
`The invention alloWs event handler code to be located in
`the source modules af?liated With the respective tasks to be
`accomplished. The registration of the event handler can also
`be located in the same piece of code. This promotes data
`hiding and a more object-oriented approach to programming
`than the tightly-coupled procedural approach, and readily
`alloWs multiple destinations, unlike the message queue
`approach.
`The features and advantages of the present invention Will
`become more fully apparent through the folloWing descrip
`tion.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`To illustrate the manner in Which the advantages and
`features of the invention are obtained, a more particular
`description of the invention summariZed above Will be given
`With reference to the attached draWings. These draWings
`only provide selected embodiments of the invention and are
`not therefore to be considered limiting of its scope. In the
`draWings:
`FIG. 1 is a diagram illustrating individual computers and
`a computer netWork, each of Which is suitable for use With
`the present invention.
`FIG. 2 is a ?oWchart illustrating a noti?cation method of
`the present invention, including a notifying step.
`FIG. 3 is a ?oWchart further illustrating registration steps
`of the method shoWn in FIG. 2.
`FIG. 4 is a ?oWchart further illustrating the notifying step
`shoWn in FIG. 2.
`FIG. 5 is a ?oWchart further illustrating an ordering value
`registration step shoWn in FIG. 2.
`FIG. 6 is a block diagram illustrating a form of softWare
`organiZation supported by the present invention.
`FIG. 7 is a block diagram illustrating a form of softWare
`organiZation utiliZed in the absence of the present invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`The present invention relates to a method and apparatus
`for managing event noti?cation in a computer system. The
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 9
`
`

`
`10
`
`15
`
`25
`
`35
`
`5
`invention is suitable for use on individual stand-alone com
`puters as Well as on individual or multiple computers
`connected in a computer network. The computers may be
`Workstations, laptop computers, disconnectable mobile
`computers, ?le servers, or a combination thereof. The net
`Work may include one or more LANs, Wide-area networks,
`Internet servers and clients, intranet servers and clients, or a
`combination thereof.
`One of the many computer netWorks suited for use With
`the present invention is indicated generally at 10 in FIG. 1.
`In one embodiment, the netWork 10 includes Novell Net
`Ware® netWork operating system softWare (NETWARE is a
`registered trademark of Novell, Inc.). In alternative
`embodiments, the netWork includes NetWare Connect
`Services, VINES, WindoWs NT, WindoWs 95, LAN
`Manager, or LANtastic netWork operating system softWare
`(VINES is a trademark of Banyan Systems; WINDOWS NT,
`WINDOWS 95, and LAN MANAGER are trademarks of
`Microsoft Corporation; LANTASTIC is a trademark of
`Artisoft). The netWork 10 may include a local area netWork
`12 Which is connectable to other netWorks 14, including
`other LANs or portions of the Internet or an intranet, through
`a gateWay or other mechanism.
`The netWork 10 includes several ?le servers 16 that are
`connected by netWork signal lines 18 to one or more netWork
`clients 20. The ?le servers 16 and netWork clients 20 may be
`con?gured by those of skill in the art in a Wide variety of
`Ways to operate according to the present invention. The ?le
`servers 16 may be con?gured as Internet servers, as intranet
`servers, as directory services providers, as softWare compo
`nent servers, or as a combination thereof. The servers 16
`may be uniprocessor or multiprocessor machines.
`Suitable netWork clients 20 include, Without limitation,
`personal computers 22, laptops 24, and Workstations 26. The
`signal lines 18 may include tWisted pair, coaXial, or optical
`?ber cables, telephone lines, satellites, microWave relays,
`modulated AC poWer lines, and other data transmission
`“Wires” knoWn to those of skill in the art. In addition to the
`netWork client computers 20, a printer 28 and an array of
`disks 30 are also attached to the netWork 10. Although
`particular individual and netWork computer systems and
`components are shoWn, those of skill in the art Will appre
`ciate that the present invention also Works With a variety of
`other netWorks and computers.
`The ?le servers 16 and the netWork clients 20 are capable
`of using ?oppy drives, tape drives, optical drives or other
`means to read a storage medium 32. A suitable storage
`medium 32 includes a magnetic, optical, or other computer
`readable storage device having a speci?c physical substrate
`con?guration. Suitable storage devices include ?oppy disks,
`hard disks, tape, CD-ROMs, PROMs, RAM, and other
`computer system storage devices. The substrate con?gura
`tion represents data and instructions Which cause the com
`puter system to operate in a speci?c and prede?ned manner
`as described herein. Thus, the medium 32 tangibly embodies
`a program, functions, and/or instructions that are executable
`by the ?le servers 16 and/or netWork client computers 20 to
`perform event noti?cation steps of the present invention
`substantially as described herein.
`FIG. 2 illustrates a method for managing event noti?ca
`tion in a computer system (such as one or more of the
`systems 10, 16, 20 shoWn in FIG. 1) according to the present
`invention. The method includes a step 40 of registering at
`least one event consumer With a registry capable of holding
`multiple registrations. Registration is described in greater
`detail hereafter, but generally creates a record of Which event
`consumers to notify in response to Which events.
`
`45
`
`55
`
`65
`
`5,925,108
`
`6
`Suitable event consumers include event handlers of the
`kind familiar to those of skill in the art. One suitable registry
`includes a linked list of Event Control Blocks (“ECBs”)
`such as the list of NESLiECB structures described in
`English and in the C programming language in the ’214
`application; said description is hereby incorporated by ref
`erence. In addition to providing the registry With informa
`tion such as an identi?cation of the event handler and the
`event(s) of Which it Wishes noti?cation, the event handler
`registration step 40 de?nes a registration order for the
`registered event consumers.
`The method also includes a step 42 of registering an
`ordering value for at least one registered event consumer.
`The step 42 de?nes an event consumer order Which typically
`differs from the registration order. In some embodiments, the
`steps 40 and 42 are both accomplished using one routine,
`such as the NESLRegisterConsumer() function described in
`English and in the C programming language in the ’214
`application; said description is hereby incorporated by ref
`erence.
`The method also includes a step 44 of registering at least
`one event producer With the registry. Such registration
`produces a record containing at least an identi?er for the
`producer and the type of event it produces. In one
`embodiment, the step 44 is accomplished using a
`NESLRegisterProducer( ) function described in English and
`in the C programming language in the ’214 application; said
`description is hereby incorporated by reference. Multiple
`registered producers may produce the same event.
`The method also includes a step 46 of producing an event
`using the event producer that Was registered during the step
`44. Suitable events include a Wide variety of events relating
`to user actions, resource usage, and other occurrences both
`Within and Without the computer system, of types familiar to
`those of skill in the art. In one embodiment, the step 46 is
`accomplished using a NESLProduceEvent() function and an
`EventData structure described in English and in the C
`programming language in the ’214 application; said descrip
`tion is hereby incorporated by reference.
`Finally, the illustrated method includes a step 48 of
`notifying at least one of the event consumers of the event.
`Noti?cation is performed “according to” the event consumer
`order, namely, in the speci?ed order or in the reverse of that
`order. Although the event consumer order may coincide With
`the registration order, it need not do so. In one embodiment,
`the step 48 is accomplished using callback routines Which
`Were registered during the step 40. The callback routines are
`invoked according to the order de?ned during the step 42.
`Noti?cation is further described in English and in the C
`programming language in the ’214 application; said descrip
`tion is hereby incorporated by reference.
`FIG. 3 illustrates one embodiment of the steps 40, 42 in
`greater detail. The step 40 of registering event consumers
`comprises steps 50, 60 of registering the names of tWo
`events X and Y; steps 54, 64 of registering callback proce
`dures for X and Y; steps 56, 66 of registering certain ?ags or
`equivalent indicators; and steps 58, 68 of registering version
`identi?ers. The step 42 of registering ordering values com
`prises steps 52, 62 of registering OSI Model layers as
`ordering values. As indicated at the bottom of FIG. 3,
`registrations may also be performed for additional event
`handlers; tWo registrations are shoWn merely for illustration.
`One embodiment of a system according to the invention
`maintains in computer memory a dynamically allocated
`linked collection of ECBs corresponding to events. Each
`ECB contains a version indicator, at least one ordering
`
`Petitioner Microsoft Corporation - Ex. 1058, p. 10
`
`

`
`5,925,108
`
`7
`value, an event name, an indication as to Whether the
`corresponding event is consumable, an indication as to
`Whether the corresponding event is for broadcast, an iden
`ti?cation of a module Which oWns the event, and a pointer
`to an internal Workspace. In one embodiment, broadcast
`events are implemented as non-consumable events.
`ECBs and each of the steps shoWn in FIG. 3 are further
`described in English and in the C programming language in
`the ’214 application; said descriptions are hereby incorpo
`rated by reference. By Way of illustration, and not limitation,
`steps 50, 60 may be accomplished using the NESLiECB
`NecbEventName ?eld and related routines; steps 52, 62 may
`be accomplished using the NESLiECB NecbOsiLayer ?eld
`and related routines; steps 54, 64 may be accomplished
`using the NESLiECB PNecbNotifyProc ?eld and related
`routines; steps 56, 66 may be accomplished using the
`NESLiECB NecbRefData ?eld and related routines; and
`steps 58, 68 may be accomplished using the NESLiECB
`NecbVersion ?eld and related routines.
`Steps 52 and 62 illustrate a method Wherein the step 42
`(FIG. 2) of registering an ordering value for each event
`consumer comprises registering ordering values Which cor
`respond directly to layers in a computer netWork architecture
`reference model, namely, the OSI Model. As discussed in the
`Summary of the Invention, at pages 77—78, 134 in the ’214
`application, and elseWhere, alloWing noti?cation in an order
`that corresponds to system architecture but nonetheless
`differs from registration order alloWs softWare to be orga
`niZed more logically and ef?ciently from a programmer’s
`point of vieW.
`Under an alternative method of the invention the step 42
`(FIG. 2) of registering an ordering value for each event
`consumer comprises registering ordering values Which cor
`respond directly to a memory hierarchy. Various memory
`hierarchies are Well-known, including hierarchies organiZed
`according to memory access speed, memory capacity, the
`number of tasks Which rely on data stored in a particular
`section of memory, and other familiar criteria. Event con
`sumers may be organiZed during the step 42 according to the
`levels of such a memory hierarchy.
`To illustrate this aspect of the invention, assume that a
`given memory hierarchy contains a ?le contents cache, a
`netWork connection cache, and a volume information cache,
`in order of increasing importance. Assume further that an
`“out of memory” event occurs Which is intended to cause
`some cache event handler to free up a block of memory
`containing at least a requested number of bytes, such as 8
`Kbytes. The ?rst event handler to see the event is the ?le
`contents cache event handler; if that handler can free 8
`Kbytes, it does so and then consumes the event. If the ?le
`contents cache event handler cannot free 8 Kbytes, it returns
`a “not consumed” message to the event engine, Which then
`passes the “out of memory” event noti?cation to the netWork
`connection cache event handler. This handler either frees the
`requested memory and consumes the event or returns a “not
`consumed” status to the event engine, Which passes the
`event noti?cation on to the volume information cache event
`handler.
`Of course, the event handl