United States Patent
`
`Johnson et at
`
`11111111111111111111111
`US005925108A
`Patent Number
`
`Date of Patent
`
`11111111
`
`5925108
`Jut 20 1999
`
`EVENT NOTIFICATION IN
`SYSTEM
`
`COMPUTER
`
`Johnson Orem Lori Olson
`Inventors Monte
`Gauthier Troy Thomas both of
`Spanish Fork Mark Dakins
`all of Utah
`
`Springville
`
`Assignee Novell
`
`Inc Provo Utah
`
`Appl No 08/741925
`
`Filed
`
`Oct 31 1996
`
`Related U.S Application Data
`
`Provisional application No 60/007214 Nov
`
`1995
`
`Int Cl.6
`U.S Cl
`
`Field of Search
`
`GO6F 15/163
`
`709/300
`
`709/1
`
`672
`395/670
`395/673 704 680 682
`
`References Cited
`
`U.S PATENT DOCUMENTS
`
`5404529
`5414851
`5414854
`5418968
`5421014
`5421016
`5423023
`5423043
`5428734
`5428792
`5430875
`5430876
`5434964
`5437007
`5437014
`5437025
`5781724
`
`4/1995 Chernikoff et al
`
`5/1995 Brice Jr et al
`5/1995 Heninger et al
`5/1995 Gobeli
`
`5/1995
`
`Bucher
`
`5/1995
`
`Conner
`
`et al
`
`6/1995
`
`Batch et al
`
`6/1995
`
`6/1995
`
`Fitzpatrick et al
`
`Haynes et al
`
`et al
`
`6/1995
`Conner
`7/1995 Ma
`7/1995
`Schreiber
`7/1995 Moss et al
`
`et al
`
`7/1995
`
`7/1995
`
`Bailey et al
`Busboom et al
`
`7/1995
`
`Bale et al
`
`7/1998
`
`Nevarez
`
`et al
`
`OTHER PUBLICATIONS
`
`395/700
`
`395/650
`
`395/700
`
`395/725
`
`395/650
`
`395/700
`
`395/500
`
`395/700
`
`395/159
`
`395/700
`
`395/650
`
`395/650
`
`395/157
`
`395/159
`
`395/275
`
`395/600
`
`395/186
`
`Cahill et al OOPSLA 1993 pp
`
`The Amadeus GRT
`144161
`ASX An ObjectOriented Framework for Developing Dis
`Schmidt USENIX Association
`tributed Applications
`1994 pp 207226
`Technical Conference
`Callback functions The heart of every GUIs API
`Repor4 NovDec 1994 pp 4346
`Loon
`
`van
`
`395/600
`
`395/400
`
`List continued
`
`on next page
`
`5185885
`5212778
`5237684
`5247676
`5265206
`5276899
`5283856
`5291593
`5291608
`5305454
`5305461
`5315703
`5321837
`5321841
`5339423
`5355406
`5355484
`5367633
`
`5377350
`5388189
`
`5394544
`5396630
`
`2/1993 Dysart et al
`5/1993 Dally et al
`8/1993
`Record et al
`
`9/1993 Ozur et al
`
`11/1993
`
`Shackelford
`
`et al
`
`1/1994 Neches
`
`2/1994
`
`3/1994
`
`3/1994
`
`Gross et al
`Abraham et al
`
`Flurry
`
`4/1994
`
`Record et al
`
`4/1994
`
`Feigenbaum et al
`5/1994 Matheny et al
`6/1994 Daniel et al
`
`6/1994
`
`East et al
`
`8/1994
`
`Beitel et al
`
`10/1994 Checinski et al
`Record et al
`
`10/1994
`
`11/1994 Matheny et al
`12/1994 Skinner
`
`2/1995
`
`Kung
`2/1995 Motoyama et al
`Banda et al
`3/1995
`
`395/650
`
`395/650
`
`395/200
`
`395/800
`
`395/51
`
`395/600
`
`395/725
`
`395/650
`
`395/775
`
`395/164
`
`395/650
`
`395/725
`
`395/600
`
`379/88
`
`395/650
`
`395/164
`
`395/600
`
`395/50
`
`395/575
`
`395/700
`
`Primary ExaminerMajid
`Banankhah
`Attorney Agen4 or FirmComputer Law
`
`ABSTRACT
`
`corresponds
`
`to
`
`event
`
`registra
`
`system and method separate the order in which
`handlers register from the order in which the event handlers
`are notified of events This allows any convenient
`tion order to be used together with
`notification order that
`network architecture memory hierarchy
`familiar scale The notification order is deter
`or another
`mined by the event producers and therefore may be reversed
`without
`re-registering the event handlers Events may be
`broadcast may carry data between event handlers and may
`be consumed to prevent
`further notifications
`
`20 Claims Drawing Sheets
`
`Register Event
`
`Name
`
`Register Event Consumer
`
`OSI
`
`Layer as Ordering Value
`
`hiegister event Lonsumer
`
`Register Event Consumer
`Consumption
`Broadcast Flags
`
`58
`
`Register Event Consumer
`
`Version
`
`Reaster Event
`
`Name
`
`Register Event Consumer
`
`OSI
`
`Layer as Ordering Value
`
`Register Event Consumer
`Notiticatian Callback Pronedure
`
`Register Event Consumer
`
`Consumprion Broadcast Flags
`
`no-
`
`____________
`-register vent Uonsumer
`
`version
`
`Petitioner IBM – Ex. 1058, p. 1
`
`

`
`5925108
`Page
`
`OTHER PUBLICATIONS
`
`Optimizing MultiMethod Dispatch Using Cnmpressed
`et al OOPSLA 1994 pp
`Amid
`Dispatch Tables
`244258
`OTSOAn Object Oriented Approach
`To Distributed
`Koivisto et al USENlXAssociation
`Computation
`1991 pp 163177
`Conference
`
`Static Type System for Message Passing
`OOPSLA 1991 pp 129143
`
`Ghelli
`
`distributed
`
`FIFObased
`in
`objects
`Chang et al JOOI Feb
`
`Supporting
`messagepassing systems
`1995 pp 5664
`The Xthreads Library Design Implementation and Appli
`IEEE COMPSAC 1993 pp
`Sang et al
`cations
`173179
`
`Communication Facility for Distributed ObjectOriented
`et al USENIX Association
`Applications
`Deshpande
`1992 pp 263276
`Technical Conference
`Communication Mechanism on Autonomous Objects
`Ishilcawa OOPSIA 1992 pp 303314
`Designing Object SystemsObject communication
`Cook et al JOOI Sep 1994 pp 1423
`An expanded
`view of messages
`JulAug 1993 pp 5152
`Ford Dr DobbsJourna4
`EventDriven Threads
`Jun 1995 pp 4850 52 53 98 100 102
`The Kala Basket
`Simmel et al OOPSLA 1991 pp
`230246
`Objectoriented design of
`Ackroyd JOOI Jun 1995 pp 5059
`
`finite
`
`state machine
`
`Firesmith JOOI
`
`Petitioner IBM – Ex. 1058, p. 2
`
`

`
`U.S Patent
`
`Jul 20 1999
`
`Sheet
`
`of
`
`5925108
`
`Co
`
`cJ
`
`cc
`CJ
`
`cJ
`
`cJ
`\1
`
`Co
`
`IftI000I
`
`Petitioner IBM – Ex. 1058, p. 3
`
`

`
`U.S Patent
`
`Jul 20 1999
`
`Sheet
`
`of
`
`5925108
`
`40
`
`42
`
`44
`
`46
`
`48
`
`Register Event Consumers
`
`Register Ordering Values for Event Consumers
`
`Register Event Producer
`
`Produce Event
`
`Notify Event Consumers
`
`FIG
`
`Petitioner IBM – Ex. 1058, p. 4
`
`

`
`U.S Patent
`
`Jul 20 1999
`
`Sheet
`
`of
`
`5925108
`
`5O\
`
`52.\
`
`54\
`
`56
`
`58
`
`6O
`
`62
`
`64
`
`66
`
`68
`
`Register Event
`
`Name
`
`Register Event Consumer
`Layer as Ordering Value
`
`OSI
`
`Register Event Consumer
`Notification Callback Procedure
`
`Register Event Consumer
`Consumption Broadcast Flags
`
`Register Event Consumer
`
`Version
`
`Register Event
`
`Name
`
`Register Event Consumer
`Layer as Ordering Value
`
`OSI
`
`Register Event Consumer
`Notification Callback Procedure
`
`Register Event Consumer
`Consumption Broadcast Flags
`
`Register Event Consumer
`
`Version
`
`FIG
`
`Petitioner IBM – Ex. 1058, p. 5
`
`

`
`U.S Patent
`
`Jul 20 1999
`
`Sheet
`
`of
`
`5925108
`
`FIG
`
`88
`
`9O\
`
`Register Primary Ordering Value
`
`Register Secondary Ordering Value
`
`FIG
`
`Petitioner IBM – Ex. 1058, p. 6
`
`

`
`U.S Patent
`
`Jul 20 1999
`
`Sheet
`
`of
`
`5925108
`
`100
`
`110
`
`120
`
`128
`
`102
`
`104
`
`106
`
`Event Consumer for Task
`
`\j
`
`Resource Management
`
`for Task
`
`Registration for Task
`
`112.
`
`114
`
`116
`
`Event Consumer for Task
`
`Resource ManagementforTaskY
`
`Registration for Task
`
`FIG
`
`Resource Managemei
`forTaskX
`
`122
`
`124
`
`130
`
`132
`
`Event Handler Registration for Task
`
`Event Handler Registration for Task
`
`FIG
`
`Petitioner IBM – Ex. 1058, p. 7
`
`

`
`5925108
`
`functions
`
`in the desired sequence
`express knowledge of the destination
`Under
`
`another
`
`This likewise requires
`functions
`
`of event
`
`approach
`to the management
`notification the messages or events are passed through
`message queue from the source to
`the destination This
`the sending and
`loosely-coupled system in that
`creates
`need not know about each
`other
`
`EVENT NOTIFICATION IN
`SYSTEM
`
`COMPUTER
`
`RELATED APPLICATIONS
`
`is based on commonly owned copending
`This application
`U.S patent application Ser No 60/007214 filed Nov
`1995 for
`Method
`and Apparatus
`for Improved Event or
`Message Notification in
`Computer System hereinafter
`the 214 application
`
`COPYRIGHT NOTICE
`
`the disclosure
`
`of
`
`this patent
`
`document
`
`portion of
`contains material which
`is subject
`to copyright protection
`has no objection
`The copyright owner
`to the
`facsimile
`by anyone of the patent document or the patent
`reproduction
`disclosure as it appears in the Patent and Trademark Office
`file or records but otherwise
`reserves all copyright
`patent
`rights whatsoever
`The copyright owner does not hereby
`this patent document main
`waive any of its rights to have
`including without
`tained
`in secrecy
`limitation its
`to 37 C.ER
`1.14
`pursuant
`
`rights
`
`FIELD OF THE INVENTION
`
`The present
`invention relates to the management of event
`system and more
`or message notifications in
`computer
`to the relationship between
`event
`handler
`particularly
`in which registered event handlers
`registration the manner
`and
`receive notification of events
`the computer
`system
`architecture
`
`TECHNICAL BACKGROUND OF THE
`INVENTION
`
`are used in many different computer
`Event mechanisms
`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
`be
`communicated
`ciated data should
`by one
`part of
`least one other part of the system to
`computer
`system to at
`enable the system to operate appropriately Event is some
`times used as an abbreviation
`for message describing
`an
`because communication may be accomplished
`event
`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 notifications
`
`specific
`
`One familiar approach to the management of event noti
`implementation The notifying
`fication utilizes
`procedural
`function is made expressly aware of the destinations
`of
`each
`The notifying function makes
`event notification
`function in each
`destination which is
`for handling the information resulting from the
`responsible
`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
`for the function calls to be correctly linked
`time in order
`
`call
`
`to
`
`together
`
`implementations the notifying func
`In such procedural
`forced to make multiple calls either directly or
`tion is
`needs to
`indirectly whenever more than one destination
`receive the message because one call must be made for each
`destination If
`their
`the messages are intended to arrive at
`then the noti
`particular order
`destinations
`in
`
`respective
`
`fying function imposes an ordering by calling the destination
`
`receiving
`
`functions
`
`at
`
`compile time but are linked instead through
`the message
`queue Such
`message queue implementation is difficult
`to
`10 use when message may have multiple destinations because
`the message queue is typically implemented as
`first-out FIFO structure After the first
`destination
`has
`retrieved the pending message from the queue the message
`removed in which case it
`is no longer available for
`is either
`in place in
`15 any other destination or the message is left
`which case it hinders
`to subsequent messages
`access
`event sources and event destina
`registration process This
`allows several destinations
`for
`the order
`single source but
`in which messages are distributed to multiple destinations
`or unpredictable Two types of
`either
`tightly constrained
`distribution are used namely simultaneous broadcast
`and
`to the order of destination
`distribution according
`
`first-in
`
`is
`
`registra
`
`Under
`
`third approach
`
`tions are loosely coupled through
`
`20
`
`25
`
`30
`
`40
`
`50
`
`tion
`
`Under simultaneous broadcast
`the order of receipt
`is assumed that all destinations
`important
`receive
`not
`so it
`the same time In practice messages may
`the message at
`and
`arrive at different times but
`the order is not predictable
`thus cannot be relied on
`
`is
`
`to the order of destination
`
`regis
`
`several
`
`difficult
`
`each
`
`hardware
`
`so
`
`system
`hardware
`
`Distribution according
`tration may result in
`First Registered First Notified order
`Last Registered First Notified order
`In either case the
`or
`given mes
`in which different destinations
`order
`receive
`sage depends on the order in which the destinations
`regis
`in such messages with some central
`tered their
`interest
`registry In situations where the desired order of message
`receipt does not match the most convenient
`or established
`order of registration tying the event notification order
`closely to the registration order is not advantageous
`Yet another approach to event notification utilizes hard
`ware based priority encoders
`These encoders which are
`tailored for use in prioritizing multiple simultaneous
`inputs
`number of inputs of varying degrees of priority When
`take
`inputs are asserted the encoder
`resolves to the input
`the highest priority When that
`which has
`input has been
`satisfied 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
`identified when multiple inputs
`be
`ority to always
`are
`asserted at one time
`such special-purpose
`However
`is expensive
`to configure and difficult
`to upgrade Moreover
`is customized so the hardware
`piece of hardware
`be
`failure points which cannot
`introduces many potential
`fixed without hardware
`changes Finally priority encoders
`are tailored for use in prioritizing simultaneous
`inputs not
`for ordering
`sequence of event notifications
`Thus it would be an advancement
`in the art to provide
`60 system and method for loosely coupled event notification to
`multiple destinations which allow the notification order to
`differ from the registration order
`to provide such
`It would also be an advancement
`and method which do not require special-purpose
`65 such as priority encoders
`to provide such
`It would be an additional advancement
`system and method which support broadcast notification
`
`Petitioner IBM – Ex. 1058, p. 8
`
`

`
`5925108
`
`Such
`
`disclosed
`
`method
`
`and system for event notification are
`and claimed herein
`
`BRIEF SUMMARY OF THE INVENTION
`
`novel method and sys
`The present
`invention provides
`tem which allow an event notification to be sent to multiple
`predefined order
`In one
`destinations
`to
`according
`is established when each
`embodiment
`the notification order
`registers for notification of the event However
`destination
`the notification order need not be the same as or even the
`reverse of the registration order
`Each registration of
`includes
`an indication of the desired notification order of the
`event handler also termed herein the event consumer
`further notifi
`of an event
`to prevent
`although consumption
`cations is optional This notification order does not change
`the registration This distinguishes the invention from
`after
`executive task handlers which constantly
`reassign priority to
`each
`task to determine which task will execute next The
`
`for event notification
`
`destination
`
`event engine upon receipt of the event notification first
`destination with the
`passes notification to the registered
`followed by the next and so on An
`highest notification level
`option exists for the engine to start with the event destination
`of the lowest notification level and continue until
`
`the highest
`
`has been serviced If
`level event destination
`mode of notification is desired or
`if ordering is not
`then registering the event destination with any
`important
`notification level will produce the desired results for broad
`cast events
`
`broadcast
`
`10
`
`is
`
`invention these notifications could be
`Without the present
`notification
`in
`tightly coupled system but
`accomplished
`above
`routine would require intimate knowledge
`of
`the
`sequence of events and would call routines associated with
`each of the above mentioned notifications Such dependen
`code
`and
`cies interfere with modular
`logically organized
`hence make the creation and modification of large computer
`and expensive
`systems more difficult
`However with the present
`invention this ordering can be
`readily achieved without such dependencies An event
`associated with the Remove PCMCIA Card action and
`corresponding
`are provided for
`event
`handlers
`the file
`system the file cache the connection manager the transport
`module and the low-level NIC driver Upon registration
`15 notification order is specified for these event handlers The
`notification order which may differ from the registration
`is based upon the OSI Model Upon receipt of the
`order
`system according to the invention noti
`event occurrence
`each of
`the destinations
`their
`in turn according
`
`fies
`
`20 notification order
`
`to
`
`Other events in Client32 code require different ordering
`Some of the events of interest
`are handled in
`bottom-up
`OSI Model ordering rather
`top-down
`than the
`ordering
`illustrated above But bottom-up notification order can also
`25 be readily specified
`for
`given class of events using the
`invention
`
`present
`The invention allows event handler
`code to be located in
`the source modules affiliated 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 more object-oriented
`approach to programming
`and readily
`than the tightly-coupled procedural
`approach
`allows multiple destinations unlike the message queue
`approach
`
`The features and advantages of the present
`become more fully apparent
`through the following descrip
`tion
`
`invention will
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`To
`
`illustrate
`
`the manner
`
`features of the
`
`and
`
`not
`
`in which the advantages
`invention are obtained
`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
`therefore to be considered limiting of its scope In the
`drawings
`FIG is
`and
`diagram illustrating individual computers
`computer network each of which is suitable for use with
`invention
`the present
`FIG is
`
`flowchart
`
`illustrating
`
`notification method of
`
`invention including
`
`notifying step
`
`the present
`FIG is
`flowchart further illustrating registration steps
`of the method shown in FIG
`FIG is
`flowchart further illustrating the notifying step
`shown in FIG
`FIG is
`flowchart further illustrating an ordering value
`registration step shown in FIG
`FIG is
`block diagram illustrating
`invention
`organization supported by the present
`FIG is
`form of software
`block diagram illustrating
`invention
`organization utilized in the absence of the present
`DETAILED DESCRIPTION OF THE
`EMBODIMENTS
`PREFERRED
`
`form of software
`
`The present
`for managing
`
`invention relates to
`
`event notification in
`
`method and apparatus
`computer system The
`
`30
`
`4Q
`
`50
`
`55
`
`The
`invention
`features which promote
`has several
`modular logically organized source code without sacrificing
`the ability to fully control the order of event notification The
`loosely coupled system in which event
`invention allows
`handlers do not need to be expressly known by the function
`the event The event handlers do not need to know
`producing
`that any other
`notification of
`
`routine is also interested
`
`the
`
`events will
`
`in handling
`the event Other
`be notified
`according to the order specified at notification registration
`time This means that
`registration can occur
`the
`in any
`given set of interested destinations and
`arbitrary order for
`be enforced
`the
`order of notification will still
`
`proper
`In some embodiments the desired ordering corresponds
`directly to well known scale such as memory hierarchy
`network
`architecture
`reference
`or the ordered layers in
`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
`reference model OSI Model
`tion network
`architecture
`CLIENT32
`trademark of Novell
`Inc.
`in the design of Client32 code is
`This ordering evident
`required for most of the events of
`also the order
`interest
`user wishes to remove
`within the client For example if
`PCMCIA Network Interface Card NIC from client
`the
`following sequence of events needs to be accomplished
`all open files associated with the connection
`by the NIC need to be closed
`
`is
`
`supported
`
`information cached at
`the client
`for
`any file
`needs to be flushed to the server disks
`connections
`the connection
`needs to be closed or terminated
`IPX needs to be notified that
`the NIC
`the transport
`in question is no longer available for service requests and
`the low-level drivers associated with the card need to 65
`the particular NIC is no longer available in
`be notified that
`
`those
`
`60
`
`the machine
`
`Petitioner IBM – Ex. 1058, p. 9
`
`

`
`workstations
`
`signal
`
`individual
`
`particular
`
`components
`
`invention is suitable for use on individual stand-alone com
`as on individual
`or multiple computers
`as well
`puters
`connected in
`computer network The computers may be
`mobile
`computers
`disconnectable
`laptop
`combination thereof The net
`computers file servers or
`work may include one or more LANs wide-area networks
`servers and clients intranet servers and clients or
`Internet
`combination thereof
`networks suited for use with
`One of the many computer
`invention is indicated generally at 10 in FIG
`the present
`10 includes Novell Net
`In one embodiment
`the network
`Ware network operating system software NETWARE is
`registered trademark of Novell
`Inc.
`embodiments
`the network includes
`NetWare
`Connect
`Services VINES Windows NT Windows 95 LAN
`Manager or LANtastic network operating
`system software
`trademark of Banyan Systems WINDOWS NT
`VINES is
`WINDOWS 95 and LAN MANAGER are trademarks
`LANTASTIC is
`trademark
`Microsoft Corporation
`Artisoft The network
`local area network
`10 may include
`14 including
`12 which is connectable
`to other networks
`other LANs or portions of the Internet or an intranet through
`gateway or other mechanism
`The network
`10 includes
`several
`file servers 16 that are
`connected by network signal lines 18 to one or more network
`clients 20 The file servers 16 and network
`clients 20 may be
`wide variety of
`by those of skill
`in the art
`in
`configured
`invention The file
`ways to operate according to the present
`servers 16 may be configured
`as Internet servers as intranet
`servers as directory services providers as software compo
`combination thereof The servers 16
`nent servers or as
`may be uniprocessor
`or multiprocessor machines
`Suitable network
`clients 20 include without
`limitation
`26 The
`personal computers 22 laptops 24 and workstations
`lines 18 may include twisted pair coaxial or optical
`lines satellites microwave
`fiber cables
`telephone
`relays
`modulated AC power
`lines and other data transmission
`wires known to those of skill
`in the art
`In addition to the
`computers 20
`printer 28 and an array
`network
`of
`client
`10 Although
`disks 30 are also attached to the network
`and network
`systems and
`computer
`are shown those of skill
`in the art will appre
`invention also works with
`ciate that
`the present
`variety of
`other networks
`and computers
`The file servers 16 and the network clients 20 are capable
`of using floppy drives tape drives optical drives or other
`storage medium 32
`means to read
`suitable
`storage
`medium 32 includes magnetic optical or other computer-
`specific physical substrate
`readable storage device having
`configuration Suitable storage devices include floppy disks
`hard disks tape CD-ROMs PROMs RAM and
`other
`system storage devices The substrate configura
`computer
`the com
`tion represents data and instructions which cause
`specific and predefined manner
`puter system to operate in
`as described herein Thus the medium 32 tangibly embodies
`program functions and/or
`instructions that are executable
`by the file servers 16 and/or network
`client computers 20 to
`perform event notification steps of
`invention
`the present
`substantially as described herein
`FIG illustrates method for managing
`system such as one or more of
`tion in
`the
`computer
`systems 10 16 20 shown in FIG according to the present
`invention The method includes
`step 40 of registering at
`least one event consumer with
`registry capable of holding
`multiple registrations Registration is described in greater
`record of which event
`detail hereafter but generally creates
`to notify in response to which events
`
`event notifica
`
`consumers
`
`5925108
`
`Suitable event consumers
`kind familiar to those of skill
`
`include
`event handlers of the
`in the art One suitable registry
`linked list of Event Control Blocks ECBs
`includes
`such as the list of NESL ECB structures
`described
`in
`programming language in the 214
`English and in the
`by ref
`application said description is hereby incorporated
`erence In addition to providing the registry with informa
`and the
`tion such as an identification of the event handler
`events of which it wishes notification the event handler
`registration step 40 defines
`for
`the
`registration order
`registered event consumers
`
`10
`
`registering an
`
`The method
`
`also includes
`
`step 42 of
`event consumer
`least one registered
`ordering value for at
`The step 42 defines an event consumer order which typically
`15 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
`programming language in the 214
`English and in the
`by ref
`application said description is hereby incorporated
`20 erence
`
`In alternative
`
`of
`
`of
`
`step 44 of registering at
`registry Such
`registration
`
`least
`
`at
`
`for the
`
`In one
`
`an event
`
`48 of
`
`one
`
`25
`
`40
`
`50
`
`according
`
`comprises
`
`events
`
`dures for
`
`The method also includes
`event producer with the
`produces
`least an identifier
`record containing
`producer and the type of event
`it produces
`embodiment
`44 is accomplished
`using
`the
`step
`function described in English and
`NESLRegisterProducer
`programming language in the 214 application said
`in the
`description is hereby
`by reference Multiple
`incorporated
`registered producers may produce the same event
`The method also includes
`step 46 of producing
`that was registered during the step
`using the event producer
`44 Suitable events include
`wide variety of events relating
`to user actions resource usage and other occurrences both
`within and without the computer system of types familiar to
`In one embodiment
`the step 46 is
`those of skill
`in the art
`function and an
`using NESLProduceEvent
`accomplished
`in English and
`EventData
`structure
`described
`in the
`programming language in the 214 application said descrip
`tion is hereby incorporated
`by reference
`illustrated method
`Finally the
`includes
`step
`least one of the event consumers of the event
`notifying at
`Notification is performed according to the event consumer
`order namely in the specified 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
`routines which
`the step 48 is accomplished
`using callback
`were registered during the step 40 The callback routines are
`to the order defined during the step 42
`invoked
`in English and
`Notification is further described
`in the
`programming language in the 214 application said descrip
`tion is hereby incorporated
`by reference
`FIG illustrates one embodiment of the steps 40 42 in
`greater detail The step 40 of registering event consumers
`steps 50 60 of
`two
`registering the names of
`steps 54 64 of registering callback proce
`and
`steps 56 66 of registering certain flags or
`and
`indicators and steps 58 68 of registering version
`equivalent
`identifiers The step 42 of registering ordering values com
`registering OSI Model
`steps 52 62 of
`layers as
`60 prises
`ordering values As indicated
`the bottom of FIG
`registrations may also be performed for additional event
`handlers two registrations are shown merely for illustration
`One embodiment of
`
`at
`
`system according to the invention
`65 maintains in computer memory
`dynamically allocated
`linked collection of ECBs corresponding
`to events
`Each
`ECB contains
`version
`least
`
`indicator
`
`at
`
`one ordering
`
`Petitioner IBM – Ex. 1058, p. 10
`
`

`
`FIG
`
`present
`
`first
`
`10 has
`
`that
`
`20
`
`25
`
`30
`
`40
`
`was registered
`
`to
`
`it
`
`to
`
`illustrates alternative methods
`by the
`provided
`invention for performing the notifying step 48 FIG
`sequence comprising steps 7074 notifies three
`followed by
`event handlers in the order indicated namely
`Three notifications are shown for illustra
`followed by
`tion more or fewer notifications are performed similarly
`to the invention The X-Y-Z sequence shown in
`according
`steps 7074 is followed under various circumstances
`It may
`be that
`which in turn
`has
`higher ordering value than
`Alternatively it may be
`higher ordering value than
`andY or
`and
`or all three have the same primary
`ordering value but different secondary ordering values were
`and
`and
`registered Or it may be that
`or
`or all
`three have
`the same ordering value but
`which was registered before
`is before
`Differently stated according to one method the notifying
`step 48 FIG notifies event consumers according
`to the
`registration order when the event consumers have
`the same
`and
`consumers
`otherwise
`notifies event
`ordering value
`according to the event consumer order
`According to another method the step 42 FIG
`steps 88 and 90 shown in FIG
`includes
`resulting in
`registration of both primary and secondary ordering values
`The step 90 of registering secondary ordering values defines
`event consumer order which differs from the
`secondary
`registration order The notifying step 48 then notifies event
`consumers according to the secondary event consumer order
`when the event consumers have
`the same primary ordering
`value and otherwise notifies event consumers according
`order defined by the step 88
`the primary event consumer
`This method can be used to define the relative order for
`event notifications within each OSI Model
`layer while
`layer-by-layer notification order
`the overall
`preserving
`second sequence shown in FIG
`comprising steps
`7680 illustrates the meaning of notification according to
`contrast with steps 7074 The
`through
`order
`specified
`notification order may be identical with the specified order
`or the notification order may be the reverse of the specified
`and bottom-
`order This allows for instance both top-down
`up OSI Model ordering Note that
`is not necessary
`re-register event handlers to reverse the effective notification
`order Events may be registered or flagged as top-down or
`bottom-up The producer declares an event to be top-down
`or bottom-up and the consumers merely register their OSI
`or other notification level
`in FIG
`third sequence shown
`comprising steps
`8284 illustrates consumption
`of an event by an event
`handler During step 82 event handler
`is notified of
`5Q given event During subsequent step 84 event handler
`notified of the event The event handler
`determines that no
`further notifications are needed and consumes the event
`the notification of event handler
`that
`
`5925108
`
`indication as to whether
`
`the
`
`to
`
`value an event name an
`is consumable an indication as to
`event
`corresponding
`whether
`is for broadcast an iden
`the corresponding
`event
`tification of module which owns the event and
`pointer
`In one embodiment broadcast
`an internal workspace
`events are implemented as non-consumable
`events
`ECBs and each of the steps shown in FIG are further
`described in English and in the
`programming language in
`the 214 application said descriptions
`are hereby incorpo
`rated by reference By way of illustration and not limitation
`using the NESLECB
`steps 50 60 may be accomplished
`NecbEventName
`field and related routines steps 52 62 may
`using the NESLECB NecbOsiLayer field
`be accomplished
`related routines steps 54 64 may be accomplished
`and
`using the NESLECB PNecbNotifyProc field and
`related
`steps 56 66 may be accomplished
`using
`NESLECB NecbRefData
`field and related routines and
`using the NESLECB
`steps 58 68 may be accomplished
`Necb Version field and related routines
`
`routines
`
`the
`
`method wherein the step 42
`Steps 52 and 62 illustrate
`FIG
`of registering an ordering value for each
`event
`registering ordering values which cor
`comprises
`consumer
`respond directly to layers in computer network architecture
`reference model namely the OSI Model As discussed in the
`Summary of the Invention at pages 7778 134 in the 214
`application and elsewhere allowing notification in an order
`corresponds
`to system architecture
`that
`but nonetheless
`differs from registration order allows software to be orga
`nized more logically and efficiently from programmers
`point of view
`
`event
`
`the
`
`file
`
`Under an alternative method of the invention the step 42
`FIG
`of registering an ordering value for each
`consumer
`registering ordering values which cor
`comprises
`respond directly to memory hierarchy Various memory
`are well-known including hierarchies organized
`hierarchies
`to memory access
`speed memory capacity
`according
`number of tasks which rely on data stored in
`particular
`familiar criteria Event con
`section of memory and other
`sumers may be organized during the step 42 according to the
`levels of such memory hierarchy
`To illustrate
`this aspect of the invention assume that
`given memory hierarchy contains
`cache
`contents
`network
`connection
`cache and
`volume information cache
`importance Assume further that an
`in order of increasing
`out of memory event occurs which is intended
`to cause
`some cache
`block of memory
`event handler
`to free up
`requested number of bytes such as
`least
`containing
`Kbytes The first event handler
`is the file
`to see the event
`cache
`that handler
`event handler
`contents
`Kbytes it does so and then consumes
`contents cache event handler cannot
`free Kbytes it returns
`not consumed message to the event engine which then
`passes the out of memory event notification to the network
`connection
`cache event handler This handler either
`frees the
`not
`requested memory and consumes the event or returns
`consumed status to the event engine which passes the
`event notification on to the volume information cache event
`handler
`
`at
`
`if
`
`can
`
`free
`
`the event
`
`If
`
`the file
`
`O