Appeal 2007-1476
Application 10/308,866
of a failure of a subsystem, Dias' recovery program anticipates 1) identifying
an active second member to replace the first member and 2) causing the
service to be provided by another member of the composite resource.
Dias discloses (col. 3, ll. 44-60, and Fig. 1) plural nodes 100-1
through 100-n, each with software subsystems 600-1 through 600-m. Dias
states (col. 4, ll. 2-5) that a monitor can detect if a subsystem fails. Failure
of a subsystem on one node "triggers recovery actions which are taken for
the other instances of that subsystem and also for subsystem that interact
with or depend on that subsystem" (Dias, col. 3, ll. 60-63). Dias discloses
(col. 7, ll. 14-25) that an event manager, upon receiving notice of a
subsystem failure that has not yet been recovered, looks to see if a rule exists
for the "resource type." Thus, the subsystems correspond to Appellants'
members, and failure of a subsystem corresponds to the claimed "event of
interest" in independent claims 1 and 32 and to the claimed member failure
in independent claim 18.
Dias further discloses (col. 7, l. 57-col. 8, l. 5) that a recovery program
begins executing commands by determining for each command the node on
which the command is to be executed. When a command is to be executed
on another node, the recovery driver transmits the command to the specified
node. Dias discloses (col. 9, l. 66-col. 10, l. 19) that a recovery command
includes five specifications – 1) the set of nodes upon which the command
should execute, 2) the command itself, 3) the expected resulting status for
the command to be executed successfully, 4) an information file used to
expand the recovery node specification, and 5) the maximum number of
times the command will be executed if the first try is not successful.
4
Page: Previous 1 2 3 4 5 6 7 Next
Last modified: September 9, 2013